From tschatzl at openjdk.org Mon Jan 2 14:21:58 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 2 Jan 2023 14:21:58 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett wrote: > Please review this change to WhiteBox and some tests involving G1 concurrent GCs. > > Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a > concurrent GC. Many of them follow it with a loop waiting for a concurrent > cycle to not be in progress. A few also preceed that call with a similar > loop, since that call does nothing and returns false if a concurrent cycle is > already in progress. Those tests typically want to ensure there was a > concurrent cycle that was started after some setup. > > The failing test calls that function, asserting that it returned true, e.g. a > new concurrent cycle was started. > > There are various problems with this, due to races with concurrent cycles > started automatically, and due to possibly aborted (by full GCs) concurrent cycles, > making some of these tests unreliable in some configurations. > > For example, the test failure associated with this bug intermittently arises > when running with `-Xcomp`, triggering a concurrent cycle before the explicit > request by the test, causing the explicit request to fail (because there is > already one in progress), failing the assert. Waiting for there not to be an > in-progress cycle before the explicit request just narrows the race window. > > We have a different mechanism in WhiteBox for controlling concurrent cycles, > the concurrent GC breakpoint mechanism. By adding a counter specifically for > such cycles, we can use GC breakpoints to ensure only the concurrent cycles > the test wants are occurring, and can verify they completed successfully. > > So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC > breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to > avoid racing request problems and to detect aborted cycles. Since it is no > longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began > this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer > serves any purpose, having been purely a test of that removed function. > > Testing: > mach5 tier1-7 - running the changed tests on a variety of platforms with a > variety of configurations. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk20/pull/71 From mbaesken at openjdk.org Mon Jan 2 14:38:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 2 Jan 2023 14:38:32 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args Message-ID: The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. This leads to a somewhat misleading message `[debugd] Argument is expected for 'rmiport' ` (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. ------------- Commit messages: - JDK-8299470 Changes: https://git.openjdk.org/jdk/pull/11811/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299470 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11811.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11811/head:pull/11811 PR: https://git.openjdk.org/jdk/pull/11811 From yyang at openjdk.org Tue Jan 3 09:43:38 2023 From: yyang at openjdk.org (Yi Yang) Date: Tue, 3 Jan 2023 09:43:38 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms Message-ID: harmless refactor to share code across different platforms of VirtualMachineImpl: 1. Shared code to process command response after requesting a command execution 2. Read functionality in SocketInputStream can be reused ------------- Commit messages: - update year - 8299518: HotSpotVirtualMachine shared code across different platforms Changes: https://git.openjdk.org/jdk/pull/11823/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299518 Stats: 448 lines in 5 files changed: 87 ins; 240 del; 121 mod Patch: https://git.openjdk.org/jdk/pull/11823.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11823/head:pull/11823 PR: https://git.openjdk.org/jdk/pull/11823 From sspitsyn at openjdk.org Tue Jan 3 18:51:08 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 3 Jan 2023 18:51:08 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v3] In-Reply-To: References: Message-ID: On Tue, 27 Dec 2022 14:26:39 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge ../jdk-openjdk into typos-typos > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10029 From sspitsyn at openjdk.org Tue Jan 3 19:12:01 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 3 Jan 2023 19:12:01 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v3] In-Reply-To: References: Message-ID: On Tue, 27 Dec 2022 14:26:39 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge ../jdk-openjdk into typos-typos > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Michael, I've reviewed the changes but the [JDK-8294321](https://bugs.openjdk.org/browse/JDK-8294321) seems to be already resolved. So, what JBS issue are you actually trying to fix? ------------- PR: https://git.openjdk.org/jdk/pull/10029 From lmesnik at openjdk.org Tue Jan 3 19:39:03 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 3 Jan 2023 19:39:03 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote: >> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. >> >> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Better comments. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11735 From cjplummer at openjdk.org Tue Jan 3 21:58:49 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 3 Jan 2023 21:58:49 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 19:08:59 GMT, Serguei Spitsyn wrote: > Michael, I've reviewed the changes but the [JDK-8294321](https://bugs.openjdk.org/browse/JDK-8294321) seems to be already resolved. So, what JBS issue are you actually trying to fix? It's closed because #11385 used it to fix some of the typos. #11385 should have used a new issue, but now instead a new issue is needed for the remaining typos. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Wed Jan 4 01:22:57 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 4 Jan 2023 01:22:57 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v3] In-Reply-To: References: Message-ID: On Tue, 27 Dec 2022 14:26:39 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge ../jdk-openjdk into typos-typos > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Hell Michael, I've created https://bugs.openjdk.org/browse/JDK-8299563 to track this final few typos. Could you please update the title of this PR to `8299563: Fix typos`? That should then allow you to proceed using this PR. Please also merge with latest master branch once more since some typo fixes from this PR have been merged recently. Thank you for your patience. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Wed Jan 4 01:23:01 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 4 Jan 2023 01:23:01 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 13:22:14 GMT, Alexey Ivanov wrote: >> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk into typos-typos >> - Remove file that was removed upstream >> - Fix inconsistency in capitalization >> - Undo change in zlip >> - Fix typos > > test/jdk/sun/jvmstat/testlibrary/utils.sh line 181: > >> 179: if [ $? -eq 0 ] >> 180: then >> 181: # it's still lingering, now it is hard > > Suggestion: > > # it's still lingering, now hit it hard @mernst, this suggestion appears relevant. Could you update the PR to address this? ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Wed Jan 4 01:26:57 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 4 Jan 2023 01:26:57 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 13:06:25 GMT, Alexey Ivanov wrote: >> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk into typos-typos >> - Remove file that was removed upstream >> - Fix inconsistency in capitalization >> - Undo change in zlip >> - Fix typos > > src/java.xml/share/classes/org/w3c/dom/Document.java line 293: > >> 291: * systemId, and notationName attributes are >> 292: * copied. If a deep import is requested, the descendants >> 293: * of the source Entity are recursively imported and > > This class may come from a 3rd party library. Anyone from `java.xml` can confirm it? @mernst, could you undo this change to this file from this PR? It does indeed seem to come from a 3rd party source. @JoeWang-Java can correct us if that's not the case. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dholmes at openjdk.org Wed Jan 4 02:08:50 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jan 2023 02:08:50 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 09:34:55 GMT, Yi Yang wrote: > harmless refactor to share code across different platforms of VirtualMachineImpl: > 1. Shared code to process command response after requesting a command execution > 2. Read functionality in SocketInputStream can be reused There are a lot of stylistic changes here that have nothing to do with refactoring or code sharing and they make the real changes very hard to see. At a minimum things like variable renaming should be done in a separate commit, so the refactoring is more obvious, but it may be better to use a separate cleanup RFE. src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 59: > 57: > 58: // This provider only understands pids > 59: int pid = Integer.parseInt(vmid); This will now throw `NumberFormatException` instead of the expected `AttachNotSupportedException`. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Wed Jan 4 02:58:50 2023 From: yyang at openjdk.org (Yi Yang) Date: Wed, 4 Jan 2023 02:58:50 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 02:05:38 GMT, David Holmes wrote: >> harmless refactor to share code across different platforms of VirtualMachineImpl: >> 1. Shared code to process command response after requesting a command execution >> 2. Read functionality in SocketInputStream can be reused > > src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 59: > >> 57: >> 58: // This provider only understands pids >> 59: int pid = Integer.parseInt(vmid); > > This will now throw `NumberFormatException` instead of the expected `AttachNotSupportedException`. The same check is performed in its superclass HotSpotVirtualMachine. So we can be sure that it will not throw NumberFormatException and AttachNotSupportedException here https://github.com/openjdk/jdk/blob/38cfc591725de478879266584280562f0ba4b42f/src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java#L69-L74 ------------- PR: https://git.openjdk.org/jdk/pull/11823 From kbarrett at openjdk.org Wed Jan 4 03:27:19 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 4 Jan 2023 03:27:19 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" [v2] In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: <2wRK9LZ0L4QdgzNhCM2bya3emb4zU9OTwvt5VnyzO0E=.0b22adcb-c49b-4a46-bf8a-82975ea1d514@github.com> > Please review this change to WhiteBox and some tests involving G1 concurrent GCs. > > Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a > concurrent GC. Many of them follow it with a loop waiting for a concurrent > cycle to not be in progress. A few also preceed that call with a similar > loop, since that call does nothing and returns false if a concurrent cycle is > already in progress. Those tests typically want to ensure there was a > concurrent cycle that was started after some setup. > > The failing test calls that function, asserting that it returned true, e.g. a > new concurrent cycle was started. > > There are various problems with this, due to races with concurrent cycles > started automatically, and due to possibly aborted (by full GCs) concurrent cycles, > making some of these tests unreliable in some configurations. > > For example, the test failure associated with this bug intermittently arises > when running with `-Xcomp`, triggering a concurrent cycle before the explicit > request by the test, causing the explicit request to fail (because there is > already one in progress), failing the assert. Waiting for there not to be an > in-progress cycle before the explicit request just narrows the race window. > > We have a different mechanism in WhiteBox for controlling concurrent cycles, > the concurrent GC breakpoint mechanism. By adding a counter specifically for > such cycles, we can use GC breakpoints to ensure only the concurrent cycles > the test wants are occurring, and can verify they completed successfully. > > So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC > breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to > avoid racing request problems and to detect aborted cycles. Since it is no > longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began > this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer > serves any purpose, having been purely a test of that removed function. > > Testing: > mach5 tier1-7 - running the changed tests on a variety of platforms with a > variety of configurations. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into test-concmark20 - use gc breakpoints to perform conc gc ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/71/files - new: https://git.openjdk.org/jdk20/pull/71/files/39abc3dc..3b837273 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=00-01 Stats: 786 lines in 35 files changed: 563 ins; 95 del; 128 mod Patch: https://git.openjdk.org/jdk20/pull/71.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/71/head:pull/71 PR: https://git.openjdk.org/jdk20/pull/71 From kbarrett at openjdk.org Wed Jan 4 03:27:20 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 4 Jan 2023 03:27:20 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" [v2] In-Reply-To: References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: On Thu, 22 Dec 2022 16:11:46 GMT, Ivan Walulya wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into test-concmark20 >> - use gc breakpoints to perform conc gc > > Lgtm! Thanks for reviews @walulyai and @tschatzl . ------------- PR: https://git.openjdk.org/jdk20/pull/71 From kbarrett at openjdk.org Wed Jan 4 03:31:57 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 4 Jan 2023 03:31:57 GMT Subject: [jdk20] Integrated: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett wrote: > Please review this change to WhiteBox and some tests involving G1 concurrent GCs. > > Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a > concurrent GC. Many of them follow it with a loop waiting for a concurrent > cycle to not be in progress. A few also preceed that call with a similar > loop, since that call does nothing and returns false if a concurrent cycle is > already in progress. Those tests typically want to ensure there was a > concurrent cycle that was started after some setup. > > The failing test calls that function, asserting that it returned true, e.g. a > new concurrent cycle was started. > > There are various problems with this, due to races with concurrent cycles > started automatically, and due to possibly aborted (by full GCs) concurrent cycles, > making some of these tests unreliable in some configurations. > > For example, the test failure associated with this bug intermittently arises > when running with `-Xcomp`, triggering a concurrent cycle before the explicit > request by the test, causing the explicit request to fail (because there is > already one in progress), failing the assert. Waiting for there not to be an > in-progress cycle before the explicit request just narrows the race window. > > We have a different mechanism in WhiteBox for controlling concurrent cycles, > the concurrent GC breakpoint mechanism. By adding a counter specifically for > such cycles, we can use GC breakpoints to ensure only the concurrent cycles > the test wants are occurring, and can verify they completed successfully. > > So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC > breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to > avoid racing request problems and to detect aborted cycles. Since it is no > longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began > this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer > serves any purpose, having been purely a test of that removed function. > > Testing: > mach5 tier1-7 - running the changed tests on a variety of platforms with a > variety of configurations. This pull request has now been integrated. Changeset: b743519b Author: Kim Barrett URL: https://git.openjdk.org/jdk20/commit/b743519ba911a254669fa8a96e6006c14e3f5ad1 Stats: 288 lines in 24 files changed: 98 ins; 131 del; 59 mod 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" Reviewed-by: iwalulya, tschatzl ------------- PR: https://git.openjdk.org/jdk20/pull/71 From dholmes at openjdk.org Wed Jan 4 04:22:51 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jan 2023 04:22:51 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 02:55:52 GMT, Yi Yang wrote: >> src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 59: >> >>> 57: >>> 58: // This provider only understands pids >>> 59: int pid = Integer.parseInt(vmid); >> >> This will now throw `NumberFormatException` instead of the expected `AttachNotSupportedException`. > > The same check is performed in its superclass HotSpotVirtualMachine. So we can be sure that it will not throw NumberFormatException and AttachNotSupportedException here > > https://github.com/openjdk/jdk/blob/38cfc591725de478879266584280562f0ba4b42f/src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java#L69-L74 In that case the `int pid` determined by the superclass should be made available to the subclasses so they can use it and not need to re-parse the `vmid`. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Wed Jan 4 05:00:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 4 Jan 2023 05:00:57 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: References: Message-ID: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> On Sat, 24 Dec 2022 04:14:07 GMT, Serguei Spitsyn wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix race between VTMS_transition_disable_for_one and start_VTMS_transition Still muddling through this ... src/hotspot/share/classfile/javaClasses.cpp line 1740: > 1738: void java_lang_Thread::inc_VTMS_transition_disable_count(oop java_thread) { > 1739: int val = VTMS_transition_disable_count(java_thread); > 1740: assert(JvmtiVTMSTransition_lock->owned_by_self(), "Must be locked"); Nit: normally a lock-checking assertion would come first in the function, so that it stands out more. src/hotspot/share/classfile/javaClasses.cpp line 1746: > 1744: void java_lang_Thread::dec_VTMS_transition_disable_count(oop java_thread) { > 1745: int val = VTMS_transition_disable_count(java_thread); > 1746: assert(JvmtiVTMSTransition_lock->owned_by_self(), "Must be locked"); Nit: normally a lock-checking assertion would come first in the function, so that it stands out more. src/hotspot/share/prims/jvmtiThreadState.cpp line 384: > 382: JvmtiThreadState* vstate = java_lang_Thread::jvmti_thread_state(vth()); > 383: if (vstate != NULL) { > 384: vstate->set_is_in_VTMS_transition(true); Is the VTMS transition flag in the `JvmtiThreadState` dead code now? src/hotspot/share/prims/jvmtiThreadState.cpp line 482: > 480: _VTMS_transition_disable_for_all_count > 0) { > 481: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); > 482: ml.notify_all(); Checking the counts outside the lock seems really racy. Maybe it is safe in the original code but now we have two counters it is very hard to ascertain this is correct. Overall I find it very hard to see exactly how these counters get used. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Wed Jan 4 07:43:55 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 4 Jan 2023 07:43:55 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> References: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> Message-ID: On Wed, 4 Jan 2023 04:33:53 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix race between VTMS_transition_disable_for_one and start_VTMS_transition > > src/hotspot/share/classfile/javaClasses.cpp line 1746: > >> 1744: void java_lang_Thread::dec_VTMS_transition_disable_count(oop java_thread) { >> 1745: int val = VTMS_transition_disable_count(java_thread); >> 1746: assert(JvmtiVTMSTransition_lock->owned_by_self(), "Must be locked"); > > Nit: normally a lock-checking assertion would come first in the function, so that it stands out more. Okay, thanks. Fixed locally. > src/hotspot/share/prims/jvmtiThreadState.cpp line 384: > >> 382: JvmtiThreadState* vstate = java_lang_Thread::jvmti_thread_state(vth()); >> 383: if (vstate != NULL) { >> 384: vstate->set_is_in_VTMS_transition(true); > > Is the VTMS transition flag in the `JvmtiThreadState` dead code now? Yes. All this dead code has been removed now. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Wed Jan 4 07:48:58 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 4 Jan 2023 07:48:58 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> References: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> Message-ID: On Wed, 4 Jan 2023 04:54:27 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix race between VTMS_transition_disable_for_one and start_VTMS_transition > > src/hotspot/share/prims/jvmtiThreadState.cpp line 482: > >> 480: _VTMS_transition_disable_for_all_count > 0) { >> 481: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); >> 482: ml.notify_all(); > > Checking the counts outside the lock seems really racy. Maybe it is safe in the original code but now we have two counters it is very hard to ascertain this is correct. Overall I find it very hard to see exactly how these counters get used. This notification code is just an optimization. All related waiting fragments are with timeouts. I agree this sync protocol is kind of complicated and also does not scale well. I'm still thinking on how to improve it. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From yyang at openjdk.org Wed Jan 4 09:22:40 2023 From: yyang at openjdk.org (Yi Yang) Date: Wed, 4 Jan 2023 09:22:40 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: References: Message-ID: > harmless refactor to share code across different platforms of VirtualMachineImpl: > 1. Shared code to process command response after requesting a command execution > 2. Read functionality in SocketInputStream can be reused Yi Yang 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: - separate renaming - 8299518: HotSpotVirtualMachine shared code across different platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11823/files - new: https://git.openjdk.org/jdk/pull/11823/files/293cccdd..cb700000 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11823.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11823/head:pull/11823 PR: https://git.openjdk.org/jdk/pull/11823 From mbaesken at openjdk.org Wed Jan 4 12:10:11 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 12:10:11 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v2] In-Reply-To: References: Message-ID: > The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. > This leads to a somewhat misleading message > `[debugd] Argument is expected for 'rmiport' ` > (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. > Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Improve exception message for SAGetoptException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11811/files - new: https://git.openjdk.org/jdk/pull/11811/files/0844170b..9c5d46d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11811.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11811/head:pull/11811 PR: https://git.openjdk.org/jdk/pull/11811 From mbaesken at openjdk.org Wed Jan 4 12:10:12 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 12:10:12 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args In-Reply-To: References: Message-ID: On Mon, 2 Jan 2023 14:31:14 GMT, Matthias Baesken wrote: > The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. > This leads to a somewhat misleading message > `[debugd] Argument is expected for 'rmiport' ` > (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. > Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. I adjusted the exception message a bit to show what is wrong (-1 as an argument is not expected/supported). Removed one warning output because it seems we do not get there. Any reviews ? ------------- PR: https://git.openjdk.org/jdk/pull/11811 From clanger at openjdk.org Wed Jan 4 12:44:50 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 4 Jan 2023 12:44:50 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 12:10:11 GMT, Matthias Baesken wrote: >> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. >> This leads to a somewhat misleading message >> `[debugd] Argument is expected for 'rmiport' ` >> (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. >> Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Improve exception message for SAGetoptException I've got one suggestion, plus, the copyright year now is 2023 ? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java line 503: > 501: } > 502: } catch (SAGetoptException e) { > 503: System.err.println("SA agent option related exception occured"); Maybe you could do here: `System.err.println("SA agent option exception occured: " + e.getMessage);` and remove the `System.err.println(e.getMessage());` in line 505. ------------- Changes requested by clanger (Reviewer). PR: https://git.openjdk.org/jdk/pull/11811 From mbaesken at openjdk.org Wed Jan 4 13:04:10 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 13:04:10 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v3] In-Reply-To: References: Message-ID: > The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. > This leads to a somewhat misleading message > `[debugd] Argument is expected for 'rmiport' ` > (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. > Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Copyright years, omit one output line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11811/files - new: https://git.openjdk.org/jdk/pull/11811/files/9c5d46d8..d42cc159 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11811.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11811/head:pull/11811 PR: https://git.openjdk.org/jdk/pull/11811 From clanger at openjdk.org Wed Jan 4 13:07:51 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 4 Jan 2023 13:07:51 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v3] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 13:04:10 GMT, Matthias Baesken wrote: >> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. >> This leads to a somewhat misleading message >> `[debugd] Argument is expected for 'rmiport' ` >> (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. >> Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright years, omit one output line Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11811 From kevinw at openjdk.org Wed Jan 4 14:21:51 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 4 Jan 2023 14:21:51 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v3] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 13:04:10 GMT, Matthias Baesken wrote: >> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. >> This leads to a somewhat misleading message >> `[debugd] Argument is expected for 'rmiport' ` >> (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. >> Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright years, omit one output line The changes here to log a better error are I think good (maybe adding the stacktrace printing is not needed now the error is more understandable!), but aborting the launch attempt in the caller, if it gets -1 when trying to find a free port, should be even clearer? In test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java the method testWithPid() finds an rmiPort: final int rmiPort = useRmiPort ? Utils.findUnreservedFreePort(REGISTRY_DEFAULT_PORT, registryPort) : -1; ...but can proceed to launch even if it gets that -1 value? That looks like a mistake. In the "if (useRmiPort) {" block, we should be failing the test if rmiPort is -1, saying something like "cannot find an rmiPort, findUnreservedFreePort returns -1" A similar abort if setting registryPort gets -1 might also be good? ------------- PR: https://git.openjdk.org/jdk/pull/11811 From mbaesken at openjdk.org Wed Jan 4 14:27:48 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 14:27:48 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v3] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:19:18 GMT, Kevin Walls wrote: > In the "if (useRmiPort) {" block, we should be failing the test if rmiPort is -1, saying something like "cannot find an rmiPort, findUnreservedFreePort returns -1" > > A similar abort if setting registryPort gets -1 might also be good? Hi Kevin, I think you are correct, adjusting the test test/hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java in those two cases (rmiPort / registryPort -1) probably makes sense. Should we do it in another JBS issue or here ? Additionally , should we fail the test in these cases , or pass with some warning - message ? ------------- PR: https://git.openjdk.org/jdk/pull/11811 From jwilhelm at openjdk.org Wed Jan 4 14:34:19 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 4 Jan 2023 14:34:19 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8299476: PPC64 Zero build fails after JDK-8286302 - 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" - 8299483: ProblemList java/text/Format/NumberFormat/CurrencyFormat.java - 8298324: Unable to run shell test with make - 8299235: broken link referencing missing id The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=11845&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11845&range=00.1 Changes: https://git.openjdk.org/jdk/pull/11845/files Stats: 299 lines in 28 files changed: 101 ins; 131 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/11845.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11845/head:pull/11845 PR: https://git.openjdk.org/jdk/pull/11845 From djelinski at openjdk.org Wed Jan 4 14:39:37 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 4 Jan 2023 14:39:37 GMT Subject: RFR: 8299593: getprotobyname should not be used Message-ID: <8nFkW5weDqgQxZbKi5LZjwlRnc7mdME5QHWbwi6MgFM=.70eb5c32-6c00-4e10-b7f5-6a2d28b69b71@github.com> Please review this patch that removes the remaining uses of non-reentrant `getprotobyname` function. While the protocol number for TCP could theoretically be modified to something other than the default `IPPROTO_TCP`, that scenario would likely not work, and is not something that we are willing to support. [Existing code](https://github.com/openjdk/jdk/blob/2f3f3b618500b5f112fabca30d4c6780b2a8e723/src/java.base/unix/native/libnet/net_util_md.c#L355) in networking area is using `IPPROTO_TCP` for `TCP_NODELAY`, and no issues were reported. Tier 1-3 tests still pass. ------------- Commit messages: - Copyright - Remove getprotobyname Changes: https://git.openjdk.org/jdk/pull/11842/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11842&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299593 Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11842.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11842/head:pull/11842 PR: https://git.openjdk.org/jdk/pull/11842 From kevinw at openjdk.org Wed Jan 4 14:41:54 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 4 Jan 2023 14:41:54 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v3] In-Reply-To: References: Message-ID: <-asflXFaJzF88SV_P2FIS1vyfhKeBn8Rxl-lALQC3Bw=.a7e5dcf2-15f1-49a8-8e7e-97e9fda8200b@github.com> On Wed, 4 Jan 2023 13:04:10 GMT, Matthias Baesken wrote: >> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. >> This leads to a somewhat misleading message >> `[debugd] Argument is expected for 'rmiport' ` >> (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. >> Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright years, omit one output line SADebugDTest is only one test, so seems OK to have it fail as soon as we realise we need a port, and it has a value of -1. I would do it in this change as they are so connected, but really whichever works best for you. (I don't see other uses of findUnreservedFreePort() in the same test hierarchy, so this task should not keep on growing... 8-) ) ------------- PR: https://git.openjdk.org/jdk/pull/11811 From alanb at openjdk.org Wed Jan 4 14:45:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 4 Jan 2023 14:45:52 GMT Subject: RFR: 8299593: getprotobyname should not be used In-Reply-To: <8nFkW5weDqgQxZbKi5LZjwlRnc7mdME5QHWbwi6MgFM=.70eb5c32-6c00-4e10-b7f5-6a2d28b69b71@github.com> References: <8nFkW5weDqgQxZbKi5LZjwlRnc7mdME5QHWbwi6MgFM=.70eb5c32-6c00-4e10-b7f5-6a2d28b69b71@github.com> Message-ID: On Wed, 4 Jan 2023 12:56:18 GMT, Daniel Jeli?ski wrote: > Please review this patch that removes the remaining uses of non-reentrant `getprotobyname` function. > > While the protocol number for TCP could theoretically be modified to something other than the default `IPPROTO_TCP`, that scenario would likely not work, and is not something that we are willing to support. [Existing code](https://github.com/openjdk/jdk/blob/2f3f3b618500b5f112fabca30d4c6780b2a8e723/src/java.base/unix/native/libnet/net_util_md.c#L355) in networking area is using `IPPROTO_TCP` for `TCP_NODELAY`, and no issues were reported. > > Tier 1-3 tests still pass. Looks okay, should be no reason to use getprotobyname here. I assume everything would break if /etc/protocols were changed to set to another value. ------------- PR: https://git.openjdk.org/jdk/pull/11842 From mbaesken at openjdk.org Wed Jan 4 14:56:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 14:56:54 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v4] In-Reply-To: References: Message-ID: > The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. > This leads to a somewhat misleading message > `[debugd] Argument is expected for 'rmiport' ` > (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. > Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust SADebugDTest in case we get port -1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11811/files - new: https://git.openjdk.org/jdk/pull/11811/files/d42cc159..d81273c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=02-03 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11811.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11811/head:pull/11811 PR: https://git.openjdk.org/jdk/pull/11811 From mbaesken at openjdk.org Wed Jan 4 14:56:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 14:56:55 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v3] In-Reply-To: <-asflXFaJzF88SV_P2FIS1vyfhKeBn8Rxl-lALQC3Bw=.a7e5dcf2-15f1-49a8-8e7e-97e9fda8200b@github.com> References: <-asflXFaJzF88SV_P2FIS1vyfhKeBn8Rxl-lALQC3Bw=.a7e5dcf2-15f1-49a8-8e7e-97e9fda8200b@github.com> Message-ID: On Wed, 4 Jan 2023 14:39:14 GMT, Kevin Walls wrote: > SADebugDTest is only one test, so seems OK to have it fail as soon as we realise we need a port, and it has a value of -1. > > I would do it in this change as they are so connected, but really whichever works best for you. (I don't see other uses of findUnreservedFreePort() in the same test hierarchy, so this task should not keep on growing... 8-) ) Hi Kevin, I adjusted the mentioned test, please have a look ! ------------- PR: https://git.openjdk.org/jdk/pull/11811 From kevinw at openjdk.org Wed Jan 4 15:16:50 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 4 Jan 2023 15:16:50 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v4] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:56:54 GMT, Matthias Baesken wrote: >> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. >> This leads to a somewhat misleading message >> `[debugd] Argument is expected for 'rmiport' ` >> (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. >> Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust SADebugDTest in case we get port -1 Looks good! Rereading the change, occured should be "occurred" (we do have a lot of "occured" in the JDK, but many more "occurred") On the line after that, I don't think we should introduce the stacktrace. The user is getting a more readable error message already... In SAGetopt.java you single-quote the 'opt' value, but could we do the same to the _argv[_optind] value. Then can you could make it "a registryPort" rather than "an", and I think I'm done with comments. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11811 From mbaesken at openjdk.org Wed Jan 4 15:30:10 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 4 Jan 2023 15:30:10 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v5] In-Reply-To: References: Message-ID: > The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. > This leads to a somewhat misleading message > `[debugd] Argument is expected for 'rmiport' ` > (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. > Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Small output adjustments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11811/files - new: https://git.openjdk.org/jdk/pull/11811/files/d81273c0..1020fe27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11811&range=03-04 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11811.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11811/head:pull/11811 PR: https://git.openjdk.org/jdk/pull/11811 From jwilhelm at openjdk.org Wed Jan 4 16:06:57 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 4 Jan 2023 16:06:57 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 14:25:12 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: df1caf90 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/df1caf90818558b897a6b8ab80757f2a03398c55 Stats: 299 lines in 28 files changed: 101 ins; 131 del; 67 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/11845 From mernst at openjdk.org Wed Jan 4 16:35:41 2023 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 4 Jan 2023 16:35:41 GMT Subject: RFR: 8299563: Fix typos [v4] In-Reply-To: References: Message-ID: > 8299563: Fix typos Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Address review feedback - Merge ../jdk-openjdk into typos-typos - Merge ../jdk-openjdk into typos-typos - Reinstate typos in Apache code that is copied into the JDK - Merge ../jdk-openjdk into typos-typos - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos ------------- Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=03 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From lancea at openjdk.org Wed Jan 4 16:41:55 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 4 Jan 2023 16:41:55 GMT Subject: RFR: 8299563: Fix typos [v4] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 16:35:41 GMT, Michael Ernst wrote: >> 8299563: Fix typos > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Address review feedback > - Merge ../jdk-openjdk into typos-typos > - Merge ../jdk-openjdk into typos-typos > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10029 From aivanov at openjdk.org Wed Jan 4 19:56:59 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Jan 2023 19:56:59 GMT Subject: RFR: 8299563: Fix typos [v4] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 16:35:41 GMT, Michael Ernst wrote: >> 8299563: Fix typos > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Address review feedback > - Merge ../jdk-openjdk into typos-typos > - Merge ../jdk-openjdk into typos-typos > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Wed Jan 4 20:02:57 2023 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 4 Jan 2023 20:02:57 GMT Subject: Integrated: 8299563: Fix typos In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8299563: Fix typos This pull request has now been integrated. Changeset: 7dcc6899 Author: Michael Ernst Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/7dcc689932ea276586282e0917f2efc10a598eb7 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod 8299563: Fix typos Reviewed-by: lancea, aivanov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Wed Jan 4 22:38:03 2023 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 4 Jan 2023 22:38:03 GMT Subject: RFR: 8299563: Fix typos [v3] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 01:19:52 GMT, Jaikiran Pai wrote: >> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Merge ../jdk-openjdk into typos-typos >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk into typos-typos >> - Remove file that was removed upstream >> - Fix inconsistency in capitalization >> - Undo change in zlip >> - Fix typos > > Hello Michael, I've created https://bugs.openjdk.org/browse/JDK-8299563 to track this final few typos. Could you please update the title of this PR to `8299563: Fix typos`? That should then allow you to proceed using this PR. Please also merge with latest master branch once more since some typo fixes from this PR have been merged recently. Thank you for your patience. Thank you @jaikiran @LanceAndersen @aivanov-jdk ! ------------- PR: https://git.openjdk.org/jdk/pull/10029 From sspitsyn at openjdk.org Wed Jan 4 23:41:50 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 4 Jan 2023 23:41:50 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v5] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 15:30:10 GMT, Matthias Baesken wrote: >> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. >> This leads to a somewhat misleading message >> `[debugd] Argument is expected for 'rmiport' ` >> (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. >> Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Small output adjustments Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11811 From yyang at openjdk.org Thu Jan 5 02:53:50 2023 From: yyang at openjdk.org (Yi Yang) Date: Thu, 5 Jan 2023 02:53:50 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 04:20:11 GMT, David Holmes wrote: > In that case the `int pid` determined by the superclass should be made available to the subclasses so they can use it and not need to re-parse the `vmid`. Hi @dholmes-ora, this is feasible, but in fact, the super class of VirtualMachine has already saved an unresolved pid(String) and corresponding getter method, so if we want to avoid re-parsing pid, we should save this parsed result in the parent class of the parent class of VirtualMachineImpl, and then modify the corresponding method, which seems to be beyond the scope of simple refactoring, so I hope avoiding re-parsing can be done by another PR ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Thu Jan 5 02:53:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 02:53:54 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: References: Message-ID: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> On Wed, 4 Jan 2023 09:22:40 GMT, Yi Yang wrote: >> harmless refactor to share code across different platforms of VirtualMachineImpl: >> 1. Shared code to process command response after requesting a command execution >> 2. Read functionality in SocketInputStream can be reused > > Yi Yang 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: > > - separate renaming > - 8299518: HotSpotVirtualMachine shared code across different platforms src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 195: > 193: * InputStream for the socket connection to get target VM > 194: */ > 195: private static class SocketInputStreamImpl extends SocketInputStream { Can this class definition also be shared by making it a protected nested class in the superclass? src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 188: > 186: > 187: // known error > 188: private static final int ATTACH_ERROR_BADVERSION = 101; It doesn't look right that this has the same value as ATTACH_ERROR_NOTONCP src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 372: > 370: } > 371: > 372: void processCompletionStatus(IOException ioe, String cmd, InputStream sis) throws AgentLoadException, IOException { Some doc comments for this method would be good. src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 425: > 423: > 424: protected abstract int readImpl(long fd, byte[] bs, int off, int len) throws IOException; > 425: protected abstract void closeImpl(long fd) throws IOException; If the subclasses all override these in exactly the same way then these do not need to be abstract and can simply delegate to VirtualMachineImpl.xxx ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Thu Jan 5 02:53:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 02:53:55 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> References: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> Message-ID: On Thu, 5 Jan 2023 02:35:54 GMT, David Holmes wrote: >> Yi Yang 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: >> >> - separate renaming >> - 8299518: HotSpotVirtualMachine shared code across different platforms > > src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 195: > >> 193: * InputStream for the socket connection to get target VM >> 194: */ >> 195: private static class SocketInputStreamImpl extends SocketInputStream { > > Can this class definition also be shared by making it a protected nested class in the superclass? Sorry I see it already is, but I think we can do better. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Thu Jan 5 02:53:56 2023 From: yyang at openjdk.org (Yi Yang) Date: Thu, 5 Jan 2023 02:53:56 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: References: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> Message-ID: On Thu, 5 Jan 2023 02:40:22 GMT, David Holmes wrote: >> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 195: >> >>> 193: * InputStream for the socket connection to get target VM >>> 194: */ >>> 195: private static class SocketInputStreamImpl extends SocketInputStream { >> >> Can this class definition also be shared by making it a protected nested class in the superclass? > > Sorry I see it already is, but I think we can do better. This(`SocketInputStreamImpl`) is implementation-specific, it calls platform-dependent VirtualMachine.xxx. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Thu Jan 5 02:53:57 2023 From: yyang at openjdk.org (Yi Yang) Date: Thu, 5 Jan 2023 02:53:57 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> References: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> Message-ID: On Thu, 5 Jan 2023 02:36:59 GMT, David Holmes wrote: >> Yi Yang 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: >> >> - separate renaming >> - 8299518: HotSpotVirtualMachine shared code across different platforms > > src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 188: > >> 186: >> 187: // known error >> 188: private static final int ATTACH_ERROR_BADVERSION = 101; > > It doesn't look right that this has the same value as ATTACH_ERROR_NOTONCP They are located in different error families. The former is to deal with agent_load and the latter is to deal with command execution version errors. > src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 425: > >> 423: >> 424: protected abstract int readImpl(long fd, byte[] bs, int off, int len) throws IOException; >> 425: protected abstract void closeImpl(long fd) throws IOException; > > If the subclasses all override these in exactly the same way then these do not need to be abstract and can simply delegate to VirtualMachineImpl.xxx All Posix OS platforms call the same VirtualMachineImpl.read/write/etc, but Windows is an unusual guy, it calls VirtualMachineImpl.readPipe/writePipe/etc ------------- PR: https://git.openjdk.org/jdk/pull/11823 From sspitsyn at openjdk.org Thu Jan 5 03:05:51 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 5 Jan 2023 03:05:51 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 09:22:40 GMT, Yi Yang wrote: >> harmless refactor to share code across different platforms of VirtualMachineImpl: >> 1. Shared code to process command response after requesting a command execution >> 2. Read functionality in SocketInputStream can be reused > > Yi Yang 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: > > - separate renaming > - 8299518: HotSpotVirtualMachine shared code across different platforms I like the approach in general. Also, I agree with David on his comments, especially on the renaming. The abstract methods `readImpl()` and `closeImpl()` is better to name as `read()` and `close()`. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Thu Jan 5 03:05:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 03:05:53 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: References: Message-ID: On Thu, 5 Jan 2023 02:44:48 GMT, Yi Yang wrote: >> In that case the `int pid` determined by the superclass should be made available to the subclasses so they can use it and not need to re-parse the `vmid`. > >> In that case the `int pid` determined by the superclass should be made available to the subclasses so they can use it and not need to re-parse the `vmid`. > > Hi @dholmes-ora, this is feasible, but in fact, the super class of VirtualMachine has already saved an unresolved pid(String) and corresponding getter method, so if we want to avoid re-parsing pid, we should save this parsed result in the parent class of the parent class of VirtualMachineImpl, and then modify the corresponding method, which seems to be beyond the scope of simple refactoring, so I hope avoiding re-parsing can be done by another PR It is well within scope of improving code sharing in this arera, but I'm okay with leaving that for a next step. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Thu Jan 5 03:08:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 03:08:53 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v2] In-Reply-To: References: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> Message-ID: On Thu, 5 Jan 2023 02:50:49 GMT, Yi Yang wrote: >> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 425: >> >>> 423: >>> 424: protected abstract int readImpl(long fd, byte[] bs, int off, int len) throws IOException; >>> 425: protected abstract void closeImpl(long fd) throws IOException; >> >> If the subclasses all override these in exactly the same way then these do not need to be abstract and can simply delegate to VirtualMachineImpl.xxx > > All Posix OS platforms call the same VirtualMachineImpl.read/write/etc, but Windows is an unusual guy, it calls VirtualMachineImpl.readPipe/writePipe/etc That is a shame, though perhaps we could just rename those methods on Windows? This also raises the obvious question can we in fact reduce this to just a Windows and Posix version, or are there other differences between Linux, macOS etc that have to be accounted for? Though in that case we could introduce a shared superclass for the Posix platforms. Next steps perhaps? ------------- PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Thu Jan 5 03:32:21 2023 From: yyang at openjdk.org (Yi Yang) Date: Thu, 5 Jan 2023 03:32:21 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: Message-ID: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> > harmless refactor to share code across different platforms of VirtualMachineImpl: > 1. Shared code to process command response after requesting a command execution > 2. Read functionality in SocketInputStream can be reused Yi Yang has updated the pull request incrementally with one additional commit since the last revision: add doc; readImpl/closeImpl to read/close ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11823/files - new: https://git.openjdk.org/jdk/pull/11823/files/cb700000..0580ab2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=01-02 Stats: 15 lines in 5 files changed: 3 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11823.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11823/head:pull/11823 PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Thu Jan 5 03:38:49 2023 From: yyang at openjdk.org (Yi Yang) Date: Thu, 5 Jan 2023 03:38:49 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> Message-ID: <_lqJUms8uyKL0-X7RNrb8Q4BmILuUuKuXckrvTLzgG0=.487a0510-85dd-4d4b-b37b-e8cf26382eae@github.com> On Thu, 5 Jan 2023 03:06:20 GMT, David Holmes wrote: >> All Posix OS platforms call the same VirtualMachineImpl.read/write/etc, but Windows is an unusual guy, it calls VirtualMachineImpl.readPipe/writePipe/etc > > That is a shame, though perhaps we could just rename those methods on Windows? > > This also raises the obvious question can we in fact reduce this to just a Windows and Posix version, or are there other differences between Linux, macOS etc that have to be accounted for? Though in that case we could introduce a shared superclass for the Posix platforms. Next steps perhaps? The remaining code for the POSIX system is exactly the same, except that Linux will make an extra attempt to find java_pid in cgroup environment. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Thu Jan 5 04:33:50 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 04:33:50 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> References: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> Message-ID: On Thu, 5 Jan 2023 02:37:45 GMT, David Holmes wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> add doc; readImpl/closeImpl to read/close > > src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 372: > >> 370: } >> 371: >> 372: void processCompletionStatus(IOException ioe, String cmd, InputStream sis) throws AgentLoadException, IOException { > > Some doc comments for this method would be good. I was thinking more about describing what the parameters are - in particular it is unclear why the actual IOE can be replaced by a passed in one. If we wanted a custom message then I would at least expect to chain the actual IOE to the replacement. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Thu Jan 5 04:33:52 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 04:33:52 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Thu, 5 Jan 2023 03:32:21 GMT, Yi Yang wrote: >> harmless refactor to share code across different platforms of VirtualMachineImpl: >> 1. Shared code to process command response after requesting a command execution >> 2. Read functionality in SocketInputStream can be reused > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > add doc; readImpl/closeImpl to read/close src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java line 130: > 128: @Override > 129: protected int read(long fd, byte[] bs, int off, int len) throws IOException { > 130: return VirtualMachineImpl.readPipe(fd, bs, off, len); If you add read/close methods for Windows that then call readPipe/closePipe, then we don't need to subclass and override. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From sspitsyn at openjdk.org Thu Jan 5 05:02:51 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 5 Jan 2023 05:02:51 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Thu, 5 Jan 2023 04:31:16 GMT, David Holmes wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> add doc; readImpl/closeImpl to read/close > > src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java line 130: > >> 128: @Override >> 129: protected int read(long fd, byte[] bs, int off, int len) throws IOException { >> 130: return VirtualMachineImpl.readPipe(fd, bs, off, len); > > If you add read/close methods for Windows that then call readPipe/closePipe, then we don't need to subclass and override. Good suggestion. However, I wonder why the `fd` is casted from `long` to `int` on Unix. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Thu Jan 5 05:46:50 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 05:46:50 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Thu, 5 Jan 2023 04:59:51 GMT, Serguei Spitsyn wrote: >> src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java line 130: >> >>> 128: @Override >>> 129: protected int read(long fd, byte[] bs, int off, int len) throws IOException { >>> 130: return VirtualMachineImpl.readPipe(fd, bs, off, len); >> >> If you add read/close methods for Windows that then call readPipe/closePipe, then we don't need to subclass and override. > > Good suggestion. > However, I wonder why the `fd` is casted from `long` to `int` on Unix. The Unix versions of SocketInputStream had `int fd`. > So, the following code also needs to cast `fd` to `int`: > > + public synchronized int read(byte[] bs, int off, int len) throws IOException { > + if ((off < 0) || (off > bs.length) || (len < 0) || > + ((off + len) > bs.length) || ((off + len) < 0)) { > + throw new IndexOutOfBoundsException(); > + } else if (len == 0) { > + return 0; > + } > + return read(fd, bs, off, len); <== ??? > + } > + > + public synchronized void close() throws IOException { > + if (fd != -1) { > + close(fd); <== ??? > + } Looks like Windows needs a long fd so the shared API takes long and we then cast to int for the Unix native methods. A little messy but fixable. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From kevinw at openjdk.org Thu Jan 5 07:53:49 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 5 Jan 2023 07:53:49 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v5] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 15:30:10 GMT, Matthias Baesken wrote: >> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. >> This leads to a somewhat misleading message >> `[debugd] Argument is expected for 'rmiport' ` >> (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. >> Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Small output adjustments Marked as reviewed by kevinw (Committer). Thanks for updating. I do think we should remove the e.printStackTrace() that was added in src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java as this is a message for the user. In the test, those new RuntimeExceptions will produce a stacktrace for when we look at the failing test. ------------- PR: https://git.openjdk.org/jdk/pull/11811 From mbaesken at openjdk.org Thu Jan 5 08:02:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Jan 2023 08:02:54 GMT Subject: Integrated: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args In-Reply-To: References: Message-ID: <2QHITCER3HfKhS5XdxhBSEOI4hULHabmn0BJJnETMkg=.b0827f19-9439-4863-a56f-a89b91f03ae1@github.com> On Mon, 2 Jan 2023 14:31:14 GMT, Matthias Baesken wrote: > The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. > This leads to a somewhat misleading message > `[debugd] Argument is expected for 'rmiport' ` > (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. > Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. This pull request has now been integrated. Changeset: 2ccdefc8 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/2ccdefc81c0ea2ea5c4380bb045aa82ad1eb8205 Stats: 13 lines in 3 files changed: 8 ins; 0 del; 5 mod 8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args Reviewed-by: clanger, sspitsyn, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/11811 From mbaesken at openjdk.org Thu Jan 5 09:02:31 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Jan 2023 09:02:31 GMT Subject: RFR: JDK-8299657: sun/tools/jhsdb/SAGetoptTest.java fails after 8299470 Message-ID: <3I_VXTEXKOXBIBw9LFmd_qYEm3eA4_xRx-RzcoDqg44=.408773f2-6e46-4948-ba68-10256fcfe633@github.com> Some exception/error message changed with 8299470 so we have to adjust the test. Current error is Unexpected error 'Successor argument without leading - is expected for 'd' but we got '-c'' java.lang.RuntimeException: Bad option test 4 failed at SAGetoptTest.badOptionsTest(SAGetoptTest.java:124) at SAGetoptTest.main(SAGetoptTest.java:149) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125) at java.base/java.lang.Thread.run(Thread.java:1623) ------------- Commit messages: - JDK-8299657 Changes: https://git.openjdk.org/jdk/pull/11860/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11860&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299657 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11860.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11860/head:pull/11860 PR: https://git.openjdk.org/jdk/pull/11860 From clanger at openjdk.org Thu Jan 5 09:29:49 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 5 Jan 2023 09:29:49 GMT Subject: RFR: JDK-8299657: sun/tools/jhsdb/SAGetoptTest.java fails after 8299470 In-Reply-To: <3I_VXTEXKOXBIBw9LFmd_qYEm3eA4_xRx-RzcoDqg44=.408773f2-6e46-4948-ba68-10256fcfe633@github.com> References: <3I_VXTEXKOXBIBw9LFmd_qYEm3eA4_xRx-RzcoDqg44=.408773f2-6e46-4948-ba68-10256fcfe633@github.com> Message-ID: <6t5UPYE2yLU79mLuORytNDN6hf0fbFk3bTbxmUS0Q3s=.3234779a-e9e0-499f-b591-447e0acb538a@github.com> On Thu, 5 Jan 2023 08:55:32 GMT, Matthias Baesken wrote: > Some exception/error message changed with 8299470 so we have to adjust the test. > Current error is > > Unexpected error 'Successor argument without leading - is expected for 'd' but we got '-c'' > java.lang.RuntimeException: Bad option test 4 failed > at SAGetoptTest.badOptionsTest(SAGetoptTest.java:124) > at SAGetoptTest.main(SAGetoptTest.java:149) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125) > at java.base/java.lang.Thread.run(Thread.java:1623) Looks good and trivial. I assume you verified that the test is fixed now. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.org/jdk/pull/11860 From mbaesken at openjdk.org Thu Jan 5 09:34:57 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Jan 2023 09:34:57 GMT Subject: RFR: JDK-8299657: sun/tools/jhsdb/SAGetoptTest.java fails after 8299470 In-Reply-To: <3I_VXTEXKOXBIBw9LFmd_qYEm3eA4_xRx-RzcoDqg44=.408773f2-6e46-4948-ba68-10256fcfe633@github.com> References: <3I_VXTEXKOXBIBw9LFmd_qYEm3eA4_xRx-RzcoDqg44=.408773f2-6e46-4948-ba68-10256fcfe633@github.com> Message-ID: <8FZ1m9bf9qRCzeW5lY3LpBejelmKA85KpuaAU12RQNo=.ed2b705c-be3e-4e9d-9bc7-1decba4fcde6@github.com> On Thu, 5 Jan 2023 08:55:32 GMT, Matthias Baesken wrote: > Some exception/error message changed with 8299470 so we have to adjust the test. > Current error is > > Unexpected error 'Successor argument without leading - is expected for 'd' but we got '-c'' > java.lang.RuntimeException: Bad option test 4 failed > at SAGetoptTest.badOptionsTest(SAGetoptTest.java:124) > at SAGetoptTest.main(SAGetoptTest.java:149) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125) > at java.base/java.lang.Thread.run(Thread.java:1623) Hi Christoph, thanks for the review ! Yes I tested it , works now on linux x86_64 . ------------- PR: https://git.openjdk.org/jdk/pull/11860 From mbaesken at openjdk.org Thu Jan 5 09:34:58 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 5 Jan 2023 09:34:58 GMT Subject: Integrated: JDK-8299657: sun/tools/jhsdb/SAGetoptTest.java fails after 8299470 In-Reply-To: <3I_VXTEXKOXBIBw9LFmd_qYEm3eA4_xRx-RzcoDqg44=.408773f2-6e46-4948-ba68-10256fcfe633@github.com> References: <3I_VXTEXKOXBIBw9LFmd_qYEm3eA4_xRx-RzcoDqg44=.408773f2-6e46-4948-ba68-10256fcfe633@github.com> Message-ID: <5FL7UuRvaHIn_FGpvDPS0SQ_KPO6jBt9-F19IGZ96l8=.a5220107-1070-4e8c-ad7c-06d20fb2b021@github.com> On Thu, 5 Jan 2023 08:55:32 GMT, Matthias Baesken wrote: > Some exception/error message changed with 8299470 so we have to adjust the test. > Current error is > > Unexpected error 'Successor argument without leading - is expected for 'd' but we got '-c'' > java.lang.RuntimeException: Bad option test 4 failed > at SAGetoptTest.badOptionsTest(SAGetoptTest.java:124) > at SAGetoptTest.main(SAGetoptTest.java:149) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125) > at java.base/java.lang.Thread.run(Thread.java:1623) This pull request has now been integrated. Changeset: 1ca31d34 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/1ca31d34fcba5e9861104402466b5dd4cccdbafd Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8299657: sun/tools/jhsdb/SAGetoptTest.java fails after 8299470 Reviewed-by: clanger ------------- PR: https://git.openjdk.org/jdk/pull/11860 From yyang at openjdk.org Thu Jan 5 11:50:51 2023 From: yyang at openjdk.org (Yi Yang) Date: Thu, 5 Jan 2023 11:50:51 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Thu, 5 Jan 2023 05:44:23 GMT, David Holmes wrote: >> Good suggestion. >> However, I wonder why the `fd` is casted from `long` to `int` on Unix. The Unix versions of SocketInputStream had `int fd`. >> So, the following code also needs to cast `fd` to `int`: >> >> + public synchronized int read(byte[] bs, int off, int len) throws IOException { >> + if ((off < 0) || (off > bs.length) || (len < 0) || >> + ((off + len) > bs.length) || ((off + len) < 0)) { >> + throw new IndexOutOfBoundsException(); >> + } else if (len == 0) { >> + return 0; >> + } >> + return read(fd, bs, off, len); <== ??? >> + } >> + >> + public synchronized void close() throws IOException { >> + if (fd != -1) { >> + close(fd); <== ??? >> + } > > Looks like Windows needs a long fd so the shared API takes long and we then cast to int for the Unix native methods. A little messy but fixable. > If you add read/close methods for Windows that then call readPipe/closePipe, then we don't need to subclass and override. Sorry, I don't understand what this means. VirtualMachineImpl is platform-dependent while HotSpotVirtualMachine is shared, we always need to sub-class socket input stream in order to call platform-depend read/close. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From rehn at openjdk.org Thu Jan 5 18:28:55 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 5 Jan 2023 18:28:55 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:56:40 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable Looks fine, thanks. (+- DavidH comment) ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Thu Jan 5 21:47:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 5 Jan 2023 21:47:54 GMT Subject: RFR: JDK-8299470: sun/jvm/hotspot/SALauncher.java handling of negative rmiport args [v5] In-Reply-To: References: Message-ID: On Wed, 4 Jan 2023 15:30:10 GMT, Matthias Baesken wrote: >> The test serviceability/sa/sadebugd/SADebugDTest.java can pass under some circumstances a negative rmiport (--rmiport -1) to SALauncher.java. >> This leads to a somewhat misleading message >> `[debugd] Argument is expected for 'rmiport' ` >> (we set an argument [-1] but probably this is not what is really expected) and additionally the real exception is not shown. >> Probably also a warning in case of negative rmiport values should be printed because they seem to lead to errors. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Small output adjustments This change has introduced a test failure in our tier 5 CI testing: https://bugs.openjdk.org/browse/JDK-8299700 I missed an issue had already been filed for the failure. ------------- PR: https://git.openjdk.org/jdk/pull/11811 From duke at openjdk.org Fri Jan 6 02:45:18 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 02:45:18 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor Message-ID: This PR adds a new lint warning category `this-escape`. It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) * Some constructor `B()` of `B` invokes `A()` as its superclass constructor * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. **Patch Navigation Guide** * Non-trivial compiler changes: * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` * Javadoc additions of `@implNote`: * `src/java.base/share/classes/java/io/PipedReader.java` * `src/java.base/share/classes/java/io/PipedWriter.java` * `src/java.base/share/classes/java/lang/Throwable.java` * `src/java.base/share/classes/java/util/ArrayDeque.java` * `src/java.base/share/classes/java/util/EnumMap.java` * `src/java.base/share/classes/java/util/HashSet.java` * `src/java.base/share/classes/java/util/Hashtable.java` * `src/java.base/share/classes/java/util/LinkedList.java` * `src/java.base/share/classes/java/util/TreeMap.java` * `src/java.base/share/classes/java/util/TreeSet.java` * New unit tests * `test/langtools/tools/javac/warnings/ThisEscape/*.java` * **Everything else** is just adding `@SuppressWarnings("this-escape")` ------------- Commit messages: - Remove trailing whitespace. - Some documentation tweaks. - Treat method references like the equivalent lambda. - Fix bug where initializers could generate duplicate warnings. - Javadoc fix. - Add ThisEscape.html doc note and link the new @implNote's to it. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - Add more @SuppressWarnings("this-escape") annotations. - ... and 38 more: https://git.openjdk.org/jdk/compare/c6588d5b...9c162283 Changes: https://git.openjdk.org/jdk/pull/11874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8015831 Stats: 4326 lines in 1285 files changed: 4259 ins; 3 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Fri Jan 6 04:51:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 6 Jan 2023 04:51:00 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Hi Archie, The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Fri Jan 6 05:52:51 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 6 Jan 2023 05:52:51 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Thu, 5 Jan 2023 11:47:56 GMT, Yi Yang wrote: >> Looks like Windows needs a long fd so the shared API takes long and we then cast to int for the Unix native methods. A little messy but fixable. > >> If you add read/close methods for Windows that then call readPipe/closePipe, then we don't need to subclass and override. > > Sorry, I don't understand what this means. VirtualMachineImpl is platform-dependent while HotSpotVirtualMachine is shared, we always need to sub-class socket input stream in order to call platform-depend read/close. As long as all the platform-specific `VirtualMachineImpl` classes define a `read` and `close` method then we can simply have the shared socket stream class call those methods. Windows will need an extra level of indirection because its `read` method will have to call `readPipe`. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Fri Jan 6 06:42:50 2023 From: yyang at openjdk.org (Yi Yang) Date: Fri, 6 Jan 2023 06:42:50 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Fri, 6 Jan 2023 05:50:05 GMT, David Holmes wrote: > As long as all the platform-specific `VirtualMachineImpl` classes define a `read` and `close` method then we can simply have the shared socket stream class call those methods. Windows will need an extra level of indirection because its `read` method will have to call `readPipe`. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From alanb at openjdk.org Fri Jan 6 07:53:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 07:53:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` This looks like a very useful lint warning to have but this PR is unwieldy. If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From kevinw at openjdk.org Fri Jan 6 11:19:48 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 6 Jan 2023 11:19:48 GMT Subject: RFR: 8299234: JMX Repository.query performance In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 18:50:52 GMT, Alexey Bakhtin wrote: > Please find a patch to improve JMX Repository.query performance > > Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: > Before: > > $ java test 1000000 1000000 > Test PASSED in 8943169791 ns. > GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 > > > After: > > $ java test 1000000 1000000 > Test PASSED in 4808213917 ns. > GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 > > Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. > > All javax/management jtreg tests passed successfully. Hi, Speedup sounds good. So we don't need the ObjectNamePattern class, and it's private so no dependencies. I haven't fully followed the wildcard matching changes yet. Will try and do some testing also. ------------- PR: https://git.openjdk.org/jdk/pull/11758 From kevinw at openjdk.org Fri Jan 6 13:19:22 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 6 Jan 2023 13:19:22 GMT Subject: RFR: 8299112: HashedPasswordFileTest.java and ExceptionTest.java fails with java.lang.NullPointerException Message-ID: Exceptions during setup of these tests could leave e.g. JMXConnector cs as null. But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure. We must only call close if this is not null. ------------- Commit messages: - 8299112: HashedPasswordFileTest.java and ExceptionTest.java fails with java.lang.NullPointerException Changes: https://git.openjdk.org/jdk/pull/11881/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11881&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299112 Stats: 18 lines in 2 files changed: 9 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11881.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11881/head:pull/11881 PR: https://git.openjdk.org/jdk/pull/11881 From coleenp at openjdk.org Fri Jan 6 14:15:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 6 Jan 2023 14:15:56 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 01:57:27 GMT, David Holmes wrote: >> I agree that this is ambigious. The `jvmtiTagMap` calls `add/update` methods of `jvmtiTagMapTable` which in turn calls `resourceHashTable` methods `put` and `put_if_absent`. >> `put` and `put_if_absent` can be used for both adding and updating and reporting it in returned values. >> `jvmtiTagMap` calls to `jvmtiTagMapTable` add/update DO NOT CARE about the returned values. For these calls, it doesn't mater if an add (update) method resulted in an update (add). >> So which one of the following cases would be correct? >> - Based on the `jvmtiTagMap` calls, let the add/update be void and ignore the differences of what really happens in the table. Or >> - Based on the `resourceHashTable` bool-valued `put` and `put_if_absent` methods, let the add/update be bool-values and leave the decision on "what really happened in the table" to the callers in `jvmtiTagMap`. (current implementation) > > The issue is not the underlying RHT methods but the semantics of the `jvmtiTagMap` methods. If a call to add always expects to add then it should be a fatal error if it actually did an update as that indicates something is broken. Similarly if an update actually does an add. The JvmtiTagMap code adds/updates and removes the entries like below in two places which could probably be simplified, but I think that's outside the scope of this RFE. I suggest removing the bool return from add, remove and update, and add the assert(true) in the remove case. There's already an assert that add/update happened in the other cases. ``` // if the object is not already tagged then we tag it if (found_tag == 0) { if (tag != 0) { hashmap->add(o, tag); } else { // no-op } } else { // if the object is already tagged then we either update // the tag (if a new tag value has been provided) // or remove the object if the new tag value is 0. if (tag == 0) { hashmap->remove(o); } else { hashmap->update(o, tag); } } ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Fri Jan 6 14:51:54 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 14:51:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 04:48:27 GMT, David Holmes wrote: > The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? Hi @dholmes-ora, The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. > If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. Hi @AlanBateman, As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. > I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? If this is generally agreed as a better route then let me know and I'll update the patch. Thanks for both of your comments. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From alanb at openjdk.org Fri Jan 6 15:41:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 6 Jan 2023 15:41:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 14:49:16 GMT, Archie L. Cobbs wrote: > Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? > > If this is generally agreed as a better route then let me know and I'll update the patch. Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Fri Jan 6 15:57:50 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 6 Jan 2023 15:57:50 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman wrote: >>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? >> >> Hi @dholmes-ora, >> >> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. >> >> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. >> >> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. >> >>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. >> >> Hi @AlanBateman, >> >> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. >> >>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. >> >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. >> >> Thanks for both of your comments. > >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. > > Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. I agree with @AlanBateman. When we introduced similar warnings in the past, we have enabled support in javac (with some test) in a separate PR, and then followed up with small dedicated PR for each of the various areas (enabling new warnings one by one). See this great umbrella JBS issue (created by @asotona) which has details on all the issues that were filed when we added an extra Lint warning for lossy conversions: https://bugs.openjdk.org/browse/JDK-8286374 They all refer to this: https://bugs.openjdk.org/browse/JDK-8244681 Which was submitted as a separate javac-only PR: https://github.com/openjdk/jdk/pull/8599 ------------- PR: https://git.openjdk.org/jdk/pull/11874 From sspitsyn at openjdk.org Fri Jan 6 17:48:52 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 6 Jan 2023 17:48:52 GMT Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java can fail with java.lang.NullPointerException In-Reply-To: References: Message-ID: <4am0cKTtgvOUXiVcrcVpeRZ0lw0yDhbMBua7AejtBmA=.7edac3f6-56b5-4dc1-b1e0-eeebb9eefa79@github.com> On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls wrote: > Exceptions during setup of these tests could leave e.g. JMXConnector cs as null. > But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure. > We must only call close if this is not null. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11881 From cjplummer at openjdk.org Fri Jan 6 18:52:58 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 6 Jan 2023 18:52:58 GMT Subject: Integrated: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 02:04:01 GMT, Chris Plummer wrote: > There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. > > I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. This pull request has now been integrated. Changeset: d6e9f015 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/d6e9f01584ef84d6390c356fd3b342d9d79899ab Stats: 31 lines in 3 files changed: 6 ins; 25 del; 0 mod 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads 8282383: [LOOM] 6 nsk JDI and JDB tests sometimes failing with vthread wrapper due to running out of carrier threads Reviewed-by: dholmes, sspitsyn, alanb, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/11735 From cjplummer at openjdk.org Fri Jan 6 19:14:50 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 6 Jan 2023 19:14:50 GMT Subject: RFR: 8299739: HashedPasswordFileTest.java and ExceptionTest.java can fail with java.lang.NullPointerException In-Reply-To: References: Message-ID: <0-cc5qcwvvB385rZYtIXAdzWPLApYZqxGgI1r9P2KVU=.abc27141-122e-4fcb-a893-3f7f2cee122d@github.com> On Fri, 6 Jan 2023 13:11:41 GMT, Kevin Walls wrote: > Exceptions during setup of these tests could leave e.g. JMXConnector cs as null. > But, we call cs.close() during a finally block and fail with an NPE, obscuring the real failure. > We must only call close if this is not null. I looks like ExceptionTest.java does log the exception before hitting the NPE. Were you not seeing it in the log? ------------- PR: https://git.openjdk.org/jdk/pull/11881 From cjplummer at openjdk.org Fri Jan 6 22:04:53 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 6 Jan 2023 22:04:53 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Thu, 5 Jan 2023 03:32:21 GMT, Yi Yang wrote: >> harmless refactor to share code across different platforms of VirtualMachineImpl: >> 1. Shared code to process command response after requesting a command execution >> 2. Read functionality in SocketInputStream can be reused > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > add doc; readImpl/closeImpl to read/close I would also like to request that the variable renames be omitted from this PR. They create too much noise and would best left to a PR that focuses on just the renames and possibly other style changes. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From cjplummer at openjdk.org Fri Jan 6 22:15:51 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 6 Jan 2023 22:15:51 GMT Subject: RFR: 8299593: getprotobyname should not be used In-Reply-To: <8nFkW5weDqgQxZbKi5LZjwlRnc7mdME5QHWbwi6MgFM=.70eb5c32-6c00-4e10-b7f5-6a2d28b69b71@github.com> References: <8nFkW5weDqgQxZbKi5LZjwlRnc7mdME5QHWbwi6MgFM=.70eb5c32-6c00-4e10-b7f5-6a2d28b69b71@github.com> Message-ID: On Wed, 4 Jan 2023 12:56:18 GMT, Daniel Jeli?ski wrote: > Please review this patch that removes the remaining uses of non-reentrant `getprotobyname` function. > > While the protocol number for TCP could theoretically be modified to something other than the default `IPPROTO_TCP`, that scenario would likely not work, and is not something that we are willing to support. [Existing code](https://github.com/openjdk/jdk/blob/2f3f3b618500b5f112fabca30d4c6780b2a8e723/src/java.base/unix/native/libnet/net_util_md.c#L355) in networking area is using `IPPROTO_TCP` for `TCP_NODELAY`, and no issues were reported. > > Tier 1-3 tests still pass. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/11842 From duke at openjdk.org Fri Jan 6 23:13:09 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 23:13:09 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v2] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year for newly added files to 2023. - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/9c162283..f667cd56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=00-01 Stats: 1935 lines in 1303 files changed: 60 ins; 1770 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 6 23:13:09 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 6 Jan 2023 23:13:09 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 15:38:31 GMT, Alan Bateman wrote: >>> The associated JBS issue has been dormant for 6+ years and this is a very intrusive change affecting many, many files. Has the resurrection of this project previously been discussed somewhere? >> >> Hi @dholmes-ora, >> >> The work to add this warning has been guided by @briangoetz in discussions on the amber-dev mailing list. See that thread for how we came up with the current design, underlying motivation, etc. >> >> Regarding intrusiveness (assuming you're referring simply to the number of files touched), as mentioned this was one of two options. The other option would be to patch to about ~30 `Java.gmk` files in `make/modules` to exclude `this-escape` from `-Xlint` during the various module builds. >> >> Going this route is fine with me, but it has the downside that any new code being developed would not benefit from the new warning. This was in fact my original approach (and it was a lot easier :) but Brian rightly pointed out that adding `@SuppressWarnings` annotations was the the safer (i.e, more conservative) approach. >> >>> If you haven't done so already then you probably should socialize on compiler-dev and get agreement on the semantics and other details. >> >> Hi @AlanBateman, >> >> As mentioned this has been under discussion on amber-dev for a while. Happy to continue that discussion here as well. >> >>> I think you will also need to separate the addition of the lint warning from the changes to the wider JDK. It might be okay to add the feature but have it disabled for the JDK build initially. >> >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. >> >> Thanks for both of your comments. > >> Sounds reasonable... so I take it you would also be in favor of patching `make/modules` instead of adding `@SuppressWarnings` annotations everywhere... is that correct? >> >> If this is generally agreed as a better route then let me know and I'll update the patch. > > Yes, I think that would be better. It would remove most of the noise, 1200+ files, and 10+ mailing lists from this PR. I assume there will be at least some iteration on compiler-dev about the details and changes to javac. Once you get to the JDK changes then I suspect that some areas may want to fix issues rather than adding SW. Sadly, I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. Also we have places that register themselves to cleaners. I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. Hi @AlanBateman, OK that sounds like a plan. I've pushed a new commit to the `ThisEscape` branch that removes all the`@SuppressWarnings` annotations and replaces them with adjustments to build flags. I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch. > I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. Hmm. Hasn't that horse already left the barn? You kind of implied that when you said: > I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior. Of course I'd love to be wrong... in which case, we can fix these constructors. Or, the third option - just do nothing yet. That would mean removing the warnings, which is fine. But then the `ThisEscape.html` document is orphaned. What should we do with it? I can remove it, just leave it there, or put it somewhere else (where?). It seems like having some documentation of the meaning of "this escape" would be helpful, because it's a subtle concept and there are multiple ways to define "escape". Thanks. @mcimadamore thanks for the bugs suggestion, I'll put that on the to-do list. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Sat Jan 7 16:24:56 2023 From: duke at openjdk.org (ExE Boss) Date: Sat, 7 Jan 2023 16:24:56 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v2] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:13:09 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year for newly added files to 2023. > - Suppress "this-escape" warnings using build flags instead of @SuppressAnnotations annotations. src/java.base/share/classes/java/lang/AssertionError.java line 75: > 73: */ > 74: @SuppressWarnings("this-escape") > 75: public AssertionError(Object detailMessage) { The?Javadoc of?this?constructor should?probably?mention that?it?calls `initCause(?)` when?`detailMessage` is?a?`Throwable`. src/java.base/share/classes/java/lang/BootstrapMethodError.java line 77: > 75: * Constructs a {@code BootstrapMethodError} with the specified > 76: * cause. > 77: * Suggestion: * * @implNote This constructor invokes {@link #initCause initCause()}; see * This Escape. * src/java.base/share/classes/java/lang/ExceptionInInitializerError.java line 54: > 52: * throwable object. > 53: * A detail message is a String that describes this particular exception. > 54: */ Suggestion: * * @implNote This constructor invokes {@link #initCause initCause()}; see * This Escape. */ ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Sat Jan 7 16:58:58 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 7 Jan 2023 16:58:58 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v3] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add a few more Javadoc warnings for 'this' escape via initCause(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/f667cd56..398737fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=01-02 Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From alanb at openjdk.org Sat Jan 7 18:05:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 7 Jan 2023 18:05:50 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 23:08:27 GMT, Archie L. Cobbs wrote: > I've moved the `@SuppressWarnings` annotations onto a new branch `ThisEscapeAnnotations`. This is just for future reference in case somebody wants to add them back someday and doesn't want to start from scratch. > > > I suspect some of the suggestions to document leaking this in implNotes will need discussion too because they amount to documenting "hooks" that people will rely on, e.g. documenting in ArrayDeque that its constructor invokes addList could be read as an invite to override it. > > Hmm. Hasn't that horse already left the barn? You kind of implied that when you said: > > > I see a few examples in your list where there have been attempts to avoid leaking "this" but where we backed away out of concern that 3rd party code was extending some class and overriding a method known to be invoked by the constructor. > > In other words, it doesn't sound like changing the behavior of these constructors is viable option at this point. And if that's the case, we might as well document and warn about the current behavior. > > Of course I'd love to be wrong... in which case, we can fix these constructors. I hope at least some of these can be fixed as leaking a part initialized object to an untrusted subclass or some other code is problematic in many ways. Skimming through the original list, then some of these may be accidental and some may be fixable without any compatibility concerns, esp. in the JDK internal classes. Yes, some horses have left the barn. A horse that got out a long time ago is j.net.ServerSocket where 3 of its constructors call an overridable bind method. Recent re-implementation would have fixed this but there were concerns that subclasses may be relying on this long standing undocumented behavior. There are other cases in the list where the leaking may be necessary part of the contract for subclasses. So it will probably require working through them on a case by case basis. I don't think the implementation notes should be included as part of the adding the lint warning as I think it creates an attractive nuisance. Developers reading these implementation notes may c reate code that depends on these "hooks" and it will make it very hard for the JDK to ever change the behavior. Where the leaking is a necessary part of the contract for subclassing then it may be that it has to be documented as normative text rather than an implementation note. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Sat Jan 7 19:52:49 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 7 Jan 2023 19:52:49 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor In-Reply-To: References: Message-ID: On Sat, 7 Jan 2023 18:03:04 GMT, Alan Bateman wrote: > I don't think the implementation notes should be included as part of the adding the lint warning as I think it creates an attractive nuisance. I agree with you - not only for that reason, but also because as others have pointed out the addition of the warning is really a separate task from the evaluation and triage of any existing leaks. Moreover, this latter task is really multiple separate tasks that belong to the various module/functional groups. I'll remove all the Javadoc `@implNote`'s from the patch, and `src/java.base/share/classes/java/lang/doc-files/ThisEscape.html` as well - it will still be available in the git history if someone comes up with a better home for it. This will also further reduce the number of labels and therefore required reviewers. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Sat Jan 7 19:59:59 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 7 Jan 2023 19:59:59 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v4] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Remove Javadoc @implNotes; plan to triage the various existing leaks separately. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/398737fa..537b3e3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=02-03 Stats: 255 lines in 29 files changed: 0 ins; 251 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Sat Jan 7 21:08:07 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 7 Jan 2023 21:08:07 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: Message-ID: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Fix incorrect @bug numbers in unit tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/537b3e3c..7e2fdb07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=03-04 Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From yyang at openjdk.org Mon Jan 9 03:29:04 2023 From: yyang at openjdk.org (Yi Yang) Date: Mon, 9 Jan 2023 03:29:04 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v4] In-Reply-To: References: Message-ID: > harmless refactor to share code across different platforms of VirtualMachineImpl: > 1. Shared code to process command response after requesting a command execution > 2. Read functionality in SocketInputStream can be reused Yi Yang has updated the pull request incrementally with two additional commits since the last revision: - describe parameter - Revert "separate renaming" This reverts commit cb700000ac62fdfa605ed4f9e415c4ab73bfc8a3. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11823/files - new: https://git.openjdk.org/jdk/pull/11823/files/0580ab2d..e9d8c36f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=02-03 Stats: 69 lines in 4 files changed: 2 ins; 0 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/11823.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11823/head:pull/11823 PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Mon Jan 9 03:29:04 2023 From: yyang at openjdk.org (Yi Yang) Date: Mon, 9 Jan 2023 03:29:04 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Fri, 6 Jan 2023 22:01:45 GMT, Chris Plummer wrote: > I would also like to request that the variable renames be omitted from this PR. They create too much noise and would best left to a PR that focuses on just the renames and possibly other style changes. Okay, reverted. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Mon Jan 9 03:29:05 2023 From: yyang at openjdk.org (Yi Yang) Date: Mon, 9 Jan 2023 03:29:05 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v4] In-Reply-To: References: <1VQLsrRR0G1alxt-codhC7fDPc6_NZE1iGGF7JMaCsI=.64cb2589-810d-4f43-962f-e5dc07b936ca@github.com> Message-ID: On Thu, 5 Jan 2023 04:28:46 GMT, David Holmes wrote: > I was thinking more about describing what the parameters are - in particular it is unclear why the actual IOE can be replaced by a passed in one. If we wanted a custom message then I would at least expect to chain the actual IOE to the replacement. Done. Parameter ioe means if we get IOE during previous command execution, delay throwing it until command execution completion status has been read. Since all other parameters are straightforward and this is a private method, I don't write strandard `@param` descriptions for them. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From dholmes at openjdk.org Mon Jan 9 06:39:52 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jan 2023 06:39:52 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Sat, 7 Jan 2023 21:08:07 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect @bug numbers in unit tests. All your new files need a copyright and GPL header. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Mon Jan 9 07:41:52 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 9 Jan 2023 07:41:52 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v3] In-Reply-To: References: <-ZcyQiQCsmuKy1ajfGQKFJHz0pnlTM1zvjAV0WgDQ2M=.7d4734f2-05d6-4473-8b51-319fa82f43ae@github.com> Message-ID: On Fri, 6 Jan 2023 06:38:46 GMT, Yi Yang wrote: >> As long as all the platform-specific `VirtualMachineImpl` classes define a `read` and `close` method then we can simply have the shared socket stream class call those methods. Windows will need an extra level of indirection because its `read` method will have to call `readPipe`. > >> As long as all the platform-specific `VirtualMachineImpl` classes define a `read` and `close` method then we can simply have the shared socket stream class call those methods. Windows will need an extra level of indirection because its `read` method will have to call `readPipe`. That is unfortunate. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From djelinski at openjdk.org Mon Jan 9 07:39:57 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 9 Jan 2023 07:39:57 GMT Subject: Integrated: 8299593: getprotobyname should not be used In-Reply-To: <8nFkW5weDqgQxZbKi5LZjwlRnc7mdME5QHWbwi6MgFM=.70eb5c32-6c00-4e10-b7f5-6a2d28b69b71@github.com> References: <8nFkW5weDqgQxZbKi5LZjwlRnc7mdME5QHWbwi6MgFM=.70eb5c32-6c00-4e10-b7f5-6a2d28b69b71@github.com> Message-ID: On Wed, 4 Jan 2023 12:56:18 GMT, Daniel Jeli?ski wrote: > Please review this patch that removes the remaining uses of non-reentrant `getprotobyname` function. > > While the protocol number for TCP could theoretically be modified to something other than the default `IPPROTO_TCP`, that scenario would likely not work, and is not something that we are willing to support. [Existing code](https://github.com/openjdk/jdk/blob/2f3f3b618500b5f112fabca30d4c6780b2a8e723/src/java.base/unix/native/libnet/net_util_md.c#L355) in networking area is using `IPPROTO_TCP` for `TCP_NODELAY`, and no issues were reported. > > Tier 1-3 tests still pass. This pull request has now been integrated. Changeset: d03a5d95 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/d03a5d9580ef3b9be4d766ff9a11d6fd5fa133f9 Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod 8299593: getprotobyname should not be used Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/11842 From aturbanov at openjdk.org Mon Jan 9 08:00:55 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 9 Jan 2023 08:00:55 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v4] In-Reply-To: References: Message-ID: <1yKrAu4ZwIuECCfzZH4aecxGyvE-fgIagcw92-bFg5Q=.b75e6219-7cf6-457c-8ae8-7ba0a82a5924@github.com> On Mon, 9 Jan 2023 03:29:04 GMT, Yi Yang wrote: >> harmless refactor to share code across different platforms of VirtualMachineImpl: >> 1. Shared code to process command response after requesting a command execution >> 2. Read functionality in SocketInputStream can be reused > > Yi Yang has updated the pull request incrementally with two additional commits since the last revision: > > - describe parameter > - Revert "separate renaming" > > This reverts commit cb700000ac62fdfa605ed4f9e415c4ab73bfc8a3. src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 422: > 420: * InputStream for the socket connection to get target VM > 421: */ > 422: static abstract class SocketInputStream extends InputStream { Use blessed modifiers order Suggestion: abstract static class SocketInputStream extends InputStream { ------------- PR: https://git.openjdk.org/jdk/pull/11823 From yyang at openjdk.org Mon Jan 9 13:25:34 2023 From: yyang at openjdk.org (Yi Yang) Date: Mon, 9 Jan 2023 13:25:34 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v5] In-Reply-To: References: Message-ID: > harmless refactor to share code across different platforms of VirtualMachineImpl: > 1. Shared code to process command response after requesting a command execution > 2. Read functionality in SocketInputStream can be reused Yi Yang has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11823/files - new: https://git.openjdk.org/jdk/pull/11823/files/e9d8c36f..9d6aa99f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11823.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11823/head:pull/11823 PR: https://git.openjdk.org/jdk/pull/11823 From duke at openjdk.org Mon Jan 9 14:03:54 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 9 Jan 2023 14:03:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Mon, 9 Jan 2023 06:37:22 GMT, David Holmes wrote: > All your new files need a copyright and GPL header. Sorry if I'm being blind but I'm not seeing it. Which file(s) are you referring to? The `@test /nodynamiccopyright/` files don't get one per [this](https://openjdk.org/groups/compiler/tests.html#gold). ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Mon Jan 9 14:46:43 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Mon, 9 Jan 2023 14:46:43 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames Message-ID: Implementation of relativized locals in interpreter frames for x86. x64, aarch64, ppc64le, riscv. Not relativized zero and s390 but done some changes to cope with the changed generic code. Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu. ------------- Commit messages: - Changed copyright date to 2023 - 8299795: Relativize locals in interpreter frames Changes: https://git.openjdk.org/jdk/pull/11902/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299795 Stats: 227 lines in 40 files changed: 107 ins; 17 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From kbarrett at openjdk.org Mon Jan 9 14:46:49 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 9 Jan 2023 14:46:49 GMT Subject: RFR: 8299701: Remove unused GCCause::_wb_conc_mark Message-ID: Please review this change to remove GCCause::_wb_conc_mark and the supporting implementation. After JDK-8293824 it is no longer used as the cause when requesting a GC. Note: The implementation in ZGC appears to have never been used. Prior to JDK-8293824 this cause was only used by a G1-specific WB function. (In the deep mists of time it might have also been used to trigger a CMS concurrent cycle; I didn't bother looking into that.) Testing: mach5 tier1 ------------- Commit messages: - remove GCCause::_wb_conc_mark Changes: https://git.openjdk.org/jdk/pull/11893/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11893&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299701 Stats: 19 lines in 6 files changed: 0 ins; 11 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11893.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11893/head:pull/11893 PR: https://git.openjdk.org/jdk/pull/11893 From eosterlund at openjdk.org Mon Jan 9 15:04:52 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 9 Jan 2023 15:04:52 GMT Subject: RFR: 8299701: Remove unused GCCause::_wb_conc_mark In-Reply-To: References: Message-ID: <2HulfQEXcnB_eV5unX7gmemBlBi_NnC2ilCGo3zlqKM=.1c529d37-e23b-49a3-b912-9ad62e812f81@github.com> On Sat, 7 Jan 2023 17:41:04 GMT, Kim Barrett wrote: > Please review this change to remove GCCause::_wb_conc_mark and the supporting > implementation. After JDK-8293824 it is no longer used as the cause when > requesting a GC. > > Note: The implementation in ZGC appears to have never been used. Prior to > JDK-8293824 this cause was only used by a G1-specific WB function. (In the > deep mists of time it might have also been used to trigger a CMS concurrent > cycle; I didn't bother looking into that.) > > Testing: > mach5 tier1 Looks good. Just one small nit. src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 256: > 254: // (c) cause == _dcmd_gc_run and +ExplicitGCInvokesConcurrent, > 255: // (d) cause == _wb_breakpoint, > 256: // (e) cause == _g1_periodic_collection and +G1PeriodicGCInvokesConcurrent. I suppose (e) should be (d) now. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/11893 From eosterlund at openjdk.org Mon Jan 9 15:04:54 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 9 Jan 2023 15:04:54 GMT Subject: RFR: 8299701: Remove unused GCCause::_wb_conc_mark In-Reply-To: <2HulfQEXcnB_eV5unX7gmemBlBi_NnC2ilCGo3zlqKM=.1c529d37-e23b-49a3-b912-9ad62e812f81@github.com> References: <2HulfQEXcnB_eV5unX7gmemBlBi_NnC2ilCGo3zlqKM=.1c529d37-e23b-49a3-b912-9ad62e812f81@github.com> Message-ID: On Mon, 9 Jan 2023 14:50:50 GMT, Erik ?sterlund wrote: >> Please review this change to remove GCCause::_wb_conc_mark and the supporting >> implementation. After JDK-8293824 it is no longer used as the cause when >> requesting a GC. >> >> Note: The implementation in ZGC appears to have never been used. Prior to >> JDK-8293824 this cause was only used by a G1-specific WB function. (In the >> deep mists of time it might have also been used to trigger a CMS concurrent >> cycle; I didn't bother looking into that.) >> >> Testing: >> mach5 tier1 > > src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 256: > >> 254: // (c) cause == _dcmd_gc_run and +ExplicitGCInvokesConcurrent, >> 255: // (d) cause == _wb_breakpoint, >> 256: // (e) cause == _g1_periodic_collection and +G1PeriodicGCInvokesConcurrent. > > I suppose (e) should be (d) now. ...never mind my nit, it looks right already. ------------- PR: https://git.openjdk.org/jdk/pull/11893 From iwalulya at openjdk.org Mon Jan 9 16:55:51 2023 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 9 Jan 2023 16:55:51 GMT Subject: RFR: 8299701: Remove unused GCCause::_wb_conc_mark In-Reply-To: References: Message-ID: On Sat, 7 Jan 2023 17:41:04 GMT, Kim Barrett wrote: > Please review this change to remove GCCause::_wb_conc_mark and the supporting > implementation. After JDK-8293824 it is no longer used as the cause when > requesting a GC. > > Note: The implementation in ZGC appears to have never been used. Prior to > JDK-8293824 this cause was only used by a G1-specific WB function. (In the > deep mists of time it might have also been used to trigger a CMS concurrent > cycle; I didn't bother looking into that.) > > Testing: > mach5 tier1 Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11893 From cjplummer at openjdk.org Mon Jan 9 20:43:55 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 9 Jan 2023 20:43:55 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v5] In-Reply-To: References: Message-ID: <4ql1Po1S5ZJnsL_ytIfnO3oVvkCZz2uazDpyr8Ju7dE=.72d9de0a-02e4-4cfb-a5a1-2425d1c54b1d@github.com> On Mon, 9 Jan 2023 13:25:34 GMT, Yi Yang wrote: >> harmless refactor to share code across different platforms of VirtualMachineImpl: >> 1. Shared code to process command response after requesting a command execution >> 2. Read functionality in SocketInputStream can be reused > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java > > Co-authored-by: Andrey Turbanov src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 61: > 59: int pid = Integer.parseInt(vmid); > 60: if (pid < 1) { > 61: throw new AttachNotSupportedException("Invalid process identifier -1"); Why the change to using -1 instead of `vmid`? It seems presumptuous that it is -1, and also seems less useful than printing `vmid`. ------------- PR: https://git.openjdk.org/jdk/pull/11823 From sspitsyn at openjdk.org Mon Jan 9 23:17:55 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 9 Jan 2023 23:17:55 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: <55O_xJx412kcO8MhN5FF7iKHxHsh-aDVyNicIi7oeHM=.9d261cd0-7d22-4931-8c7f-e1fee9d4a4a4@github.com> On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn wrote: >> This problem has two sides. >> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. >> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` >> value has been set to `true` when an agent library is loaded into running VM. >> The fix is to get rid of this cashing. >> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. >> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. >> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. >> >> Testing: >> The originally failed tests are passed now: >> >> runtime/vthread/RedefineClass.java >> runtime/vthread/TestObjectAllocationSampleEvent.java >> >> In progress: >> Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove caching if notifyJvmtiEvents in yieldContinuation One more artificial comment to keep the PR alive. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From yyang at openjdk.org Tue Jan 10 10:49:52 2023 From: yyang at openjdk.org (Yi Yang) Date: Tue, 10 Jan 2023 10:49:52 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v6] In-Reply-To: References: Message-ID: <27esMViORNgCNjS04-6IJfCHcva5NmbCZ3p6yYP2OjQ=.2e294967-6467-4a07-b9b7-004545a9584b@github.com> > harmless refactor to share code across different platforms of VirtualMachineImpl: > 1. Shared code to process command response after requesting a command execution > 2. Read functionality in SocketInputStream can be reused Yi Yang has updated the pull request incrementally with three additional commits since the last revision: - format - Merge branch 'jdk_virtualmachienimpl' of github.com:y1yang0/jdk into jdk_virtualmachienimpl - -1 to vmid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11823/files - new: https://git.openjdk.org/jdk/pull/11823/files/9d6aa99f..6077ae5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11823&range=04-05 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11823.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11823/head:pull/11823 PR: https://git.openjdk.org/jdk/pull/11823 From ayang at openjdk.org Tue Jan 10 10:59:35 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 10 Jan 2023 10:59:35 GMT Subject: RFR: 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space Message-ID: Simple change of using the actual type for a field. Test: hotspot_gc ------------- Commit messages: - s1-tenured-space Changes: https://git.openjdk.org/jdk/pull/11925/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11925&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299853 Stats: 11 lines in 6 files changed: 1 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11925.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11925/head:pull/11925 PR: https://git.openjdk.org/jdk/pull/11925 From tschatzl at openjdk.org Tue Jan 10 12:12:54 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 10 Jan 2023 12:12:54 GMT Subject: RFR: 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 10:51:14 GMT, Albert Mingkun Yang wrote: > Simple change of using the actual type for a field. > > Test: hotspot_gc Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11925 From stefank at openjdk.org Tue Jan 10 12:40:55 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 10 Jan 2023 12:40:55 GMT Subject: RFR: 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 10:51:14 GMT, Albert Mingkun Yang wrote: > Simple change of using the actual type for a field. > > Test: hotspot_gc Looks good. Some nits: src/hotspot/share/gc/serial/tenuredGeneration.hpp line 68: > 66: void assert_correct_size_change_locking(); > 67: > 68: TenuredSpace* _the_space; // Actual space holding objects Indentation is weird after this change src/hotspot/share/gc/shared/cardTableRS.hpp line 35: > 33: class Generation; > 34: class Space; > 35: class TenuredSpace; Since you are changing this, could you add a blank line after this line? ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/11925 From ayang at openjdk.org Tue Jan 10 12:57:18 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 10 Jan 2023 12:57:18 GMT Subject: RFR: 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space [v2] In-Reply-To: References: Message-ID: > Simple change of using the actual type for a field. > > Test: hotspot_gc Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11925/files - new: https://git.openjdk.org/jdk/pull/11925/files/f2356ce3..3b485fce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11925&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11925&range=00-01 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11925.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11925/head:pull/11925 PR: https://git.openjdk.org/jdk/pull/11925 From aboldtch at openjdk.org Tue Jan 10 14:40:56 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 10 Jan 2023 14:40:56 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 10:30:06 GMT, Fredrik Bredberg wrote: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Note, you changed the initial year. Should be: - * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 10 14:51:02 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 10 Jan 2023 14:51:02 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 14:38:32 GMT, Axel Boldt-Christmas wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. > > Note, you changed the initial year. Should be: > > - * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. My sed script which updated all copyright headers to 2023 didn't take into account files with only one year in the copyright line. My bad. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From mdoerr at openjdk.org Tue Jan 10 15:16:56 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 10 Jan 2023 15:16:56 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 10:30:06 GMT, Fredrik Bredberg wrote: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Works on PPC64. Thanks! Tests have passed on other platforms as well. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 10 16:56:31 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 10 Jan 2023 16:56:31 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v8] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/d55d7612..9576b50a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=06-07 Stats: 14 lines in 3 files changed: 1 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From dfuchs at openjdk.org Tue Jan 10 17:16:53 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 10 Jan 2023 17:16:53 GMT Subject: RFR: 8299234: JMX Repository.query performance In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 18:50:52 GMT, Alexey Bakhtin wrote: > Please find a patch to improve JMX Repository.query performance > > Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: > Before: > > $ java test 1000000 1000000 > Test PASSED in 8943169791 ns. > GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 > > > After: > > $ java test 1000000 1000000 > Test PASSED in 4808213917 ns. > GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 > > Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. > > All javax/management jtreg tests passed successfully. I see several issues with the proposed changes: ObjectName is not final, so I'm not sure the changes proposed to ObjectName are safe when/if a subclass is supplied. And in addition, because it's not final, you will need to make a defensive copy of the input parameter in Repository::query and do the matching against the copy. ------------- PR: https://git.openjdk.org/jdk/pull/11758 From mcimadamore at openjdk.org Tue Jan 10 18:52:56 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 10 Jan 2023 18:52:56 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Sat, 7 Jan 2023 21:08:07 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect @bug numbers in unit tests. src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345: > 2343: if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS)) > 2344: return false; > 2345: innerType = erasure(innerType); The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85: > 83: * > 84: *

> 85: * When tracking references, we distinguish between direct references and indirect references, I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098: > 1096: private void visitLooped(T tree, Consumer visitor) { > 1097: this.visitScoped(tree, false, t -> { > 1098: while (true) { Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Tue Jan 10 19:22:58 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Tue, 10 Jan 2023 19:22:58 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Mon, 9 Jan 2023 15:03:10 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix incorrect @bug numbers in unit tests. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85: > >> 83: * >> 84: *

>> 85: * When tracking references, we distinguish between direct references and indirect references, > > I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect? It's slightly different from that. Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_. This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared. Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`). You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`. Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098: > >> 1096: private void visitLooped(T tree, Consumer visitor) { >> 1097: this.visitScoped(tree, false, t -> { >> 1098: while (true) { > > Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code? Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies. The `ThisEscapeLoop.java` unit test demonstrates: public class ThisEscapeLoop { public ThisEscapeLoop() { ThisEscapeLoop ref1 = this; ThisEscapeLoop ref2 = null; ThisEscapeLoop ref3 = null; ThisEscapeLoop ref4 = null; for (int i = 0; i < 100; i++) { ref4 = ref3; ref3 = ref2; ref2 = ref1; if (ref4 != null) ref4.mightLeak(); } } public void mightLeak() { } } ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Tue Jan 10 19:44:56 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Tue, 10 Jan 2023 19:44:56 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Mon, 9 Jan 2023 14:23:47 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix incorrect @bug numbers in unit tests. > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345: > >> 2343: if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS)) >> 2344: return false; >> 2345: innerType = erasure(innerType); > > The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances). OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit. Just to confirm, you are saying that this: `if (erasure(type).equalsIgnoreMetadata(outerType)) {` should be replaced with this? `if (isSameType(type, outerType)) {` ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Tue Jan 10 20:22:16 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Tue, 10 Jan 2023 20:22:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v6] In-Reply-To: References: Message-ID: <-cVR0e9azbb3U9vWObNm1dBbUGIDuI7T6bAOpuPSG8I=.a55f2d47-00ae-471c-a51c-df638c104487@github.com> > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add this-escape to the Javadoc list of strings supported by @SuppressWarnings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/7e2fdb07..d70d12f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From jcking at openjdk.org Tue Jan 10 21:33:49 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 21:33:49 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code Message-ID: Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. ------------- Commit messages: - Use REALLOC_C_HEAP_ARRAY instead of NEW_C_HEAP_ARRAY/FREE_C_HEAP_ARRAY - Remove ArrayAllocatorMallocLimit Changes: https://git.openjdk.org/jdk/pull/11931/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299915 Stats: 336 lines in 13 files changed: 13 ins; 308 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Tue Jan 10 21:41:21 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 21:41:21 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v2] In-Reply-To: References: Message-ID: <0HxKoxC-2_7geQqXlYUZGcq-X6Q1ijKrIY42Sof8OcQ=.b3b8790f-74d6-40bd-b029-6c14dd1fd67c@github.com> > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Use unconstrained flag for SizeTTest.java Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/efb1a8b3..9e96ddb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Tue Jan 10 22:24:26 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 22:24:26 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v3] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove ArrayAllocatorMallocLimit test Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/9e96ddb9..235abed3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=01-02 Stats: 100 lines in 1 file changed: 0 ins; 100 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Tue Jan 10 22:50:11 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 10 Jan 2023 22:50:11 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Initialize memory to zero in zGranuleMap Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/235abed3..3216fb19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From mcimadamore at openjdk.org Tue Jan 10 23:41:19 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 10 Jan 2023 23:41:19 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com> On Tue, 10 Jan 2023 19:42:06 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2345: >> >>> 2343: if (!innerType.hasTag(CLASS) || !outerType.hasTag(CLASS)) >>> 2344: return false; >>> 2345: innerType = erasure(innerType); >> >> The javac way to write this would be either to compare types using `Types.isSameType` or to compare the underlying class symbols with == (as class symbols are shared across multiple type instances). > > OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit. > > Just to confirm, you are saying that this: > > `if (erasure(type).equalsIgnoreMetadata(outerType)) {` > > should be replaced with this? > > `if (isSameType(type, outerType)) {` yes ------------- PR: https://git.openjdk.org/jdk/pull/11874 From coleenp at openjdk.org Tue Jan 10 23:43:18 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 10 Jan 2023 23:43:18 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 16:56:31 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: > > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable Changes requested by coleenp (Reviewer). src/hotspot/share/prims/jvmtiTagMap.cpp line 195: > 193: JvmtiTagMap* _tag_map; > 194: JvmtiTagMapTable* _hashmap; > 195: bool _entry_found; is this used? src/hotspot/share/prims/jvmtiTagMapTable.hpp line 44: > 42: // Its get_hash() and equals() methods are also used for getting the hash > 43: // value of a Key and comparing two Keys, respectively. > 44: class JvmtiTagMapKey : public CHeapObj { Can you change mtInternal to mtServiceability here? ------------- PR: https://git.openjdk.org/jdk/pull/11288 From coleenp at openjdk.org Tue Jan 10 23:48:21 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 10 Jan 2023 23:48:21 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 16:56:31 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: > > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable src/hotspot/share/prims/jvmtiTagMap.cpp line 442: > 440: delete _fields->at(i); > 441: } > 442: delete _fields; The changes here to ClassFieldMap are not part of the change, can you revert them (also leave mtInternal even though that's wrong). src/hotspot/share/prims/jvmtiTagMap.hpp line 37: > 35: class JvmtiTagMapKeyClosure; > 36: > 37: class JvmtiTagMap : public CHeapObj { Change to mtServiceability src/hotspot/share/prims/jvmtiTagMapTable.hpp line 76: > 74: JvmtiTagMapKey::equals> ResizableResourceHT; > 75: > 76: class JvmtiTagMapTable : public CHeapObj { Change this to mtServiceability ------------- PR: https://git.openjdk.org/jdk/pull/11288 From mcimadamore at openjdk.org Tue Jan 10 23:49:12 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 10 Jan 2023 23:49:12 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com> On Tue, 10 Jan 2023 19:18:04 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 85: >> >>> 83: * >>> 84: *

>>> 85: * When tracking references, we distinguish between direct references and indirect references, >> >> I'm trying to understand the code and it's not obvious to me as to where this difference comes into play. I believe (but I'm not sure) the spirit is to treat reference to `this` in the original constructor as "direct" while treat a reference to a parameter "a" in a method called from the constructor, where "a" is assigned "this", as indirect? > > It's slightly different from that. > > Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_. > > This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared. > > Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`). > > You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`. > > Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference. So, if I understand correctly your array element test, when we have `new Object[][] { { this } }` the analysis is able to detect that there might be some direct reference nested inside the array. So the outer array is an indirect reference. The inner array is also an indirect reference - but any element accessed on the inner array are direct reference - and so you detect a leak there. Correct? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Wed Jan 11 00:07:14 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 11 Jan 2023 00:07:14 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com> References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <8PxlV-Syo2Y48TBgSQupSjArfJxMqnA8BZQIYTfYGPA=.057f204c-330b-4fb9-96e5-f8dc8fe348aa@github.com> Message-ID: On Tue, 10 Jan 2023 23:45:59 GMT, Maurizio Cimadamore wrote: >> It's slightly different from that. >> >> Considering any of the various things in scope that can point to an object (these are: the current 'this' instance, the current outer 'this' instance, method parameter/variable, method return value, top of Java stack), such a thing has a "direct" reference if it might possibly _directly_ point to the 'this' we're tracking, while a thing has an "indirect" reference if it might possibly point to the 'this' we're tracking through _at least one level of indirection_. >> >> This is just an attempt to eliminate some false positives by distinguishing between those two cases. Originally I was going to try to track fields (in a very limited way), and so this distinction was going to be more important, but even without tracking fields it's still useful. For example, if some method invokes `x.y.foo()` and `x` represents a direct but not an indirect 'this' reference, then there is no leak declared. >> >> Considering the other options... (a) if you only track direct references, then you suffer from more false negatives (how many? unclear); (b) if you lump direct and indirect references into one bucket, then you suffer from more false positives (as in previous example `x.y.foo()`). >> >> You can see an example of an indirect reference being tracked and exposed in the unit test `ThisEscapeArrayElement.java`. >> >> Another motivating example is lambdas. The act of simply _creating_ a lambda never creates a leak, and a lambda never represents a _direct_ reference. But it might represent an _indirect_ reference. > > So, if I understand correctly your array element test, when we have `new Object[][] { { this } }` the analysis is able to detect that there might be some direct reference nested inside the array. So the outer array is an indirect reference. The inner array is also an indirect reference - but any element accessed on the inner array are direct reference - and so you detect a leak there. Correct? Yes - although it's not tracked being tracked any more precisely than "one or more levels of indirection". And of course by "reference" we only mean "the possibility of a reference" - in general we don't know for sure. Here's the logic: * The analysis knows `this` is a direct reference * Therefore the array expression `{ this }` has an indirect reference (but no direct reference) * The outer array expression `{ { this } }` therefore _also_ has an indirect reference (but no direct reference) At this point, we don't know how many levels of indirection there are in `array` though.... only that its ? 1. * There expression `array[0]` therefore is determined to have both direct and indirect references (they are both _possible_ because we've dereferenced something with an indirect reference) * As does `array[0][0]` for the same reason So invoking `array[0][0].hashCode()` means invoking `hashCode()` on something that has a possible direct reference, and is therefore a leak. Note that because of the imprecision in the number of levels of indirection, invoking `array[0].hashCode()` would also have generated a warning - but in that case, a false positive. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Wed Jan 11 00:07:15 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 11 Jan 2023 00:07:15 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Tue, 10 Jan 2023 19:20:35 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1098: >> >>> 1096: private void visitLooped(T tree, Consumer visitor) { >>> 1097: this.visitScoped(tree, false, t -> { >>> 1098: while (true) { >> >> Why is this needed? Can the tracking state of `this` change after multiple "execution" of the same code? > > Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies. > > The `ThisEscapeLoop.java` unit test demonstrates: > > public class ThisEscapeLoop { > > public ThisEscapeLoop() { > ThisEscapeLoop ref1 = this; > ThisEscapeLoop ref2 = null; > ThisEscapeLoop ref3 = null; > ThisEscapeLoop ref4 = null; > for (int i = 0; i < 100; i++) { > ref4 = ref3; > ref3 = ref2; > ref2 = ref1; > if (ref4 != null) > ref4.mightLeak(); > } > } > > public void mightLeak() { > } > } So, if the code was be like this: ThisEscapeLoop ref11 = this; ThisEscapeLoop ref12 = null; ThisEscapeLoop ref13 = null; ThisEscapeLoop ref14 = null; for (int i = 0; i < 100; i++) { ref14 = ref13; ref13 = ref12; ref12 = ref11; ThisEscapeLoop ref21 = ref14; ThisEscapeLoop ref22 = null; ThisEscapeLoop ref23 = null; ThisEscapeLoop ref24 = null; for (int i = 0; i < 100; i++) { ref24 = ref23; ref23 = ref22; ref22 = ref21; if (ref24 != null) ref24.mightLeak(); } } Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Wed Jan 11 00:25:10 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 11 Jan 2023 00:25:10 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Wed, 11 Jan 2023 00:04:14 GMT, Maurizio Cimadamore wrote: >> Yes, because the 'this' reference can bounce around through different variables in scope each time around the loop. So we have to repeat the loop until all 'this' references have "flooded" into all the nooks and crannies. >> >> The `ThisEscapeLoop.java` unit test demonstrates: >> >> public class ThisEscapeLoop { >> >> public ThisEscapeLoop() { >> ThisEscapeLoop ref1 = this; >> ThisEscapeLoop ref2 = null; >> ThisEscapeLoop ref3 = null; >> ThisEscapeLoop ref4 = null; >> for (int i = 0; i < 100; i++) { >> ref4 = ref3; >> ref3 = ref2; >> ref2 = ref1; >> if (ref4 != null) >> ref4.mightLeak(); >> } >> } >> >> public void mightLeak() { >> } >> } > > So, if the code was be like this: > > > ThisEscapeLoop ref11 = this; > ThisEscapeLoop ref12 = null; > ThisEscapeLoop ref13 = null; > ThisEscapeLoop ref14 = null; > for (int i = 0; i < 100; i++) { > ref14 = ref13; > ref13 = ref12; > ref12 = ref11; > ThisEscapeLoop ref21 = ref14; > ThisEscapeLoop ref22 = null; > ThisEscapeLoop ref23 = null; > ThisEscapeLoop ref24 = null; > for (int i = 0; i < 100; i++) { > ref24 = ref23; > ref23 = ref22; > ref22 = ref21; > if (ref24 != null) > ref24.mightLeak(); > } > } > > > Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak? Actually I think it would take 1 + 1 + 3 iterations. During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references. It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again. However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Wed Jan 11 03:30:03 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 11 Jan 2023 03:30:03 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Use the more appropriate Type comparison method Types.isSameType(). - Add some more comments to clarify how the analysis works. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/d70d12f4..6e96a7d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=05-06 Stats: 31 lines in 2 files changed: 16 ins; 10 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Wed Jan 11 03:30:05 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 11 Jan 2023 03:30:05 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com> References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0Hksmg2eLQg0c9W5CB6y6dXw2vaEXxy-UY9_D0DtLQY=.351da0ec-208c-4f8d-bf16-318de07ca63e@github.com> Message-ID: <7jUSzUYT_eWYGbHkDes10f2-1i5DNdmDGDACe8qsXU4=.5bca0f1b-e004-48bc-87e0-48d6fb9deb96@github.com> On Tue, 10 Jan 2023 23:38:14 GMT, Maurizio Cimadamore wrote: >> OK I'm glad you pointed that out because I'm a little unclear on the best way to do this bit. >> >> Just to confirm, you are saying that this: >> >> `if (erasure(type).equalsIgnoreMetadata(outerType)) {` >> >> should be replaced with this? >> >> `if (isSameType(type, outerType)) {` > > yes Thanks... updated in `6e96a7d76f8`. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From kbarrett at openjdk.org Wed Jan 11 05:20:13 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 11 Jan 2023 05:20:13 GMT Subject: RFR: 8299701: Remove unused GCCause::_wb_conc_mark [v2] In-Reply-To: References: Message-ID: > Please review this change to remove GCCause::_wb_conc_mark and the supporting > implementation. After JDK-8293824 it is no longer used as the cause when > requesting a GC. > > Note: The implementation in ZGC appears to have never been used. Prior to > JDK-8293824 this cause was only used by a G1-specific WB function. (In the > deep mists of time it might have also been used to trigger a CMS concurrent > cycle; I didn't bother looking into that.) > > Testing: > mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into wb_conc_mark - remove GCCause::_wb_conc_mark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11893/files - new: https://git.openjdk.org/jdk/pull/11893/files/d4cefe03..f1aeb03d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11893&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11893&range=00-01 Stats: 4200 lines in 157 files changed: 2391 ins; 1080 del; 729 mod Patch: https://git.openjdk.org/jdk/pull/11893.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11893/head:pull/11893 PR: https://git.openjdk.org/jdk/pull/11893 From kbarrett at openjdk.org Wed Jan 11 05:20:14 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 11 Jan 2023 05:20:14 GMT Subject: RFR: 8299701: Remove unused GCCause::_wb_conc_mark [v2] In-Reply-To: <2HulfQEXcnB_eV5unX7gmemBlBi_NnC2ilCGo3zlqKM=.1c529d37-e23b-49a3-b912-9ad62e812f81@github.com> References: <2HulfQEXcnB_eV5unX7gmemBlBi_NnC2ilCGo3zlqKM=.1c529d37-e23b-49a3-b912-9ad62e812f81@github.com> Message-ID: On Mon, 9 Jan 2023 15:01:21 GMT, Erik ?sterlund wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into wb_conc_mark >> - remove GCCause::_wb_conc_mark > > Looks good. Just one small nit. Thanks for reviews @fisk and @walulyai . ------------- PR: https://git.openjdk.org/jdk/pull/11893 From kbarrett at openjdk.org Wed Jan 11 05:20:16 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 11 Jan 2023 05:20:16 GMT Subject: Integrated: 8299701: Remove unused GCCause::_wb_conc_mark In-Reply-To: References: Message-ID: On Sat, 7 Jan 2023 17:41:04 GMT, Kim Barrett wrote: > Please review this change to remove GCCause::_wb_conc_mark and the supporting > implementation. After JDK-8293824 it is no longer used as the cause when > requesting a GC. > > Note: The implementation in ZGC appears to have never been used. Prior to > JDK-8293824 this cause was only used by a G1-specific WB function. (In the > deep mists of time it might have also been used to trigger a CMS concurrent > cycle; I didn't bother looking into that.) > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: ddca2b9b Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/ddca2b9b46110ecae9f67eab9677e96168f7e9cf Stats: 19 lines in 6 files changed: 0 ins; 11 del; 8 mod 8299701: Remove unused GCCause::_wb_conc_mark Reviewed-by: eosterlund, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/11893 From duke at openjdk.org Wed Jan 11 09:22:03 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 11 Jan 2023 09:22:03 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Updated some copyright dates. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11902/files - new: https://git.openjdk.org/jdk/pull/11902/files/342d1465..54a0931d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Wed Jan 11 09:40:23 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 09:40:23 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v8] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 23:36:37 GMT, Coleen Phillimore wrote: >> Afshin Zafari has updated the pull request incrementally with three additional commits since the last revision: >> >> - 8292741: Convert JvmtiTagMapTable to ResourceHashtable >> - 8292741: Convert JvmtiTagMapTable to ResourceHashtable >> - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > > src/hotspot/share/prims/jvmtiTagMap.cpp line 195: > >> 193: JvmtiTagMap* _tag_map; >> 194: JvmtiTagMapTable* _hashmap; >> 195: bool _entry_found; > > is this used? It isn't used. Removed. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From kevinw at openjdk.org Wed Jan 11 09:50:08 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 11 Jan 2023 09:50:08 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed Message-ID: The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. javax.management.Attribute and AttributeList classes are also needed, and Query related classes. There are a number of Query-relate classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. ------------- Commit messages: - trailing whitespace in comment - change flag for testing operations vs. other classes - whitespace - 8299891: JMX ObjectInputFilter additional classes needed Changes: https://git.openjdk.org/jdk20/pull/97/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299891 Stats: 101 lines in 2 files changed: 92 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk20/pull/97.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/97/head:pull/97 PR: https://git.openjdk.org/jdk20/pull/97 From ayang at openjdk.org Wed Jan 11 10:08:17 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 11 Jan 2023 10:08:17 GMT Subject: RFR: 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 12:57:18 GMT, Albert Mingkun Yang wrote: >> Simple change of using the actual type for a field. >> >> Test: hotspot_gc > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/11925 From stefank at openjdk.org Wed Jan 11 10:08:17 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 11 Jan 2023 10:08:17 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 22:50:11 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Initialize memory to zero in zGranuleMap > > Signed-off-by: Justin King I'm happy to see this flag getting removed. I'm less happy about seeing usages of the array allocators being replaced by macros. I'd rather see an effort towards getting rid of these macros. Could we limit this patch to only remove the ArrayAllocatorMallocLimit flag and ArrayAllocator class, and defer the discussion around what API to use for array allocations? ------------- PR: https://git.openjdk.org/jdk/pull/11931 From duke at openjdk.org Wed Jan 11 10:10:45 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 10:10:45 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v9] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/9576b50a..b90aad6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=07-08 Stats: 8 lines in 4 files changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Wed Jan 11 10:10:45 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 10:10:45 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Fri, 6 Jan 2023 14:13:05 GMT, Coleen Phillimore wrote: >> The issue is not the underlying RHT methods but the semantics of the `jvmtiTagMap` methods. If a call to add always expects to add then it should be a fatal error if it actually did an update as that indicates something is broken. Similarly if an update actually does an add. > > The JvmtiTagMap code adds/updates and removes the entries like below in two places which could probably be simplified, but I think that's outside the scope of this RFE. I suggest removing the bool return from add, remove and update, and add the assert(true) in the remove case. There's already an assert that add/update happened in the other cases. > > ``` // if the object is not already tagged then we tag it > if (found_tag == 0) { > if (tag != 0) { > hashmap->add(o, tag); > } else { > // no-op > } > } else { > // if the object is already tagged then we either update > // the tag (if a new tag value has been provided) > // or remove the object if the new tag value is 0. > if (tag == 0) { > hashmap->remove(o); > } else { > hashmap->update(o, tag); > } > } The methods of HashmapTable are void and have assert to verify the expected function (add/update/remove) is done. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From ayang at openjdk.org Wed Jan 11 10:11:19 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 11 Jan 2023 10:11:19 GMT Subject: Integrated: 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 10:51:14 GMT, Albert Mingkun Yang wrote: > Simple change of using the actual type for a field. > > Test: hotspot_gc This pull request has now been integrated. Changeset: 5a9490a4 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/5a9490a40e0fe281fc1b33d2c39a9a970d8a7b4f Stats: 12 lines in 6 files changed: 2 ins; 1 del; 9 mod 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space Reviewed-by: tschatzl, stefank ------------- PR: https://git.openjdk.org/jdk/pull/11925 From duke at openjdk.org Wed Jan 11 10:49:59 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 11 Jan 2023 10:49:59 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v10] In-Reply-To: References: Message-ID: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/b90aad6e..b5a93bd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From abakhtin at openjdk.org Wed Jan 11 11:29:39 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Wed, 11 Jan 2023 11:29:39 GMT Subject: RFR: 8299234: JMX Repository.query performance [v2] In-Reply-To: References: Message-ID: <_um-ehDR_iZDst3YcuAvzAwXitiSQwo-DfmXAhOiFS8=.c3f9b6b1-61b7-482d-a313-c518b4ce183d@github.com> > Please find a patch to improve JMX Repository.query performance > > Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: > Before: > > $ java test 1000000 1000000 > Test PASSED in 8943169791 ns. > GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 > > > After: > > $ java test 1000000 1000000 > Test PASSED in 4808213917 ns. > GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 > > Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. > > All javax/management jtreg tests passed successfully. Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Use copy of the ObjectName for matching ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11758/files - new: https://git.openjdk.org/jdk/pull/11758/files/c60e6b60..1ecc5ad8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11758.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11758/head:pull/11758 PR: https://git.openjdk.org/jdk/pull/11758 From abakhtin at openjdk.org Wed Jan 11 11:29:39 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Wed, 11 Jan 2023 11:29:39 GMT Subject: RFR: 8299234: JMX Repository.query performance In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 17:14:29 GMT, Daniel Fuchs wrote: > I see several issues with the proposed changes: ObjectName is not final, so I'm not sure the changes proposed to ObjectName are safe when/if a subclass is supplied. And in addition, because it's not final, you will need to make a defensive copy of the input parameter in Repository::query and do the matching against the copy. Hi @dfuch, Thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/11758 From dfuchs at openjdk.org Wed Jan 11 12:11:17 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 11 Jan 2023 12:11:17 GMT Subject: RFR: 8299234: JMX Repository.query performance [v2] In-Reply-To: <_um-ehDR_iZDst3YcuAvzAwXitiSQwo-DfmXAhOiFS8=.c3f9b6b1-61b7-482d-a313-c518b4ce183d@github.com> References: <_um-ehDR_iZDst3YcuAvzAwXitiSQwo-DfmXAhOiFS8=.c3f9b6b1-61b7-482d-a313-c518b4ce183d@github.com> Message-ID: On Wed, 11 Jan 2023 11:29:39 GMT, Alexey Bakhtin wrote: >> Please find a patch to improve JMX Repository.query performance >> >> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: >> Before: >> >> $ java test 1000000 1000000 >> Test PASSED in 8943169791 ns. >> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 >> >> >> After: >> >> $ java test 1000000 1000000 >> Test PASSED in 4808213917 ns. >> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 >> >> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. >> >> All javax/management jtreg tests passed successfully. > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Use copy of the ObjectName for matching Using `ObjectName::getInstance` for the defensive copy is the right choice since it will only make a copy if the argument is a subclass. That looks good. I see your point about using `_canonical_name`. Technically this is still an observable change of behaviour - so it might be preferable to file a CSR if you want to proceed with the changes made to `ObjectName`. Regardless of that these changes seem to be introducing a bug (see my other comment inline). src/java.management/share/classes/javax/management/ObjectName.java line 2024: > 2022: // The other ObjectName is the string. > 2023: return Util.wildmatch(name._canonicalName, _canonicalName, > 2024: 0, 0, name.getDomainLength(), getDomainLength()); This looks wrong. Look at the parameters in wildmatch: wildmatch(final String str, final String pat, int stri, final int strend, int pati, final int patend) What tests did you run to validate your changes? If none of the ObjectName tests fail with your changes you will need to add a new test that catches the error. ------------- PR: https://git.openjdk.org/jdk/pull/11758 From dfuchs at openjdk.org Wed Jan 11 12:22:23 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 11 Jan 2023 12:22:23 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 09:40:11 GMT, Kevin Walls wrote: > The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. > javax.management.Attribute and AttributeList classes are also needed, and Query related classes. > > There are a number of Query-relate classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. I believe it would be good to add a test method that registers for notifications using a notification filter. Especially attribute change notification, possibly MBean registration too. ------------- PR: https://git.openjdk.org/jdk20/pull/97 From abakhtin at openjdk.org Wed Jan 11 14:09:21 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Wed, 11 Jan 2023 14:09:21 GMT Subject: RFR: 8299234: JMX Repository.query performance [v3] In-Reply-To: References: Message-ID: > Please find a patch to improve JMX Repository.query performance > > Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: > Before: > > $ java test 1000000 1000000 > Test PASSED in 8943169791 ns. > GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 > > > After: > > $ java test 1000000 1000000 > Test PASSED in 4808213917 ns. > GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 > > Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. > > All javax/management jtreg tests passed successfully. Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Fix parameters order for Util.wildmatch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11758/files - new: https://git.openjdk.org/jdk/pull/11758/files/1ecc5ad8..5ac859ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=01-02 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11758.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11758/head:pull/11758 PR: https://git.openjdk.org/jdk/pull/11758 From abakhtin at openjdk.org Wed Jan 11 14:11:54 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Wed, 11 Jan 2023 14:11:54 GMT Subject: RFR: 8299234: JMX Repository.query performance [v2] In-Reply-To: References: <_um-ehDR_iZDst3YcuAvzAwXitiSQwo-DfmXAhOiFS8=.c3f9b6b1-61b7-482d-a313-c518b4ce183d@github.com> Message-ID: On Wed, 11 Jan 2023 12:02:57 GMT, Daniel Fuchs wrote: >> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: >> >> Use copy of the ObjectName for matching > > src/java.management/share/classes/javax/management/ObjectName.java line 2024: > >> 2022: // The other ObjectName is the string. >> 2023: return Util.wildmatch(name._canonicalName, _canonicalName, >> 2024: 0, 0, name.getDomainLength(), getDomainLength()); > > This looks wrong. Look at the parameters in wildmatch: > > wildmatch(final String str, final String pat, > int stri, final int strend, int pati, final int patend) > > > What tests did you run to validate your changes? If none of the ObjectName tests fail with your changes you will need to add a new test that catches the error. Thank you again for review and finding. Current tests do not catch such issue, so I extended ApplyWildcardTest.java with domain patterns. The test passed on the original and new code, fails with incorrect Util.wildmatch parameters ------------- PR: https://git.openjdk.org/jdk/pull/11758 From mcimadamore at openjdk.org Wed Jan 11 14:15:18 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 11 Jan 2023 14:15:18 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Wed, 11 Jan 2023 00:22:03 GMT, Archie L. Cobbs wrote: >> So, if the code was be like this: >> >> >> ThisEscapeLoop ref11 = this; >> ThisEscapeLoop ref12 = null; >> ThisEscapeLoop ref13 = null; >> ThisEscapeLoop ref14 = null; >> for (int i = 0; i < 100; i++) { >> ref14 = ref13; >> ref13 = ref12; >> ref12 = ref11; >> ThisEscapeLoop ref21 = ref14; >> ThisEscapeLoop ref22 = null; >> ThisEscapeLoop ref23 = null; >> ThisEscapeLoop ref24 = null; >> for (int i = 0; i < 100; i++) { >> ref24 = ref23; >> ref23 = ref22; >> ref22 = ref21; >> if (ref24 != null) >> ref24.mightLeak(); >> } >> } >> >> >> Then it would take not 3 iterations but 3 * 3 to figure out that it is a potential leak? > > Actually I think it would take 1 + 1 + 3 iterations. > > During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references. > > It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again. > > However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code. True - probably 3 * 3 can be achieved if this: ThisEscapeLoop ref21 = ref14; Is replaced with ThisEscapeLoop ref21 = this; In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24). I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit). I suggest one experiment where you: 1. downgrade the warnings to notes (so that they won't make the JDK build fail) 2. enable this Lint everywhere 3. compare JDK `clean images` time w/ and w/o the Lint ------------- PR: https://git.openjdk.org/jdk/pull/11874 From jcking at openjdk.org Wed Jan 11 14:30:16 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 14:30:16 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 10:05:33 GMT, Stefan Karlsson wrote: > I'm happy to see this flag getting removed. I'm less happy about seeing usages of the array allocators being replaced by macros. I'd rather see an effort towards getting rid of these macros. Could we limit this patch to only remove the ArrayAllocatorMallocLimit flag and ArrayAllocator class, and defer the discussion around what API to use for array allocations? `ArrayAllocator` with `ArrayAllocatorMallocLimit` removed is effectively `MallocArrayAllocator`. Are you suggesting leaving `MallocArrayAllocator` and `MmapArrayAllocator` thus update references to `ArrayAllocator` to be `MallocArrayAllocator`? As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). ------------- PR: https://git.openjdk.org/jdk/pull/11931 From stuefe at openjdk.org Wed Jan 11 14:53:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 11 Jan 2023 14:53:14 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 22:50:11 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Initialize memory to zero in zGranuleMap > > Signed-off-by: Justin King Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) ------------- PR: https://git.openjdk.org/jdk/pull/11931 From stefank at openjdk.org Wed Jan 11 15:11:15 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 11 Jan 2023 15:11:15 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:27:44 GMT, Justin King wrote: > ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and MmapArrayAllocator thus update references to ArrayAllocator to be MallocArrayAllocator? Yes, that was what I wanted. > As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). I agree about the argument about consistency, so I retract my objection. We can deal with these macros as a separate RFE (if we ever get to it). I would like to retain the usage of mmapped memory for ZGC to minimize the risk of any surprises for us. ZGC code also tend to initialize as much as possible in the initialization list, so the extra memset that comes after initialization lists sticks out a bit. Could you create a private `ZGranuleMap::allocate_array` function that uses os::reserve_memory/commmit_memory and change the code to be: inline ZGranuleMap::ZGranuleMap(size_t max_offset) : _size(max_offset >> ZGranuleSizeShift), _map(allocate_array(_size)) { Or if you like, I can provide a patch on top of your branch to do that. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From mcimadamore at openjdk.org Wed Jan 11 16:02:16 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 11 Jan 2023 16:02:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Use the more appropriate Type comparison method Types.isSameType(). > - Add some more comments to clarify how the analysis works. More questions. Let's say that we only tracked escaping of direct references to `this`. Do you have any sense of how many "less" warnings would be reported in real code (e.g. JDK) ? What I mean by this - let's say that we don't care about tracking _where_ `this` ends up going exactly (e.g. if it's aliased by another variable) - and perhaps also let's say we don't care about inspecting the method to which `this` is leaked too closely - e.g. we treat any early escape of `this` as a possible issue. Of course you could construct examples (like your tests) in which such a simplistic analysis would be defeated. What I'm interested in though is what incremental improvement is brought by the more complex analysis you have in this PR? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Wed Jan 11 16:17:16 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 11 Jan 2023 16:17:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: On Wed, 11 Jan 2023 14:12:46 GMT, Maurizio Cimadamore wrote: >> Actually I think it would take 1 + 1 + 3 iterations. >> >> During the first two iterations of the outer loop, nothing changes after the first go round of the inner loop - i.e., the total set of possible references in existence does not change, because all of the assignments in the inner loop won't involve any 'this' references. >> >> It's only the during the third iteration of the outer loop that any 'this' references seep into any of the variables seen by the inner loop. Then it will take 3 cycles for the reference set to converge again. >> >> However, this is not to say that there aren't some pathological examples out there. I guess the question is could they exist in "normal" code. > > True - probably 3 * 3 can be achieved if this: > > > ThisEscapeLoop ref21 = ref14; > > Is replaced with > > > ThisEscapeLoop ref21 = this; > > > In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24). > > I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit). > > I suggest one experiment where you: > 1. downgrade the warnings to notes (so that they won't make the JDK build fail) > 2. enable this Lint everywhere > 3. compare JDK `clean images` time w/ and w/o the Lint Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4. If we build a graph of all the assignments, we get: ref4 <- ref3 <- ref2 <- ref1 <- this So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there. Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From jcking at openjdk.org Wed Jan 11 17:55:53 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 17:55:53 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v5] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Restore mmap allocator for zGranuleMap Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/3216fb19..d30748e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=03-04 Stats: 33 lines in 2 files changed: 30 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Wed Jan 11 18:01:16 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 18:01:16 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:08:23 GMT, Stefan Karlsson wrote: > > ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and MmapArrayAllocator thus update references to ArrayAllocator to be MallocArrayAllocator? > > Yes, that was what I wanted. > > > As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). > > I agree about the argument about consistency, so I retract my objection. We can deal with these macros as a separate RFE (if we ever get to it). > > I would like to retain the usage of mmapped memory for ZGC to minimize the risk of any surprises for us. ZGC code also tend to initialize as much as possible in the initialization list, so the extra memset that comes after initialization lists sticks out a bit. Could you create a private `ZGranuleMap::allocate_array` function that uses os::reserve_memory/commmit_memory and change the code to be: > > ``` > inline ZGranuleMap::ZGranuleMap(size_t max_offset) : > _size(max_offset >> ZGranuleSizeShift), > _map(allocate_array(_size)) { > ``` > > Or if you like, I can provide a patch on top of your branch to do that. The extra memset is due to `malloc` not handing out zero initialized memory, it looks like `zGranuleMap` is sensitive to that. Done. Restored mmap as suggested for zGranuleMap. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Wed Jan 11 18:13:15 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 18:13:15 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote: > Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). > > Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? > > (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) Correct, glibc always mmap's allocations above a certain limit and always unmaps them on free. I believe most implementations do that, either immediately unmapping or using madvise. AIX still uses sbrk, based on their documentation that I could find. Though AIX does have something called [malloc disclaim](https://www.ibm.com/docs/en/aix/7.2?topic=subsystem-malloc-disclaim). ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Wed Jan 11 18:26:36 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 18:26:36 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v6] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Ensure Padded2DArray clears memory to preserve compatibility with mmap Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/d30748e9..cf3097ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=04-05 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From duke at openjdk.org Wed Jan 11 18:47:14 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 11 Jan 2023 18:47:14 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> Message-ID: <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> On Wed, 11 Jan 2023 16:14:24 GMT, Maurizio Cimadamore wrote: >> True - probably 3 * 3 can be achieved if this: >> >> >> ThisEscapeLoop ref21 = ref14; >> >> Is replaced with >> >> >> ThisEscapeLoop ref21 = this; >> >> >> In which case the inner loop won't converge immediately (as it will have to propagate from ref21 to ref22 to ref23 to ref24). >> >> I guess what I'm uncomfortable with is that we have effectively unbounded computation here (especially when we also consider the fact that the analysis "follows" method bodies as well, if they are found in the same compilation unit). >> >> I suggest one experiment where you: >> 1. downgrade the warnings to notes (so that they won't make the JDK build fail) >> 2. enable this Lint everywhere >> 3. compare JDK `clean images` time w/ and w/o the Lint > > Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4. > > If we build a graph of all the assignments, we get: > > ref4 <- ref3 <- ref2 <- ref1 <- this > > So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there. > > Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case. Good idea. Looks like the difference is in the noise, at least on my Macbook: Builds of master (jdk-21+3-69-gc6588d5bb3f) ================================== Build times: real 2m24.650s user 13m46.727s sys 2m33.554s real 2m27.224s user 13m43.464s sys 2m37.251s real 2m26.658s user 13m42.578s sys 2m36.133s Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8) ================================== Modifications: - Reverted files in the make/ subdirectory to enable warning - Commented out lines 363-382 in ThisEscapeAnalyzer.java so no warnings are actually reported Build times: real 2m25.912s user 13m45.860s sys 2m32.741s real 2m27.213s user 13m44.830s sys 2m36.596s real 2m25.756s user 13m42.889s sys 2m35.659s ------------- PR: https://git.openjdk.org/jdk/pull/11874 From coleenp at openjdk.org Wed Jan 11 18:55:16 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 11 Jan 2023 18:55:16 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize memory to zero in zGranuleMap >> >> Signed-off-by: Justin King > > Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). > > Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? > > (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) To follow up on @tstuefe comment - and the one that I tried to say in the bug was that we added this MmapArrayAllocate feature for some G1 marking bits that used so much memory that hit the Solaris _sbrk issue. Maybe @stefank and @tschatzl remember this issue. Maybe it's ok for AIX, then removing this code is a good change. Maybe the G1 usages need a mmap implementation though. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From duke at openjdk.org Wed Jan 11 19:13:16 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 11 Jan 2023 19:13:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> Message-ID: On Wed, 11 Jan 2023 18:44:20 GMT, Archie L. Cobbs wrote: >> Also, looking at the loop test more closely, it seems to me that what the compiler needs to do is to prove that there can be possible paths by which a `this` can land into ref4. >> >> If we build a graph of all the assignments, we get: >> >> ref4 <- ref3 <- ref2 <- ref1 <- this >> >> So, if we ask "can ref4 possibly contain `this`?" we could "walk" the variable dependencies backwards and discover that, yes, there exist a possible path in which `this` would get there. >> >> Now, of course without a loop this can never be a real issue (since you can never send a `this` fully down the chain) - but again, this is a question of how much effort should be spend to handle false negatives in what look like a pathological case. > > Good idea. Looks like the difference is in the noise, at least on my Macbook: > > Builds of master (jdk-21+3-69-gc6588d5bb3f) > ================================== > > Build times: > > real 2m24.650s > user 13m46.727s > sys 2m33.554s > > real 2m27.224s > user 13m43.464s > sys 2m37.251s > > real 2m26.658s > user 13m42.578s > sys 2m36.133s > > Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8) > ================================== > > Modifications: > > - Reverted files in the make/ subdirectory to enable warning > - Commented out lines 363-382 in ThisEscapeAnalyzer.java > so no warnings are actually reported > > Build times: > > real 2m25.912s > user 13m45.860s > sys 2m32.741s > > real 2m27.213s > user 13m44.830s > sys 2m36.596s > > real 2m25.756s > user 13m42.889s > sys 2m35.659s Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.? Consider this example: public class ThisEscapeLoop { public ThisEscapeLoop() { ThisEscapeLoop ref1 = this; ThisEscapeLoop ref2 = null; ThisEscapeLoop ref3 = null; ThisEscapeLoop ref4 = null; for (int i = 0; i < 100; i++) { ref4 = this.returnMe(ref3); ref3 = ref2; ref2 = ref1; if (ref4 != null) ref4.mightLeak(); } } public T returnMe(T x) { return x; } public void mightLeak() { } } If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From cjplummer at openjdk.org Wed Jan 11 19:16:26 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 11 Jan 2023 19:16:26 GMT Subject: RFR: 8299518: HotSpotVirtualMachine shared code across different platforms [v6] In-Reply-To: <27esMViORNgCNjS04-6IJfCHcva5NmbCZ3p6yYP2OjQ=.2e294967-6467-4a07-b9b7-004545a9584b@github.com> References: <27esMViORNgCNjS04-6IJfCHcva5NmbCZ3p6yYP2OjQ=.2e294967-6467-4a07-b9b7-004545a9584b@github.com> Message-ID: On Tue, 10 Jan 2023 10:49:52 GMT, Yi Yang wrote: >> harmless refactor to share code across different platforms of VirtualMachineImpl: >> 1. Shared code to process command response after requesting a command execution >> 2. Read functionality in SocketInputStream can be reused > > Yi Yang has updated the pull request incrementally with three additional commits since the last revision: > > - format > - Merge branch 'jdk_virtualmachienimpl' of github.com:y1yang0/jdk into jdk_virtualmachienimpl > - -1 to vmid src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 455: > 453: if (fd != -1) { > 454: close(fd); > 455: } There used to be logic to set `fd` (previously called `s`) to -1 during the close operation. Is that no longer needed? ------------- PR: https://git.openjdk.org/jdk/pull/11823 From duke at openjdk.org Wed Jan 11 19:47:16 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 11 Jan 2023 19:47:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:59:29 GMT, Maurizio Cimadamore wrote: > What I'm interested in though is what incremental improvement is brought by the more complex analysis you have in this PR? It's a good question. Here are some thoughts... One meta-goal is that this analysis be conservative. In other words, if your code does NOT generate any warnings, then you should feel confident that there is a high probability that there are no leaks. This is analogous to how you can be confident that you won't get any `ClassCastExceptions` at runtime if your code doesn't generate any `unchecked` warnings at compile time. I think this point is generally agreed upon. If so, then we would want?any simpler analysis to err on the side of generating more false positives rather than more false negatives. Assuming that, then the question comes down to a trade-off between code complexity vs. rate of false positives. >From my casual looking over the JDK, the current algorithm generates very few false positives - almost all of the warnings represent actual leaks (I'd be interested in any false positives you do see). (Of course, an irony is that most of these leaks have no real-world effect. For example package-private classes in the JDK (a) have already been debugged long ago, so any intra-package bugs due to 'this' escapes have already been fixed; and (b) are unlikely to be subclassed by anyone. And the ones that have a real-world effect (e.g., `HashSet(Collection)`) can't be fixed because of backward compatibility concerns. So this warning is most useful when writing new code.) So the current code is clearly "complex enough" already. FWIW that's ~975 lines of code excluding blank lines and comments. Now to answer your question about a theoretical simpler analysis: > let's say that we don't care about tracking where `this` ends up going exactly (e.g. if it's aliased by another variable) - and perhaps also let's say we don't care about inspecting the method to which `this` is leaked too closely - e.g. we treat any early escape of this as a possible issue. I'm not sure I completely understand the semantics. But are you saying that if a constructor invokes a private or static method, then this simpler analysis would always declare a leak? If that's the case then I think there are a lot of new false positives, because this is common in constructors. I would then worry that if we dilute the warnings with a bunch of new false positives people are just going to get discouraged and turn the warning off completely. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From darcy at openjdk.org Wed Jan 11 20:51:17 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 11 Jan 2023 20:51:17 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Use the more appropriate Type comparison method Types.isSameType(). > - Add some more comments to clarify how the analysis works. Per the discussion in "Effective Java" on calling overridable methods in a constructor, future refinements of the check under review here could be extended to examine the bodies of clone and readObject methods. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From jcking at openjdk.org Wed Jan 11 20:53:38 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 20:53:38 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v7] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Fix incompatible pointer types Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/cf3097ec..5d30170a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Wed Jan 11 20:59:15 2023 From: jcking at openjdk.org (Justin King) Date: Wed, 11 Jan 2023 20:59:15 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: <0nh4tXVw2rW8szwTMV2Rj2NLSA0x-OjM7htP5jMZBlo=.490e5098-24e3-421c-abbf-4be4e32b15da@github.com> On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize memory to zero in zGranuleMap >> >> Signed-off-by: Justin King > > Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). > > Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? > > (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) > To follow up on @tstuefe comment - and the one that I tried to say in the bug was that we added this MmapArrayAllocate feature for some G1 marking bits that used so much memory that hit the Solaris _sbrk issue. Maybe @stefank and @tschatzl remember this issue. Maybe it's ok for AIX, then removing this code is a good change. Maybe the G1 usages need a mmap implementation though. The padding.inline.hpp usage seems to have one caller which is called once. The other mmap usage in G1 we can convert to mmap using a similar approach to zGranuleMap if that is preferred. That would then be equivalent behavior, it looks like the G1 code uses the page allocation granularity anyway so maybe keeping it mmap is the better way to go here anyway? ------------- PR: https://git.openjdk.org/jdk/pull/11931 From xuelei at openjdk.org Wed Jan 11 21:03:12 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 11 Jan 2023 21:03:12 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 Message-ID: The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. ------------- Commit messages: - typo correction - 8299635: More test issues for deprecated sprintf in Xcode 14 Changes: https://git.openjdk.org/jdk/pull/11935/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299635 Stats: 43 lines in 26 files changed: 4 ins; 0 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From mikael at openjdk.org Wed Jan 11 21:19:12 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 11 Jan 2023 21:19:12 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail: src/hotspot/os/linux/attachListener_linux.cpp: In member function 'virtual void LinuxAttachOperation::complete(jint, bufferedStream*)': src/hotspot/os/linux/attachListener_linux.cpp:414:10: error: call to 'sprintf' declared with attribute warning: use os::snprintf [-Werror=attribute-warning] 414 | sprintf(msg, "%d\n", result); | ~~~~~~~^~~~~~~~~~~~~~~~~~~~~ I count ~30 sprintf:s that need updating. I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 11 21:32:14 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 11 Jan 2023 21:32:14 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 21:16:51 GMT, Mikael Vidstedt wrote: > This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail: > This is a question to me as well. I noticed there are still some use of sprintf, but the building passed on MacOS and Linux. I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters. FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); > I count ~30 sprintf:s that need updating. > > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? I'm new to hotspot. Do you know how could I enable C2? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11935 From mcimadamore at openjdk.org Wed Jan 11 21:48:18 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 11 Jan 2023 21:48:18 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> Message-ID: <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboIFFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> On Wed, 11 Jan 2023 19:10:04 GMT, Archie L. Cobbs wrote: >> Good idea. Looks like the difference is in the noise, at least on my Macbook: >> >> Builds of master (jdk-21+3-69-gc6588d5bb3f) >> ================================== >> >> Build times: >> >> real 2m24.650s >> user 13m46.727s >> sys 2m33.554s >> >> real 2m27.224s >> user 13m43.464s >> sys 2m37.251s >> >> real 2m26.658s >> user 13m42.578s >> sys 2m36.133s >> >> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8) >> ================================== >> >> Modifications: >> >> - Reverted files in the make/ subdirectory to enable warning >> - Commented out lines 363-382 in ThisEscapeAnalyzer.java >> so no warnings are actually reported >> >> Build times: >> >> real 2m25.912s >> user 13m45.860s >> sys 2m32.741s >> >> real 2m27.213s >> user 13m44.830s >> sys 2m36.596s >> >> real 2m25.756s >> user 13m42.889s >> sys 2m35.659s > > Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.? > > Consider this example: > > public class ThisEscapeLoop { > > public ThisEscapeLoop() { > ThisEscapeLoop ref1 = this; > ThisEscapeLoop ref2 = null; > ThisEscapeLoop ref3 = null; > ThisEscapeLoop ref4 = null; > for (int i = 0; i < 100; i++) { > ref4 = this.returnMe(ref3); > ref3 = ref2; > ref2 = ref1; > if (ref4 != null) > ref4.mightLeak(); > } > } > > public T returnMe(T x) { > return x; > } > > public void mightLeak() { > } > } > > If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak. > Good idea. Looks like the difference is in the noise, at least on my Macbook: > > ``` > Builds of master (jdk-21+3-69-gc6588d5bb3f) > ================================== > > Build times: > > real 2m24.650s > user 13m46.727s > sys 2m33.554s > > real 2m27.224s > user 13m43.464s > sys 2m37.251s > > real 2m26.658s > user 13m42.578s > sys 2m36.133s > > Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8) > ================================== > > Modifications: > > - Reverted files in the make/ subdirectory to enable warning > - Commented out lines 363-382 in ThisEscapeAnalyzer.java > so no warnings are actually reported > > Build times: > > real 2m25.912s > user 13m45.860s > sys 2m32.741s > > real 2m27.213s > user 13m44.830s > sys 2m36.596s > > real 2m25.756s > user 13m42.889s > sys 2m35.659s > ``` Thanks for trying it out - good to know that build time isn't affected. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Wed Jan 11 21:54:17 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 11 Jan 2023 21:54:17 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboIFFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> Message-ID: On Wed, 11 Jan 2023 21:45:20 GMT, Maurizio Cimadamore wrote: >> Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.? >> >> Consider this example: >> >> public class ThisEscapeLoop { >> >> public ThisEscapeLoop() { >> ThisEscapeLoop ref1 = this; >> ThisEscapeLoop ref2 = null; >> ThisEscapeLoop ref3 = null; >> ThisEscapeLoop ref4 = null; >> for (int i = 0; i < 100; i++) { >> ref4 = this.returnMe(ref3); >> ref3 = ref2; >> ref2 = ref1; >> if (ref4 != null) >> ref4.mightLeak(); >> } >> } >> >> public T returnMe(T x) { >> return x; >> } >> >> public void mightLeak() { >> } >> } >> >> If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak. > >> Good idea. Looks like the difference is in the noise, at least on my Macbook: >> >> ``` >> Builds of master (jdk-21+3-69-gc6588d5bb3f) >> ================================== >> >> Build times: >> >> real 2m24.650s >> user 13m46.727s >> sys 2m33.554s >> >> real 2m27.224s >> user 13m43.464s >> sys 2m37.251s >> >> real 2m26.658s >> user 13m42.578s >> sys 2m36.133s >> >> Builds of ThisEscape (jdk-21+3-125-g6e96a7d76f8) >> ================================== >> >> Modifications: >> >> - Reverted files in the make/ subdirectory to enable warning >> - Commented out lines 363-382 in ThisEscapeAnalyzer.java >> so no warnings are actually reported >> >> Build times: >> >> real 2m25.912s >> user 13m45.860s >> sys 2m32.741s >> >> real 2m27.213s >> user 13m44.830s >> sys 2m36.596s >> >> real 2m25.756s >> user 13m42.889s >> sys 2m35.659s >> ``` > > Thanks for trying it out - good to know that build time isn't affected. > Regarding the assignment graph approach, I think that would work if the references are bouncing around strictly between variables, but what if the chain includes any of the more complicated stuff that is currently being tracked, such as various Java expressions, method invocations, conditionals, etc.? > > Consider this example: > > ```java > public class ThisEscapeLoop { > > public ThisEscapeLoop() { > ThisEscapeLoop ref1 = this; > ThisEscapeLoop ref2 = null; > ThisEscapeLoop ref3 = null; > ThisEscapeLoop ref4 = null; > for (int i = 0; i < 100; i++) { > ref4 = this.returnMe(ref3); > ref3 = ref2; > ref2 = ref1; > if (ref4 != null) > ref4.mightLeak(); > } > } > > public T returnMe(T x) { > return x; > } > > public void mightLeak() { > } > } > ``` > > If you are only looking at variable assignments with values that are other variables, then the chain "breaks" when `ref4` is assigned indirectly via `returnMe()`, and you miss the leak. So, in this example though you are calling an instance method before the object is initialized, which would seem to me like a leak (leaving aside heroics to try and chase the method body and see what the body of the method actually does). And, if the method is static, same story - you are passing `ref3` somewhere else, and `ref3` potentially contains `this`. While I know that this is not perfect, and bound to generate false positives, I get the spirit of my question is, really: is there a (much) simpler scheme we can get away with, which has bounded complexity, and which has the property we care about (which seems to be no false negative). I'm less worried about contrived cases emitting false positives, as it's an optional warning that can be shut down - but I'd like perhaps to move the discussion from trying to detect _precisely_ if the leak happens to try to detect if _potentially_ a leak can happen, and see if there's some simpler analysis that can be used to get there (e.g. one which doesn't require flooding). It's possible that you have already considered all these options and the analysis you have here is the best trade off between complexity and precision - but I'd like to have a better understanding of what the trade offs are, and, more importantly, what happens to real code when we tweak the analysis this or that way (as this is a problem where I feel it's easy to get in the land of diminishing returns). ------------- PR: https://git.openjdk.org/jdk/pull/11874 From coleenp at openjdk.org Wed Jan 11 22:09:16 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 11 Jan 2023 22:09:16 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 14:47:45 GMT, Fredrik Bredberg wrote: >> src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. >> >> Note, you changed the initial year. Should be: >> >> - * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights reserved. > > My sed script which updated all copyright headers to 2023 didn't take into account files with only one year in the copyright line. My bad. # foreach f (`cat file.list`) echo $f sed -e "s/Copyright (c) ([12][0-9][0-9][0-9]), [0-9][0-9][0-9][0-9], Oracle/Copyright (c) \1, 2023, Oracle/" \ -e "s/Copyright (c) ([12][0-9][013456789][012456789]), Oracle/Copyright (c) \1, 2023, Oracle/" <$f >$f.new diff $f $f.new mv $f.new $f end ------------- PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Wed Jan 11 22:43:16 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Wed, 11 Jan 2023 22:43:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> Message-ID: On Wed, 11 Jan 2023 21:51:45 GMT, Maurizio Cimadamore wrote: > So, in this example though you are calling an instance method before the object is initialized, which would seem to me like a leak D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold. > And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this. Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it. In other words, any method (or constructor) in the current compilation unit that can't be overridden is never considered "somewhere else". > While I know that this is not perfect, and bound to generate false positives, I get the spirit of my question is, really: is there a (much) simpler scheme we can get away with, which has bounded complexity, and which has the property we care about (which seems to be no false negative). I'm less worried about contrived cases emitting false positives, as it's an optional warning that can be shut down - but I'd like perhaps to move the discussion from trying to detect precisely if the leak happens to try to detect if potentially a leak can happen, and see if there's some simpler analysis that can be used to get there (e.g. one which doesn't require flooding). It's possible that you have already considered all these options and the analysis you have here is the best trade off between complexity and precision - but I'd like to have a better understanding of what the trade offs are, and, more importantly, what happens to real code when we tweak the analysis this or that way (as this is a problem where I feel it's easy to get in the land of diminishing returns). I can only report from my own experience. I thought about this a bit and tried a few different things and what I ended up was the best I could come up with in terms of that trade-off. Of course there was a good bit of intuition and SWAG'ing in that and also a lot of thought experiments. Of course if you have a clever idea for how to do this in a simpler way that achieves basically the same result, I'm all ears :) But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person). A lot of my initial ideas were too simple for my taste, because I could easily find real-world false negatives. An example of "too simple": at first I was not trying to track an outer 'this'. But I found a lot of constructors out there that instantiate nested classes and then do things with them. Without tracking outer 'this' these would all be missed. To take a random example of that: public class FileChooserDemo extends JPanel implements ActionListener { ... public FileChooserDemo() { ... // create a radio listener to listen to option changes OptionListener optionListener = new OptionListener(); // Create options openRadioButton = new JRadioButton("Open"); openRadioButton.setSelected(true); openRadioButton.addActionListener(optionListener); // <- LEAK HERE ... } private class OptionListener implements ActionListener { ... } } That particular leak is (probably) innocuous, but it still qualifies as a leak and should be reported. Note that failing to track an outer 'this' causes false negatives, which are a bigger problem than false positives. On the flip side, I started out trying to explicitly track field references, but that seemed like more complexity than needed, at least for phase 1, so that was left out. The "flooding" aspect didn't really worry me because the reference set is "append only" and there is small, finite set of possible references at each scope, so it can't really get that out of hand. Testing indeed shows it's not a problem. By the way recursion also "floods" until convergence, just like looping. I would have been pleased to find "a much simpler scheme". But the more I thought about those options, the more I came up with easy misses. And after a certain point, it actually became easier to simply "execute" the code by scanning the AST while carrying around a `Set` to track possible references. It's really that simple. Instead of trying to be "smart" we just let the code tell us what happens. Apologies if this is not a very good answer to your question. In the big picture, the false positive rate is traded-off against code complexity, and we want the best possible trade-off, right? But how are you defining "complexity"? If you really mean performance, then I don't see a problem... the JDK build times are essentially unchanged. If you mean lines of code or whatever, then it doesn't seem inordinate. And the algorithm is more or less just an AST scan, like lots of other examples in the compiler code. So I don't see a problem there either. Yes, there may be a much simpler way that's just as good, but if I could have thought of it I would have already. Perhaps you or someone else has better insight. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From ioi.lam at oracle.com Thu Jan 12 00:15:25 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 11 Jan 2023 16:15:25 -0800 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: References: Message-ID: <4ae57b58-3bd6-9a39-b661-69236e36a634@oracle.com> CC-ing serviceability. Hi Yi, In general, I think it's good to have tools for understanding the internal layout of the class metadata layouts. I think there are overlaps between your proposal and existing tools. For example, there are jcmd options such as VM.class_hierarchy and VM.classes, etc. The Serviceability Agent can also be used to analyze the contents of the class metadata. Dd you look at the existing tools and see how they match up with your requirements? I'd be interested in seeing your implementation and compare it with the existing tools. On 1/11/2023 4:56 AM, Yi Yang wrote: > Hi, > > Internally, we often receive feedback from users and ask for help on > metaspace-related issues, for example > 1. Users are eager to know which GroovyClassLoader loads which > classes, why they are not unloaded, > and why they are leading to Metaspace OOME. > 2. They want to know the class structure of dynamically generated > classes in some scenarios such as > deserialization > 3. Finding memory leaking about duplicated classes > ... > Internally we implemented a metaspace dump that generates > human-readable text, it looks something like this: > > [Basic Information] > Dump Reason : JCMD > MaxMetaspaceSize : 18446744073709547520 B > CompressedClassSpaceSize : 1073741824 B > Class Space Used : 309992 B > Class Space Capacity : 395264 B > ... > [Class Loader Data] > ClassLoaderData : loader = 0x000000008024f928, loader_klass = > 0x0000000800010098, loader_klass_name = > sun/misc/Launcher$AppClassLoader, label = N/A > ? Class Used Chunks : > ? ? * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) > ? NonClass Used Chunks : > ? ? * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) > ? Klasses : > ? ? Klass : 0x0000000800060028, name = Test, size = 520 B > ? ? ? ConstantPool : 0x00007fd8379c1050, size = 296 B > ... > > It has been working effectively for several years and has helped many > users solve metaspace-related problems. > But a more user-friendly way is that JDK can inherently support this > capability. We hope that format of the metaspace > dump file can take both flexibility and compatibility into account,? > and the content of dump file should be detailed > enough to meet the needs of both application developers and > lower-level developers. > > Based on above considerations, I think using JSON as its file format > is an appropriate solution(But XML or binary > format are still not excluded as candidates). Specifically, in earlier > thoughts, I thought the format of the metaspace > file could be as follows(pretty printed) > > https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 > > Using the JSON format, we can flexibly add new fields without breaking > compatibility. It is debatable as to which data > to write. We can reach a consensus that third-party parsers(Metaspace > Analyzer Tool) can at least reconstruct Java > source code from the dump file. This may be quite difficult, because the metadata contains rewritten Java bytecodes. The rewriting format may be dependent on the JDK version. Also, the class linkage (the resolution of constant pool information) will be vastly from one JDK version to another. So using writing a third party tool that can work with multiple JDK versions will be quite hard. Also, defining a "portable" format for the dump will be difficult, since we don't know how the internal data structure will evolve in the future. Thanks - Ioi > Based on this, we can write more useful information for low-level > troubleshooting > or debugging. (e.g. the init_state of InstanceKlass). > In addition, we can even output the native code and associated > information with regard to Method, third-party parser > can reconstruct the human-readable assembly representation of the > compiled method based on dump file. To some extent, > we have implemented code cache dump by the way. For this reason, I'm > not sure if the title of the RFC proposal should > be called metaspace dump, maybe metadata dump?? It looks more like a > metadata-dump framework. > > Do you have any thoughts about metaspace/metadata dump? Looking > forward to hearing your feedback, any comments are invaluable! > > Best regards, > Yi Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Thu Jan 12 00:18:11 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 00:18:11 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> Message-ID: On Wed, 11 Jan 2023 22:40:43 GMT, Archie L. Cobbs wrote: > > D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold. > > > And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this. > > Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it. > So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again: ref1 -> ref2 -> ref3 -> x -> ref4 > But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person). The reason I'm asking these questions is that I'm trying to understand which ingredients went into the analysis and why, in order to try and build a mental problem of what the problem that needs to be solved is, what are the constraints, etc. I'm also a practical person :-) and I often find it easier to understand a piece of code if I know some of the reasoning that went behind it, or what's the behavior supposed to be. I do not know, off-hands, whether there is a simpler solution - I was mostly probing for war stories of the kind "I tried X and I got Y", and I apologize if that came off the wrong way. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 02:17:16 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 02:17:16 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> Message-ID: On Thu, 12 Jan 2023 00:15:08 GMT, Maurizio Cimadamore wrote: > So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again: Right - and just to reconfirm, it's only the non-overridable methods in the same compilation unit that are "invoked" (i.e., analyzed & tracked). Any method that (might) exist in another compilation unit is off limits, so we have to assume the worst case and declare a leak if we are passing it any 'this' references. > in order to try and build a mental problem of what the problem that needs to be solved is Gotcha. Let's be clear about what exactly we're worrying about. It's this situation: You have a class `B extends A`, where `B` and `A` are in different compilation units, and during the `super()` call that constructor `B()` makes to its superclass constructor `A()`, some code in class `B` gets executed (really, it's some field in `B` getting accessed that actually matters) prior to `A()` returning. So the basic goal is to analyze `A` constructors and watch 'this' references until if/when they go to someplace where we can no longer watch them. At that point we have to assume that some code in `B` might get invoked and so we generate a warning. OK, so where can a 'this' reference go? Well, here are all of the possible places a Java reference can exist: 1. On the Java stack (a) The current 'this' instance (b) A method parameter (c) A local variable (d) A temporary value that is part of the current expression being evaluated (e) The return value from a method that just returned (f) A caught exception 1. In a field of some object... (a) A normal field (b) An outer 'this' instance (c) Other synthetic field (e.g., captured free variable) 1. As an element in a reference array 1. In native code as a native reference Those are the only possibilities AFAIK. So one way to locate yourself on the spectrum from "simple" to "complex" is to answer this question: Which of those are you going to try to keep track of, and for each one, how hard are you going to try? The `this-escape` analysis being proposed tracks 1(a-e) and 2(b) pretty closely (it tries hard), and it adds a very course tracking of 2(a-c), and 3 using the notion of indirect references (it doesn't try very hard). We do not track 1(f) or 4. So to think about the overall problem, imagine how you might or might not address all of those cases. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From cjplummer at openjdk.org Thu Jan 12 02:28:16 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 12 Jan 2023 02:28:16 GMT Subject: RFR: 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method Message-ID: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> `VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object)` is not used. Furthermore it confuses the reader that runs across `removeObjectMirror()` calls, because what is actually being called is `removeObjectMirror(SoftObjectReference ref)`. ------------- Commit messages: - Remove extra removeObjectMirror() method. Changes: https://git.openjdk.org/jdk/pull/11957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300012 Stats: 18 lines in 1 file changed: 0 ins; 17 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11957/head:pull/11957 PR: https://git.openjdk.org/jdk/pull/11957 From qingfeng.yy at alibaba-inc.com Thu Jan 12 02:52:50 2023 From: qingfeng.yy at alibaba-inc.com (Yi Yang) Date: Thu, 12 Jan 2023 10:52:50 +0800 Subject: =?UTF-8?B?UmU6IFJGQzogcmVnYXJkaW5nIG1ldGFzcGFjZShtZXRhZGF0YT8pIGR1bXA=?= In-Reply-To: <4ae57b58-3bd6-9a39-b661-69236e36a634@oracle.com> References: , <4ae57b58-3bd6-9a39-b661-69236e36a634@oracle.com> Message-ID: Hi Ioi, > I think there are overlaps between your proposal and existing tools. For example, there are jcmd options such as VM.class_hierarchy and VM.classes, etc. > The Serviceability Agent can also be used to analyze the contents of the class metadata. Of course, we can continue to add jcmd commands such as jcmd VM.method_counter and jcmd VM.aggregtate_by_class_package to help diagnosing, but another once and for all solution is to implement a rich and well-formed metadata dump as this proposal described, third-party parsers and platforms are eligible to analyze well-formed dump file and provide many grouping/filtering options(grouping_by_package, filter_linked, filter_force_inline, essentially VM.class_hierarchy is aggregation of VM.classes). I'm trying to describe a real use case to illustrate benefits of well-formed metaspace dump: In our internal DevOps platform, I observed that the Metaspace utilization rate of my application has been high. During this period, FGC occurred several times. So I generate a well-formed metaspace dump through DevOps platform, and then the dump file will be automatically generated and uploaded to another internal Java troubleshooting platform, troubleshooting platform further analyzes and show it with many grouping and filter options and so on. > I'd be interested in seeing your implementation and compare it with the existing tools. I'm starting to do this, and it may take several months to implement since it looks more like a JEP level feature, I want to hear some general discussion before coding, i.e, is it acceptable to use JSON format? should it be Metadata Dump or keeping the current metaspace scope? Do you think basic+extend output for internal structure is acceptable? > This may be quite difficult, because the metadata contains rewritten Java bytecodes. The rewriting format may be dependent on the JDK version. Also, the class linkage (the resolution of constant pool information) will be vastly from one JDK version to another. So using writing a third party tool that can work with multiple JDK versions will be quite hard. Thanks for your input! Maybe display rewrited bytecodes? Anyway, I'll take a close look at this, and I'll prepare a POC along with dump parser and a simple UI diagnose web once ready. > Also, defining a "portable" format for the dump will be difficult, since we don't know how the internal data structure will evolve in the future. Yes, since we don't know how internal data structure will changed in the future, so I propose reaching a consensus that we can at least reconstruct Java (rewrited?) source code as much as possible. For example, the dumped JSON object for InstanceKlass contains two parts, the first part contains the necessary information to reconstruct the source code as much as possible, and the second part is extended information, like this: { name:.., super:.., flags:..., method:[] interface:[] fields:[], annotation:[] bytecode:[], constantpool:[], //extend init_state:..., init_thread:..., } The first part is basically unchanged(or adding new fields only), and the extended part is subject to change, visualization dump client checks if fields of JSON objects are defined and displays them further. ------------------------------------------------------------------ From:Ioi Lam Send Time:2023 Jan. 12 (Thu.) 08:15 To:hotspot-runtime-dev ; serviceability-dev at openjdk.java.net Subject:Re: RFC: regarding metaspace(metadata?) dump CC-ing serviceability. Hi Yi, In general, I think it's good to have tools for understanding the internal layout of the class metadata layouts. I think there are overlaps between your proposal and existing tools. For example, there are jcmd options such as VM.class_hierarchy and VM.classes, etc. The Serviceability Agent can also be used to analyze the contents of the class metadata. Dd you look at the existing tools and see how they match up with your requirements? I'd be interested in seeing your implementation and compare it with the existing tools. On 1/11/2023 4:56 AM, Yi Yang wrote: Hi, Internally, we often receive feedback from users and ask for help on metaspace-related issues, for example 1. Users are eager to know which GroovyClassLoader loads which classes, why they are not unloaded, and why they are leading to Metaspace OOME. 2. They want to know the class structure of dynamically generated classes in some scenarios such as deserialization 3. Finding memory leaking about duplicated classes ... Internally we implemented a metaspace dump that generates human-readable text, it looks something like this: [Basic Information] Dump Reason : JCMD MaxMetaspaceSize : 18446744073709547520 B CompressedClassSpaceSize : 1073741824 B Class Space Used : 309992 B Class Space Capacity : 395264 B ... [Class Loader Data] ClassLoaderData : loader = 0x000000008024f928, loader_klass = 0x0000000800010098, loader_klass_name = sun/misc/Launcher$AppClassLoader, label = N/A Class Used Chunks : * Chunk : [0x0000000800060000, 0x0000000800060230, 0x0000000800060800) NonClass Used Chunks : * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, 0x00007fd8379c2000) Klasses : Klass : 0x0000000800060028, name = Test, size = 520 B ConstantPool : 0x00007fd8379c1050, size = 296 B ... It has been working effectively for several years and has helped many users solve metaspace-related problems. But a more user-friendly way is that JDK can inherently support this capability. We hope that format of the metaspace dump file can take both flexibility and compatibility into account, and the content of dump file should be detailed enough to meet the needs of both application developers and lower-level developers. Based on above considerations, I think using JSON as its file format is an appropriate solution(But XML or binary format are still not excluded as candidates). Specifically, in earlier thoughts, I thought the format of the metaspace file could be as follows(pretty printed) https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 Using the JSON format, we can flexibly add new fields without breaking compatibility. It is debatable as to which data to write. We can reach a consensus that third-party parsers(Metaspace Analyzer Tool) can at least reconstruct Java source code from the dump file. This may be quite difficult, because the metadata contains rewritten Java bytecodes. The rewriting format may be dependent on the JDK version. Also, the class linkage (the resolution of constant pool information) will be vastly from one JDK version to another. So using writing a third party tool that can work with multiple JDK versions will be quite hard. Also, defining a "portable" format for the dump will be difficult, since we don't know how the internal data structure will evolve in the future. Thanks - Ioi Based on this, we can write more useful information for low-level troubleshooting or debugging. (e.g. the init_state of InstanceKlass). In addition, we can even output the native code and associated information with regard to Method, third-party parser can reconstruct the human-readable assembly representation of the compiled method based on dump file. To some extent, we have implemented code cache dump by the way. For this reason, I'm not sure if the title of the RFC proposal should be called metaspace dump, maybe metadata dump? It looks more like a metadata-dump framework. Do you have any thoughts about metaspace/metadata dump? Looking forward to hearing your feedback, any comments are invaluable! Best regards, Yi Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Thu Jan 12 06:00:18 2023 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 11 Jan 2023 22:00:18 -0800 Subject: RFC: regarding metaspace(metadata?) dump In-Reply-To: References: <4ae57b58-3bd6-9a39-b661-69236e36a634@oracle.com> Message-ID: On 1/11/2023 6:52 PM, Yi Yang wrote: > Hi Ioi, > > > I think there are overlaps between your proposal and existing tools. For > example, there are jcmd options such as VM.class_hierarchy and > VM.classes, etc. > > The Serviceability Agent can also be used to analyze the contents of > the class metadata. > > Of course, we can continue to add jcmd commands such as jcmd > VM.method_counter and jcmd VM.aggregtate_by_class_package to help > diagnosing, but another once and for all solution is to implement a > rich and well-formed metadata dump as this proposal described, > third-party parsers and platforms are eligible to analyze well-formed > dump file and provide many grouping/filtering > options(grouping_by_package, filter_linked, filter_force_inline, > essentially VM.class_hierarchy is aggregation of VM.classes). > > I'm trying to describe a real use case to illustrate benefits of > well-formed metaspace dump: In our internal DevOps platform, I > observed that the Metaspace utilization rate of my application has > been high. During this period, FGC occurred several times. So I > generate a well-formed metaspace dump through DevOps platform, and > then the dump file will be automatically generated and uploaded to > another internal Java troubleshooting platform, troubleshooting > platform further analyzes and show it with many grouping and filter > options and so on. > > > I'd be interested in seeing your implementation and compare it with > the existing tools. > > I'm starting to do this, and it may take several months to implement > since it looks more like a JEP level feature, I want to hear some > general discussion before coding, i.e, is it acceptable to use JSON > format? should it be Metadata Dump or keeping the current metaspace > scope? Do you think basic+extend output for internal structure is > acceptable? > Before discussing the output of this tool, I think it's better to first discuss the goals and intended use - For Java app developers, I am not sure if they care about the representation of the classes inside HotSpot. They may want to know what classes are loaded in what class loaders, or want to trouble shoot memory leaks (why aren't my classes unloaded, etc). For these, we already have existing tools. - For HotSpot developers, it would be nice to have a dump of all the metadata, but I am not sure how important this is, as people seem to be able to get by with their own debugging methods. By the way, there may be multiple ways of creating such a dump. The least intrusive way would be to program the Serviceability Agent, which already has a lot of Java APIs to access HotSpot internals. That way, you can write the dumper without modifying the HotSpot C++ code. It could even be maintained as a project outside of the JDK repo. Also you mentioned that "Internally we implemented a metaspace dump that generates human-readable text". Can you share how this tool was implemented? Thanks - Ioi > > This may be quite difficult, because the metadata contains rewritten > Java bytecodes. The rewriting format may be dependent on the JDK > version. Also, the class linkage (the resolution of constant pool > information) will be vastly from one JDK version to another. So using > writing a third party tool that can work with multiple JDK versions > will be quite hard. > > Thanks for your input! Maybe display rewrited bytecodes? Anyway,? I'll > take a close look at this, and I'll prepare a POC along with dump > parser and a simple UI diagnose web once ready. > > > Also, defining a "portable" format for the dump will be difficult, > since we don't know how the internal data structure will evolve in the > future. > > Yes, since we don't know how internal data structure will changed in > the future, so I propose reaching a consensus that we can at least > reconstruct Java (rewrited?) source code as much as possible. For > example, the dumped JSON object for InstanceKlass contains two parts, > the first part contains the necessary information to reconstruct the > source code as much as possible, and the second part is extended > information, like this: > { > name:.., > super:.., > flags:..., > method:[] > interface:[] > fields:[], > annotation:[] > bytecode:[], > constantpool:[], > //extend > init_state:..., > init_thread:..., > } > The first part is basically unchanged(or adding new fields only), and > the extended part is subject to change, visualization dump client > checks if fields of JSON objects are defined and displays them further. > > ------------------------------------------------------------------ > From:Ioi Lam > Send Time:2023 Jan. 12 (Thu.) 08:15 > To:hotspot-runtime-dev ; > serviceability-dev at openjdk.java.net > > Subject:Re: RFC: regarding metaspace(metadata?) dump > > CC-ing serviceability. > > Hi Yi, > > In general, I think it's good to have tools for understanding the > internal layout of the class metadata layouts. > > I think there are overlaps between your proposal and existing > tools. For example, there are jcmd options such as > VM.class_hierarchy and VM.classes, etc. > > The Serviceability Agent can also be used to analyze the contents > of the class metadata. > > Dd you look at the existing tools and see how they match up with > your requirements? > > I'd be interested in seeing your implementation and compare it > with the existing tools. > > > On 1/11/2023 4:56 AM, Yi Yang wrote: > Hi, > > Internally, we often receive feedback from users and ask for help > on metaspace-related issues, for example > 1. Users are eager to know which GroovyClassLoader loads which > classes, why they are not unloaded, > and why they are leading to Metaspace OOME. > 2. They want to know the class structure of dynamically generated > classes in some scenarios such as > deserialization > 3. Finding memory leaking about duplicated classes > ... > Internally we implemented a metaspace dump that generates > human-readable text, it looks something like this: > > [Basic Information] > Dump Reason : JCMD > MaxMetaspaceSize : 18446744073709547520 B > CompressedClassSpaceSize : 1073741824 B > Class Space Used : 309992 B > Class Space Capacity : 395264 B > ... > [Class Loader Data] > ClassLoaderData : loader = 0x000000008024f928, loader_klass = > 0x0000000800010098, loader_klass_name = > sun/misc/Launcher$AppClassLoader, label = N/A > ? Class Used Chunks : > ? ? * Chunk : [0x0000000800060000, 0x0000000800060230, > 0x0000000800060800) > ? NonClass Used Chunks : > ? ? * Chunk : [0x00007fd8379c1000, 0x00007fd8379c1350, > 0x00007fd8379c2000) > ? Klasses : > ? ? Klass : 0x0000000800060028, name = Test, size = 520 B > ? ? ? ConstantPool : 0x00007fd8379c1050, size = 296 B > ... > > It has been working effectively for several years and has helped > many users solve metaspace-related problems. > But a more user-friendly way is that JDK can inherently support > this capability. We hope that format of the metaspace > dump file can take both flexibility and compatibility into > account,? and the content of dump file should be detailed > enough to meet the needs of both application developers and > lower-level developers. > > Based on above considerations, I think using JSON as its file > format is an appropriate solution(But XML or binary > format are still not excluded as candidates). Specifically, in > earlier thoughts, I thought the format of the metaspace > file could be as follows(pretty printed) > > https://gist.github.com/y1yang0/ab3034b6381b8a9d215602c89af4e9c3 > > Using the JSON format, we can flexibly add new fields without > breaking compatibility. It is debatable as to which data > to write. We can reach a consensus that third-party > parsers(Metaspace Analyzer Tool) can at least reconstruct Java > source code from the dump file. > > This may be quite difficult, because the metadata contains > rewritten Java bytecodes. The rewriting format may be dependent on > the JDK version. Also, the class linkage (the resolution of > constant pool information) will be vastly from one JDK version to > another. So using writing a third party tool that can work with > multiple JDK versions will be quite hard. Also, defining a > "portable" format for the dump will be difficult, since we don't > know how the internal data structure will evolve in the future. > > Thanks > - Ioi > > > Based on this, we can write more useful information for low-level > troubleshooting > or debugging. (e.g. the init_state of InstanceKlass). > In addition, we can even output the native code and associated > information with regard to Method, third-party parser > can reconstruct the human-readable assembly representation of the > compiled method based on dump file. To some extent, > we have implemented code cache dump by the way. For this reason, > I'm not sure if the title of the RFC proposal should > be called metaspace dump, maybe metadata dump?? It looks more like > a metadata-dump framework. > > Do you have any thoughts about metaspace/metadata dump? Looking > forward to hearing your feedback, any comments are invaluable! > > Best regards, > Yi Yang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.org Thu Jan 12 07:28:13 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 12 Jan 2023 07:28:13 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> On Wed, 11 Jan 2023 21:29:01 GMT, Xue-Lei Andrew Fan wrote: > > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? > > I'm new to hotspot. Do you know how could I enable C2? Thanks! Never mind, I got it from configuration help message (use --with-jvm-features=compiler2). ------------- PR: https://git.openjdk.org/jdk/pull/11935 From stefank at openjdk.org Thu Jan 12 07:35:15 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 12 Jan 2023 07:35:15 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 20:53:38 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Fix incompatible pointer types > > Signed-off-by: Justin King Thanks for the ZGC update. I have a request to slightly modify the style a bit. Would you mind taking this patch: https://github.com/stefank/jdk/tree/pr_11931 There's a FIXME about that allocation.inline.hpp file is now empty. Will you remove it in this patch? I'd prefer if you did. Alternatively, remove the FIXME from this patch and then immediately clean this up as a separate patch. ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.org/jdk/pull/11931 From alanb at openjdk.org Thu Jan 12 08:09:14 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 08:09:14 GMT Subject: RFR: 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method In-Reply-To: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> References: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> Message-ID: On Thu, 12 Jan 2023 02:20:04 GMT, Chris Plummer wrote: > `VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object)` is not used. Furthermore it confuses the reader that runs across `removeObjectMirror()` calls, because what is actually being called is `removeObjectMirror(SoftObjectReference ref)`. Marked as reviewed by alanb (Reviewer). src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java line 1448: > 1446: } > 1447: > 1448: synchronized void removeObjectMirror(SoftObjectReference ref) { It might able help to make this method removeObjectMirror, this will make it clear that the method can't be called from code in other source files in this package. ------------- PR: https://git.openjdk.org/jdk/pull/11957 From mbaesken at openjdk.org Thu Jan 12 08:20:17 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 12 Jan 2023 08:20:17 GMT Subject: RFR: JDK-8299957: Enhance error logging in instrument coding with additional jplis_assert_msg Message-ID: There are a few places in the instrument coding where errors occur in our jtreg test, but the already existing error logging method jplis_assert_msg / jplis_assert is unfortunately missing so not much details are shown. This could be enhanced. ------------- Commit messages: - JDK-8299957 Changes: https://git.openjdk.org/jdk/pull/11960/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11960&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299957 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11960.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11960/head:pull/11960 PR: https://git.openjdk.org/jdk/pull/11960 From mcimadamore at openjdk.org Thu Jan 12 10:00:21 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 10:00:21 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> Message-ID: On Thu, 12 Jan 2023 02:14:10 GMT, Archie L. Cobbs wrote: >>> >>> D'oh, you're right. But if you made `returnMe()` static or private then the argument would still hold. >>> >>> > And, if the method is static, same story - you are passing ref3 somewhere else, and ref3 potentially contains this. >>> >>> Not true... static methods are safe to "invoke" because they can't be overridden. When the analyzer "invokes" the method, it will see that all it does with its parameter is return it. >>> >> >> So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again: >> >> ref1 -> ref2 -> ref3 -> x -> ref4 >> >>> But I don't really have an analysis of all the trade-offs. Really, at a certain point I stumbled on what I thought was a fairly straightforward way to achieve a good false negative rate and a very low false positive rate, without a lot of work. And frankly at that point I stopped caring about the question you're asking, although I agree it's certainly interesting from an academic point of view (I'm a practical person). >> >> The reason I'm asking these questions is that I'm trying to understand which ingredients went into the analysis and why, in order to try and build a mental problem of what the problem that needs to be solved is, what are the constraints, etc. I'm also a practical person :-) and I often find it easier to understand a piece of code if I know some of the reasoning that went behind it, or what's the behavior supposed to be. >> >> I do not know, off-hands, whether there is a simpler solution - I was mostly probing for war stories of the kind "I tried X and I got Y", and I apologize if that came off the wrong way. > >> So, for static methods, it could go down two ways: either we don't even look at referenced method bodies, give up and just declare "sorry, escaping". Or, if we look into method bodies, and see that the relationship between inner and outer parameter is as simple, it's just like assignment again: > > Right - and just to reconfirm, it's only the non-overridable methods in the same compilation unit that are "invoked" (i.e., analyzed & tracked). Any method that (might) exist in another compilation unit is off limits, so we have to assume the worst case and declare a leak if we are passing it any 'this' references. > >> in order to try and build a mental problem of what the problem that needs to be solved is > > Gotcha. > > Let's be clear about what exactly we're worrying about. It's this situation: You have a class `B extends A`, where `B` and `A` are in different compilation units, and during the `super()` call that constructor `B()` makes to its superclass constructor `A()`, some code in class `B` gets executed (really, it's some field in `B` getting accessed that actually matters) prior to `A()` returning. > > So the basic goal is to analyze `A` constructors and watch 'this' references until if/when they go to someplace where we can no longer watch them. At that point we have to assume that some code in `B` might get invoked and so we generate a warning. > > OK, so where can a 'this' reference go? > > Well, here are all of the possible places a Java reference can exist: > 1. On the Java stack > (a) The current 'this' instance > (b) A method parameter > (c) A local variable > (d) A temporary value that is part of the current expression being evaluated > (e) The return value from a method that just returned > (f) A caught exception > 1. In a field of some object... > (a) A normal field > (b) An outer 'this' instance > (c) Other synthetic field (e.g., captured free variable) > 1. As an element in a reference array > 1. In native code as a native reference > > Those are the only possibilities AFAIK. > > So one way to locate yourself on the spectrum from "simple" to "complex" is to answer this question: Which of those are you going to try to keep track of, and for each one, how hard are you going to try? > > The `this-escape` analysis being proposed tracks 1(a-e) and 2(b) pretty closely (it tries hard), and it adds a very course tracking of 2(a-c), and 3 using the notion of indirect references (it doesn't try very hard). We do not track 1(f) or 4. > > So to think about the overall problem, imagine how you might or might not address all of those cases. > * On the Java stack > (a) The current 'this' instance > (b) A method parameter > (c) A local variable > (d) A temporary value that is part of the current expression being evaluated > (e) The return value from a method that just returned > (f) A caught exception > > * In a field of some object... > (a) A normal field > (b) An outer 'this' instance > (c) Other synthetic field (e.g., captured free variable) > > * As an element in a reference array > > * In native code as a native reference Thanks for the classification. This is helpful. I'm not sure what you mean by (1f). You mean `this` can be embedded in an exception being thrown? Is that different from (2)? Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies. When looking at (2d) and (2e) the fact that Javac's AST is not in SSA form means that, yes, we need to track _expressions_ not just variables (e.g. for chains of methods calls, ternary operators and such). ------------- PR: https://git.openjdk.org/jdk/pull/11874 From fyang at openjdk.org Thu Jan 12 11:22:17 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 12 Jan 2023 11:22:17 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 09:22:03 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated some copyright dates. Also verified on linux-riscv64 HiFive Unmatched board running hotspot_loom & jdk_loom jtreg tests with extra VM options: -XX:+VerifyStack -XX:+VerifyContinuations. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From djelinski at openjdk.org Thu Jan 12 11:43:24 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 12 Jan 2023 11:43:24 GMT Subject: RFR: 8300024: Replace use of JNI_COMMIT mode with mode 0 Message-ID: Please review this patch that fixes a few memory leaks in JNI code. [The latest documentation](https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#releaseprimitivetypearrayelements-routines) of JNI functions makes an explicit note about the use of JNI_COMMIT: > If `JNI_COMMIT` is passed as the `mode` argument when `elems` is a copy of the elements in `array`, then a final call to *ReleaseArrayElements* passing a `mode` argument of "0" or `JNI_ABORT`, should be made to free the `elems` buffer No new regression test. I manually verified the Linux fix using ClhdsbPstack test in root mode. Also, tier1-2 tests on mach5 continue to pass. ------------- Commit messages: - Fix release mode Changes: https://git.openjdk.org/jdk/pull/11963/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11963&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300024 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11963.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11963/head:pull/11963 PR: https://git.openjdk.org/jdk/pull/11963 From ihse at openjdk.org Thu Jan 12 12:16:18 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 12 Jan 2023 12:16:18 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Use the more appropriate Type comparison method Types.isSameType(). > - Add some more comments to clarify how the analysis works. FWIW, the make changes look good. I have nothing to say about the actual lint code itself. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 12:31:39 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 12:31:39 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Use the more appropriate Type comparison method Types.isSameType(). > - Add some more comments to clarify how the analysis works. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 163: > 161: * invoked from the target constructor; if empty, we're still in the constructor. > 162: */ > 163: private final ArrayDeque callStack = new ArrayDeque<>(); There is a concept of push/popScope and then there's a separate concept of call stack (which is just a list of diagnostic position up to the point). I wonder if this could be better modeled by using a single class e.g. Scope/Frame which has a diagnostic position, plus other useful things. Perhaps it might even be helpful to have a ref set on each scope, so that you don't have to attach a "depth" to each ref - the depth of the ref would be determined by the "scope" in which it appears. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 175: > 173: private DiagnosticPosition[] pendingWarning; > 174: > 175: // These fields are scoped to the CONSTRUCTOR OR INVOKED METHOD BEING ANALYZED Watch out for "all caps" src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218: > 216: new TreeScanner() { > 217: > 218: private Lint lint = ThisEscapeAnalyzer.this.lint; On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 220: > 218: private Lint lint = ThisEscapeAnalyzer.this.lint; > 219: private JCClassDecl currentClass; > 220: private boolean privateOuter; I don't think this is needed - see below src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 227: > 225: final boolean privateOuterPrev = this.privateOuter; > 226: final Lint lintPrev = this.lint; > 227: this.lint = this.lint.augment(tree.sym); general stylistic comment - I see here and everywhere in this class `this.xyz` - this is not the norm in the rest of the javac codebase, and it would be better to replace it with just `xyz` src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 230: > 228: try { > 229: this.currentClass = tree; > 230: this.privateOuter |= tree.sym.isAnonymous(); These can be inlined in the check below src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 270: > 268: final boolean analyzable = this.currentClassIsExternallyExtendable() && > 269: TreeInfo.isConstructor(tree) && > 270: !tree.sym.isPrivate() && Why aren't private constructors analyzed? If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes `this` escape, isn't that an issue we should detect? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294: > 292: !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) && > 293: !(this.currentClass.sym.owner.kind == MTH) && > 294: !this.privateOuter; Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 304: > 302: > 303: // We are looking for analyzable constructors only > 304: final Symbol sym = entry.getKey(); This seems unused. And, if so, perhaps we only need a `Set`, not a map. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 348: > 346: final Comparator ordering = (warning1, warning2) -> { > 347: for (int index1 = 0, index2 = 0; true; index1++, index2++) { > 348: final boolean end1 = index1 >= warning1.length; Another stylistic comment - the `final` here is not super helpful. The compiler performs effectively final analysis, so if your locals are only written once, you are good to go - and can even use them inside lambdas. From a documentation perspective it might carry a bit of value, but again, the rest of the javac code generally doesn't do that. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411: > 409: final boolean referenceExpressionNode; > 410: switch (tree.getTag()) { > 411: case CASE: surprised to see `CASE` here - as that's not an expression src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 444: > 442: if (referenceExpressionNode) { > 443: > 444: // We treat instance methods as having a "value" equal to their instance The comment is slightly misleading - e.g. I'd suggest clarifying "having a "value" whose type is the same as that of the class in which the method is defined" src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454: > 452: > 453: // If the expression type is incompatible with 'this', discard it > 454: if (type != null && !this.isSubtype(this.targetClass.sym.type, type)) Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 504: > 502: // Recurse on method expression > 503: this.scan(invoke.meth); > 504: final boolean direct = this.refs.remove(ExprRef.direct(this.depth)); Understanding checkpoint. Considering this code: rec.m() There are two cases: * `rec` might be a direct reference to this (e.g. a local) * `rec` might be an indirect reference to this (a lambda containing `this`) So the receiver of the method might be direct or indirect. This will then determine how to interpret `this` in the context of that method analysis - e.g. when we see a `JCIdent` for `this`, we create a direct/indirect `ExprRef` based on what the receiver kind was. Correct? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 817: > 815: // Methods - the "value" of a non-static method is a reference to its instance > 816: final Symbol sym = tree.sym; > 817: if (sym.kind == MTH) { This is perhaps where filtering based on the declaring class could make sense (to avoid having to filter later) ? Perhaps this could also be centralized - e.g. whenever you create an ExprRef you also pass the type for it, and if the type matches that for the current class you create it and add to the list, otherwise you skip it. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875: > 873: // Reference to this? > 874: if (tree.name == names._this || tree.name == names._super) { > 875: if (this.refs.contains(ThisRef.direct())) This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 900: > 898: final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type; > 899: final Type methodOwnerType = sym.owner.type; > 900: if (this.isSubtype(currentClassType, methodOwnerType)) { I believe what you need here is not subtyping but subclassing - see `Symbol.isSubclass` src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909: > 907: > 908: // Check for implicit outer 'this' reference > 909: if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { Similarly here - look for `Symbol.isEnclosedBy` src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1302: > 1300: * In other words, a reference that's sitting on top of the stack. > 1301: */ > 1302: private static class ExprRef extends Ref { Maybe I'm wrong - but it seems that the only thing we need to track is whether the top of stack (e.g. last evaluated expression) has a direct reference or indirect reference (or none). Do we really need a set for this? (this seems the same as for ThisRef which is used inside method, which can be one of the same three options). While I do see value for tracking which variables are aliases for this (either direct or indirect), it seems like (at least on a superficial look) that expression refs might be replaced by a visitor field/parameter. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1319: > 1317: /** A reference from the return value of the current method being "invoked". > 1318: */ > 1319: private static class ReturnRef extends Ref { Isn't this just an ExprRef? This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth). ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 13:04:18 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 13:04:18 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Use the more appropriate Type comparison method Types.isSameType(). > - Add some more comments to clarify how the analysis works. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 334: > 332: // of the stack trace of B. For example, if constructor Foo(int x) has a leak, and constructor > 333: // Foo() invokes this(0), then emitting a warning for Foo() would be redundant. > 334: final BiPredicate extendsAsPrefix = (warning1, warning2) -> { Another strategy would be to give a single warning per leaking constructor. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From djelinski at openjdk.org Thu Jan 12 13:11:57 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 12 Jan 2023 13:11:57 GMT Subject: RFR: 8300032: DwarfParser resource leak Message-ID: Please review this fix for DwarfParser cleaner. The original code registered the cleaner using a lambda that captured a reference to the parser object; as a result, the object was never GCed, and the cleaner never ran. In this version I moved the lambda creation to a static method, so that it can't capture a reference to the parser. Additionally, the new code uses a static cleaner; the cleaner object creation and cleanup are heavy operations (every cleaner comes with its own thread), and it's preferable to use a single shared cleaner where possible. I verified manually that the native `destroyDwarfContext` method is called after this fix. No new automated test. Existing tier1-2 tests continue to pass. ------------- Commit messages: - Fix dwarf cleaner Changes: https://git.openjdk.org/jdk/pull/11965/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11965&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300032 Stats: 8 lines in 1 file changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11965.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11965/head:pull/11965 PR: https://git.openjdk.org/jdk/pull/11965 From duke at openjdk.org Thu Jan 12 15:02:22 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 15:02:22 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> Message-ID: On Thu, 12 Jan 2023 09:57:00 GMT, Maurizio Cimadamore wrote: > I'm not sure what you mean by (1f). You mean this can be embedded in an exception being thrown? Is that different from (2)? Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it. An example of how this could happen would be: public class ThrownThis extends RuntimeException { public ThrownThis(Object obj) { try { this.validate(obj); } catch (RuntimeException e) { e.mightLeak(); // LEAK HERE } } private void validate(Object obj) { if (obj.hashCode() != 123) throw this; } public void mightLeak() { } } Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible. Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble. As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss! > Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies. Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 15:12:56 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 15:12:56 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> Message-ID: On Thu, 12 Jan 2023 14:59:12 GMT, Archie L. Cobbs wrote: >>> * On the Java stack >>> (a) The current 'this' instance >>> (b) A method parameter >>> (c) A local variable >>> (d) A temporary value that is part of the current expression being evaluated >>> (e) The return value from a method that just returned >>> (f) A caught exception >>> >>> * In a field of some object... >>> (a) A normal field >>> (b) An outer 'this' instance >>> (c) Other synthetic field (e.g., captured free variable) >>> >>> * As an element in a reference array >>> >>> * In native code as a native reference >> >> Thanks for the classification. This is helpful. >> >> I'm not sure what you mean by (1f). You mean `this` can be embedded in an exception being thrown? Is that different from (2)? >> >> Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies. >> >> When looking at (2d) and (2e) the fact that Javac's AST is not in SSA form means that, yes, we need to track _expressions_ not just variables (e.g. for chains of methods calls, ternary operators and such). > >> I'm not sure what you mean by (1f). You mean this can be embedded in an exception being thrown? Is that different from (2)? > > Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it. > > An example of how this could happen would be: > > public class ThrownThis extends RuntimeException { > > public ThrownThis(Object obj) { > try { > this.validate(obj); > } catch (RuntimeException e) { > e.mightLeak(); // LEAK HERE > } > } > > private void validate(Object obj) { > if (obj.hashCode() != 123) > throw this; > } > > public void mightLeak() { > } > } > > Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible. > > Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble. > > As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss! > >> Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies. > > Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out. > Yes, this would be a different case from any other that you'd have to handle in the code if you wanted to deal with it. > > An example of how this could happen would be: > > ```java > public class ThrownThis extends RuntimeException { > > public ThrownThis(Object obj) { > try { > this.validate(obj); > } catch (RuntimeException e) { > e.mightLeak(); // LEAK HERE > } > } > > private void validate(Object obj) { > if (obj.hashCode() != 123) > throw this; > } > > public void mightLeak() { > } > } > ``` > Interesting example - I thought you might have been referring to a case where the class being analyzed was itself an exception. Question - shouldn't we conclude that `this` leak when we see `throw this` ? E.g. what if the constructor did not have a `catch` (or if the catch was of a different type) ? > Of course, that's an absurd example and the likelihood that any random piece of actually code does that is negligible. > > Regardless, I did briefly consider including handling for thrown exceptions but quickly decided it couldn't possibly be worth the trouble. > > As a result, if you compile that example with `-Xlint:this-escape` you don't get a warning. No major loss! > > > Also, it seems to me that (3) is a special case of (2) - in the sense that you can imagine a reference array as a big object that has many fields as there are elements - so the same reasoning applies. > > Yes it's effectively the same thing, but fields and array elements are accessed by different mechanisms in Java, so from the point of the analyzer they have to be handled separately for that reason, which is why I broke them out. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 15:19:44 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 15:19:44 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 13:01:44 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the more appropriate Type comparison method Types.isSameType(). >> - Add some more comments to clarify how the analysis works. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 334: > >> 332: // of the stack trace of B. For example, if constructor Foo(int x) has a leak, and constructor >> 333: // Foo() invokes this(0), then emitting a warning for Foo() would be redundant. >> 334: final BiPredicate extendsAsPrefix = (warning1, warning2) -> { > > Another strategy would be to give a single warning per leaking constructor. We already impose a limit of at most one warning per constructor. But for this limit what is technically meant by "per constructor" is "At most one warning per constructor, assuming that constructor is the one being analyzed (i.e., the one invoked by the subclass and not via `this()`)." So that limitation doesn't stop a constructor from generating the same warning multiple times due to it being invoked indirectly by other constructors via `this()`. Those duplicate warnings are what the code above eliminates. So this code only generates one warning, and it's reported for the second constructor: public class DupWarn1 { public DupWarn1() { this(0); } public DupWarn1(int x) { this.mightLeak(); } public void mightLeak() { } } DupWarn1.java:8: warning: [this-escape] possible 'this' escape before subclass is fully initialized this.mightLeak(); ^ This is appropriate. The leak is really in the second constructor; the first constructor has nothing to do with it. Reporting a leak for both constructors would be redundant. An interesting side question: Is it possible to come up with an example where constructor A has a 'this' leak, and some other constructor B invokes `this()` to delegate to A, but when B delegates to A the leak occurs differently, or not at all? Because of the "flood" analysis, and the fact that you can't pass 'this' references to `this()` or `super()` (these are static contexts), I don't think it's possible. So in fact the deduplication will always apply whenever `this()` is involved. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 15:29:30 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 15:29:30 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5] In-Reply-To: References: <_GkLRl5VTNh8ToJ3cjF-_v9j6eWWQzbUCCKStOXKh4g=.5e9505f1-8182-47e6-a8ed-78982db36c94@github.com> <0VZaG4s1DCehTwPfEshM6Lt90CKit-D-w_4F8NzAw8c=.b515334e-a4d3-495d-afae-6e4aa45ff683@github.com> <8RxCBaG_JM-5ej97lG5SDVzelH018OXgboI FFvs0hmQ=.ec5da5d8-01db-4797-938b-0419a3c1d2ec@github.com> Message-ID: On Thu, 12 Jan 2023 15:10:19 GMT, Maurizio Cimadamore wrote: > Interesting example - I thought you might have been referring to a case where the class being analyzed was itself an exception. Yes - although that example doesn't compile (oops!). Just replace `catch (RuntimeException e)` with `catch (ThrownThis e)` and it should. > Question - shouldn't we conclude that this leak when we see throw this ? E.g. what if the constructor did not have a catch (or if the catch was of a different type) ? A thorough analysis would evaluate whether the exception was caught or not. But you're right - since we're not doing a thorough analysis, we should immediately declare a leak anytime we see `throw x` where `x` is a possible direct or indirect reference. Of course, this scenario should be unlikely in normal code. I will add a check for that. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 16:06:28 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 16:06:28 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 10:18:27 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the more appropriate Type comparison method Types.isSameType(). >> - Add some more comments to clarify how the analysis works. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294: > >> 292: !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) && >> 293: !(this.currentClass.sym.owner.kind == MTH) && >> 294: !this.privateOuter; > > Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe Unless you explicitly declare a nested class `private`, it won't have the `ACC_PRIVATE` flag, even though it is "implicitly private" because it has a `private` enclosing class. Example: $ cat PrivateOuter.java public class PrivateOuter { private static class Inner1 { static class Inner2 { } } } $ javap -v PrivateOuter$Inner1$Inner2 Classfile /Users/archie/proj/jdk/flex-test/classes/PrivateOuter$Inner1$Inner2.class Last modified Jan 12, 2023; size 408 bytes SHA-256 checksum 51ba6d39a5e66df2a078761d6424acbea7a8e32b8451f6ca7d2af49889673b2c Compiled from "PrivateOuter.java" class PrivateOuter$Inner1$Inner2 minor version: 0 major version: 63 flags: (0x0020) ACC_SUPER this_class: #7 // PrivateOuter$Inner1$Inner2 super_class: #2 // java/lang/Object ... So we have to keep track of this "implicit privateness" manually, which is what the `privateOuter` flag is for. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From dfuchs at openjdk.org Thu Jan 12 16:15:13 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 12 Jan 2023 16:15:13 GMT Subject: RFR: 8300032: DwarfParser resource leak In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 12:08:51 GMT, Daniel Jeli?ski wrote: > Please review this fix for DwarfParser cleaner. > > The original code registered the cleaner using a lambda that captured a reference to the parser object; as a result, the object was never GCed, and the cleaner never ran. > > In this version I moved the lambda creation to a static method, so that it can't capture a reference to the parser. > > Additionally, the new code uses a static cleaner; the cleaner object creation and cleanup are heavy operations (every cleaner comes with its own thread), and it's preferable to use a single shared cleaner where possible. > > I verified manually that the native `destroyDwarfContext` method is called after this fix. No new automated test. Existing tier1-2 tests continue to pass. Though I am not a usual reviewer for this area I believe the logic of your change is good. Please obtain the review from a maintainer of the area before integrating. ------------- PR: https://git.openjdk.org/jdk/pull/11965 From duke at openjdk.org Thu Jan 12 16:24:37 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 16:24:37 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> On Thu, 12 Jan 2023 10:25:27 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the more appropriate Type comparison method Types.isSameType(). >> - Add some more comments to clarify how the analysis works. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218: > >> 216: new TreeScanner() { >> 217: >> 218: private Lint lint = ThisEscapeAnalyzer.this.lint; > > On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider. Two things... We need to support annotations on field declarations because their initializers are effectively mini-constructors. But we don't need it on local variables, parameters, etc. - too confusing. For annotations on methods, yes it's debatable. It can be handy if you have e.g. an `init()` method that all of your constructors invoke. However, I agree it's also confusing, so I will remove. But we should keep the notion that if a constructor invokes `this()`, and the invoked constructor has annotations suppressed, then we skip over the constructor invocation. I will make these updates. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 304: > >> 302: >> 303: // We are looking for analyzable constructors only >> 304: final Symbol sym = entry.getKey(); > > This seems unused. And, if so, perhaps we only need a `Set`, not a map. Thanks, you're right, the map keys are not used here. I'll clean up the loop. But we still need a map, not a set, because the map is used elsewhere. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 16:31:21 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 16:31:21 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 10:32:19 GMT, Maurizio Cimadamore wrote: > If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes this escape, isn't that an issue we should detect? A static factory method will not create a subclassed instance, so there's no 'this' escape problem. But I admit I completely missed factory methods as a potential thing to worry about. Is it possible for a leak to be missed due to the use of a factory method? Hmm. I can't immediately think of how, but if you can come up with an example please share. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From cjplummer at openjdk.org Thu Jan 12 16:44:44 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 12 Jan 2023 16:44:44 GMT Subject: RFR: 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method [v2] In-Reply-To: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> References: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> Message-ID: > `VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object)` is not used. Furthermore it confuses the reader that runs across `removeObjectMirror()` calls, because what is actually being called is `removeObjectMirror(SoftObjectReference ref)`. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Make removeObjectMirror() private. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11957/files - new: https://git.openjdk.org/jdk/pull/11957/files/fa48e07c..dbd2f3d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11957&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11957&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11957/head:pull/11957 PR: https://git.openjdk.org/jdk/pull/11957 From mcimadamore at openjdk.org Thu Jan 12 16:46:31 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 16:46:31 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Thu, 12 Jan 2023 16:20:12 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 218: >> >>> 216: new TreeScanner() { >>> 217: >>> 218: private Lint lint = ThisEscapeAnalyzer.this.lint; >> >> On a first look I'm not sure about the granularity of suppression here. I believe that suppressing at the class level, or at the constructor level is enough. Allowing to further annotate var declarations and non-constructor methods, while doable, might actually be counter productive - in the sense that the annotation does not occur in the constructor (where you'd want to see it) but in some other method. I think the fact that a constructor is escaping (willingly) should be a visible thing. Something to consider. > > Two things... > > We need to support annotations on field declarations because their initializers are effectively mini-constructors. But we don't need it on local variables, parameters, etc. - too confusing. > > For annotations on methods, yes it's debatable. It can be handy if you have e.g. an `init()` method that all of your constructors invoke. However, I agree it's also confusing, so I will remove. > > But we should keep the notion that if a constructor invokes `this()`, and the invoked constructor has annotations suppressed, then we skip over the constructor invocation. > > I will make these updates. Yep - I guess there's a general theme of "where do we want the warnings to be reported". My general feeling is that reporting a warning on the constructor might be enough - but I see that you try to generate a warning in the exact spot where the leakage happens - which I'm not sure if it's ok, or too clever. >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 270: >> >>> 268: final boolean analyzable = this.currentClassIsExternallyExtendable() && >>> 269: TreeInfo.isConstructor(tree) && >>> 270: !tree.sym.isPrivate() && >> >> Why aren't private constructors analyzed? If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes `this` escape, isn't that an issue we should detect? > >> If we have a class with a private constructor and public static factory invoking said constructor, and the constructor makes this escape, isn't that an issue we should detect? > > A static factory method will not create a subclassed instance, so there's no 'this' escape problem. > > But I admit I completely missed factory methods as a potential thing to worry about. > > Is it possible for a leak to be missed due to the use of a factory method? > > Hmm. I can't immediately think of how, but if you can come up with an example please share. I guess what I'm thinking about: class Foo { private Foo() { m(this); } public void m() { ... } // overridable static Foo makeFoo() { return new Foo(); } } >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 294: >> >>> 292: !(this.currentClass.sym.isSealed() && this.currentClass.permitting.isEmpty()) && >>> 293: !(this.currentClass.sym.owner.kind == MTH) && >>> 294: !this.privateOuter; >> >> Here, note that is the owner of the current class symbol is a method, that covers anonymous classes too, which is a part of `privateOuter`. So the only think we need to check here is whether "currentClass" is private, which is a simple predicate. No need to carry `privateOuter` I believe > > Unless you explicitly declare a nested class `private`, it won't have the `ACC_PRIVATE` flag, even though it is "implicitly private" because it has a `private` enclosing class. > > Example: > > $ cat PrivateOuter.java > public class PrivateOuter { > private static class Inner1 { > static class Inner2 { > } > } > } > $ javap -v PrivateOuter$Inner1$Inner2 > Classfile /Users/archie/proj/jdk/flex-test/classes/PrivateOuter$Inner1$Inner2.class > Last modified Jan 12, 2023; size 408 bytes > SHA-256 checksum 51ba6d39a5e66df2a078761d6424acbea7a8e32b8451f6ca7d2af49889673b2c > Compiled from "PrivateOuter.java" > class PrivateOuter$Inner1$Inner2 > minor version: 0 > major version: 63 > flags: (0x0020) ACC_SUPER > this_class: #7 // PrivateOuter$Inner1$Inner2 > super_class: #2 // java/lang/Object > ... > > > So we have to keep track of this "implicit privateness" manually, which is what the `privateOuter` flag is for. D'oh - missed the `|=` - so this keeps updating... ------------- PR: https://git.openjdk.org/jdk/pull/11874 From alanb at openjdk.org Thu Jan 12 16:52:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 12 Jan 2023 16:52:19 GMT Subject: RFR: 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method [v2] In-Reply-To: References: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> Message-ID: On Thu, 12 Jan 2023 16:44:44 GMT, Chris Plummer wrote: >> `VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object)` is not used. Furthermore it confuses the reader that runs across `removeObjectMirror()` calls, because what is actually being called is `removeObjectMirror(SoftObjectReference ref)`. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Make removeObjectMirror() private. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11957 From stuefe at openjdk.org Thu Jan 12 16:55:35 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 12 Jan 2023 16:55:35 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:49:59 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional commit since the last revision: >> >> Initialize memory to zero in zGranuleMap >> >> Signed-off-by: Justin King > > Curious, I always thought we do ArrayAllocator - using mmap for larger allocations - to prevent memory retention for libc variants whose allocators are "grabby", i.e. which don't promptly return memory to the OS on free(). E.g. because they only use sbrk (Solaris, AIX), or are just cautious about returning memory (glibc). > > Glibc's retention problem is only relevant for fine-grained allocations, so for glibc this is probably fine. This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment ? Does free'd memory still stick to the process? > > (While writing this, I remember that we at SAP even rewrote Arena allocation to use mmap for AIX, because large compile arenas caused lasting RSS increase, so it has definitely been a problem in the past) > > To follow up on @tstuefe comment - and the one that I tried to say in the bug was that we added this MmapArrayAllocate feature for some G1 marking bits that used so much memory that hit the Solaris _sbrk issue. Maybe @stefank and @tschatzl remember this issue. Maybe it's ok for AIX, then removing this code is a good change. Maybe the G1 usages need a mmap implementation though. > > The padding.inline.hpp usage seems to have one caller which is called once. The other mmap usage in G1 we can convert to mmap using a similar approach to zGranuleMap if that is preferred. That would then be equivalent behavior, it looks like the G1 code uses the page allocation granularity anyway so maybe keeping it mmap is the better way to go here anyway? My uninformed opinion (I'm not the G1 code owner) is that it would be fine to use explicit mmap. I'd love the complexity reduction this patch brings. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From duke at openjdk.org Thu Jan 12 16:55:39 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 16:55:39 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 10:48:49 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the more appropriate Type comparison method Types.isSameType(). >> - Add some more comments to clarify how the analysis works. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 227: > >> 225: final boolean privateOuterPrev = this.privateOuter; >> 226: final Lint lintPrev = this.lint; >> 227: this.lint = this.lint.augment(tree.sym); > > general stylistic comment - I see here and everywhere in this class `this.xyz` - this is not the norm in the rest of the javac codebase, and it would be better to replace it with just `xyz` OK. I will reluctantly remove... `` > Why on earth wouldn't you want to make it clear which one of N outer classes a field comes from, and that it's a field, and not a variable declared somewhere off screen?? > > IMHO omitting 'this' qualifiers is effectively accepting the grave offense of code obfuscation in exchange for a tiny smidgen of brevity. > > It's definitely made it harder for me to read and understand the compiler, with all the levels of nesting it has. > `` I readily admit I'm probably in the minority on this and anyway it's a bikeshed thing so there's no point in debating it. I will go with the flow :) though I feel a little sorry for the next person who has to read this code. > From a documentation perspective it might carry a bit of value Yes, that's the purpose - the `final` is for the human viewer, not the compiler. Just trying to be helpful to the next person. But you're right it's inconsistent so I'll remove. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 17:16:34 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 17:16:34 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 10:56:53 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the more appropriate Type comparison method Types.isSameType(). >> - Add some more comments to clarify how the analysis works. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411: > >> 409: final boolean referenceExpressionNode; >> 410: switch (tree.getTag()) { >> 411: case CASE: > > surprised to see `CASE` here - as that's not an expression I put it there because of switch expressions and `yeild`... ? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From vromero at openjdk.org Thu Jan 12 17:43:26 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 12 Jan 2023 17:43:26 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Use the more appropriate Type comparison method Types.isSameType(). > - Add some more comments to clarify how the analysis works. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 200: > 198: // > 199: > 200: public void analyzeTree(Env env) { nit: this method could be removed in favor of the overloaded version below src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 204: > 202: } > 203: > 204: public void analyzeTree(Env env, JCTree tree) { nit: `env` parameter doesn't seem to be used could be dropped I think ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 17:43:30 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 17:43:30 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 17:13:55 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 411: >> >>> 409: final boolean referenceExpressionNode; >>> 410: switch (tree.getTag()) { >>> 411: case CASE: >> >> surprised to see `CASE` here - as that's not an expression > > I put it there because of switch expressions and `yeild`... ? Well, yield can... yield a value - `case` doesn't. So I'm confused. Also because the variable is called `referenceExpressionNode` and `CASE` is not an expression. Can `CASE` leave anything on the stack? YIELD does, but CASE? >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454: >> >>> 452: >>> 453: // If the expression type is incompatible with 'this', discard it >>> 454: if (type != null && !this.isSubtype(this.targetClass.sym.type, type)) >> >> Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch? > > No because (for example) what if you cast? > > The thing you're casting might be compatible, but after the cast it might become incompatible. Uhm. Turns out I probably did not understand the filter correctly, and now I'm more dubious about what it actually does. Say you have this hierarchy: interface A { } class B { B() { A a = (A)this; ... } } class C extends B implements A { } ``` Pathological case, I know. But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated). ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 17:43:36 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 17:43:36 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 11:09:35 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the more appropriate Type comparison method Types.isSameType(). >> - Add some more comments to clarify how the analysis works. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 444: > >> 442: if (referenceExpressionNode) { >> 443: >> 444: // We treat instance methods as having a "value" equal to their instance > > The comment is slightly misleading - e.g. I'd suggest clarifying "having a "value" whose type is the same as that of the class in which the method is defined" Agreed - will fix. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 454: > >> 452: >> 453: // If the expression type is incompatible with 'this', discard it >> 454: if (type != null && !this.isSubtype(this.targetClass.sym.type, type)) > > Instead of adding the direct reference, and then having to check if the reference needs to be removed, would it be possible not to add the reference in the first place if the types mismatch? No because (for example) what if you cast? The thing you're casting might be compatible, but after the cast it might become incompatible. > This will then determine how to interpret this in the context of that method analysis - e.g. when we see a JCIdent for this, we create a direct/indirect ExprRef based on what the receiver kind was. Correct? Yes, exactly. When we "invoke" a method, we "preload" the set of current references that the method is going to have when it starts. That "preload" step includes any references from (a) the method receiver (non-static methods only) and (b) method parameters. To the extent the method receiver has a direct/indirect reference, that turns into a direct/indirect `ThisRef` during method execution. You can see this happen in the very next lines after what you quoted. But of course the method invocation (the "apply") could have been applied to any arbitrary expression as the receiver. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 817: > >> 815: // Methods - the "value" of a non-static method is a reference to its instance >> 816: final Symbol sym = tree.sym; >> 817: if (sym.kind == MTH) { > > This is perhaps where filtering based on the declaring class could make sense (to avoid having to filter later) ? Perhaps this could also be centralized - e.g. whenever you create an ExprRef you also pass the type for it, and if the type matches that for the current class you create it and add to the list, otherwise you skip it. Yes but see previous comment regarding casting. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875: > >> 873: // Reference to this? >> 874: if (tree.name == names._this || tree.name == names._super) { >> 875: if (this.refs.contains(ThisRef.direct())) > > This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere). The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method. When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set. In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question). Regarding the optimization you mention, in light of the above I'm not sure it would still work. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 17:53:25 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 17:53:25 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 12:15:17 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the more appropriate Type comparison method Types.isSameType(). >> - Add some more comments to clarify how the analysis works. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 175: > >> 173: private DiagnosticPosition[] pendingWarning; >> 174: >> 175: // These fields are scoped to the CONSTRUCTOR OR INVOKED METHOD BEING ANALYZED > > Watch out for "all caps" Will fix. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 900: > >> 898: final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type; >> 899: final Type methodOwnerType = sym.owner.type; >> 900: if (this.isSubtype(currentClassType, methodOwnerType)) { > > I believe what you need here is not subtyping but subclassing - see `Symbol.isSubclass` Hmm, I tried using `Symbol.isSubclass()` but it caused test failures. Obviously I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch? > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909: > >> 907: >> 908: // Check for implicit outer 'this' reference >> 909: if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { > > Similarly here - look for `Symbol.isEnclosedBy` Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 18:00:36 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 18:00:36 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 12:17:32 GMT, Maurizio Cimadamore wrote: > There is a concept of push/popScope and then there's a separate concept of call stack (which is just a list of diagnostic position up to the point). I wonder if this could be better modeled by using a single class e.g. Scope/Frame which has a diagnostic position, plus other useful things. I think that would be more confusing, because they're really two different animals. Scopes only have meaning within a single method. They simply serve to bracket the lifetimes of `VarRef` references, following Java curly brace scope. When you "invoke" a method, you put aside the current stack of scopes and start over with an empty scope stack. They don't bridge between methods. Call stacks are just a list of method+code position therein, and they exist outside of any single method. They have nothing to do with Java scopes defined by curly braces. > Perhaps it might even be helpful to have a ref set on each scope, so that you don't have to attach a "depth" to each ref - the depth of the ref would be determined by the "scope" in which it appears. That's another way to skin the same cat... in fact I had a design like that before but then realized it was a lot simpler to just carry around one `RefSet`. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 18:09:27 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 18:09:27 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 12:26:27 GMT, Maurizio Cimadamore wrote: > Do we really need a set for this? There are surely other ways to model things. But I got myself really confused trying to build more complicated models. What I ended up with is this simple model that works: * There is a set of `Ref` subclasses that model the various types of 'this' references possible: `OuterRef`, `ExprRef`, etc. * There is a singleton `this.refs`, which just is a `Set`, containing the 'this' references that are alive at the current moment * As we "execute" code, all we need to do is update the `this.refs` based on what the current bit of code does E.g.... When a variable is assigned a value that has a reference, we add a `VarRef` for that variable. When we leave a scope, we remove any `Ref`'s that are no longer in scope. Before executing a method, we add `Ref`'s for the method receiver and parameter. When we return from a non-void method, we convert any `ReturnRef` into a `ExprRef`. Etc. THAT I can understand. I don't see converting the above into a bitmap or whatever as worth the additional complexity. We're not programming in perl here. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 18:16:25 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 18:16:25 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: Message-ID: <1r69eKftXv6ZlGQP76mNrfgbldbDcMxhnyVOQ8oUV7U=.8facaf51-1f7e-486a-912e-a9a5912b7d88@github.com> On Thu, 12 Jan 2023 17:39:05 GMT, Vicente Romero wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use the more appropriate Type comparison method Types.isSameType(). >> - Add some more comments to clarify how the analysis works. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 200: > >> 198: // >> 199: >> 200: public void analyzeTree(Env env) { > > nit: this method could be removed in favor of the overloaded version below Thanks - will fix. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 204: > >> 202: } >> 203: >> 204: public void analyzeTree(Env env, JCTree tree) { > > nit: `env` parameter doesn't seem to be used could be dropped I think Thanks - will fix. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 18:16:27 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 18:16:27 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 17:48:37 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 909: >> >>> 907: >>> 908: // Check for implicit outer 'this' reference >>> 909: if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { >> >> Similarly here - look for `Symbol.isEnclosedBy` > > Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch? I can't seem to be able to run tests - I get failures in the build: * For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch: ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 18:16:31 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 18:16:31 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 12:28:12 GMT, Maurizio Cimadamore wrote: > This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth). Yes, a method return value that represents a reference is an `ExprRef` just before the `return` is actually executed, but then it turns into a `ReturnRef`. A `ReturnRef` is really just a yellow sticky note that reminds us "Hey whenever you finish 'executing' this method, remember that there is a reference in its return value". > This might also be related with the fact that we deal with return values in different ways than with e.g. values returned from a nested scope (where we just pop, and then copy all pending expression to the outer depth). Exactly. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 18:21:22 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 18:21:22 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com> On Thu, 12 Jan 2023 18:11:01 GMT, Maurizio Cimadamore wrote: >> Same comment as previous: I don't quite know what I'm doing and I'm loathe to break what is already working. Do you have a suggested patch? > > I can't seem to be able to run tests - I get failures in the build: > > > * For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch: This patch: diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk index 1c89328a388..7c3f0293edc 100644 --- a/make/test/BuildMicrobenchmark.gmk +++ b/make/test/BuildMicrobenchmark.gmk @@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \ TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \ SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \ INCLUDE_FILES := indify/Indify.java, \ - DISABLED_WARNINGS := rawtypes serial options, \ + DISABLED_WARNINGS := this-escape rawtypes serial options, \ BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \ JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \ )) @@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \ TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \ SMALL_JAVA := false, \ CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \ - DISABLED_WARNINGS := processing rawtypes cast serial preview, \ + DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \ SRC := $(MICROBENCHMARK_SRC), \ BIN := $(MICROBENCHMARK_CLASSES), \ JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \ diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java index 9d35c2fbc0a..4e2b1e558e7 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java @@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner { // Check for implicit 'this' reference final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type; final Type methodOwnerType = sym.owner.type; + //if (currentClassType.tsym.isSubClass(sym.owner, types)) { if (this.isSubtype(currentClassType, methodOwnerType)) { if (this.refs.contains(ThisRef.direct())) this.refs.add(ExprRef.direct(this.depth)); @@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner { } // Check for implicit outer 'this' reference + // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) { if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { if (this.refs.contains(OuterRef.direct())) this.refs.add(ExprRef.direct(this.depth)); Fixes the build failure. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 18:40:28 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 18:40:28 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Thu, 12 Jan 2023 16:40:33 GMT, Maurizio Cimadamore wrote: > I guess what I'm thinking about: No leak is possible in that example. * `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden * Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 18:43:21 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 18:43:21 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com> References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com> Message-ID: On Thu, 12 Jan 2023 18:18:38 GMT, Maurizio Cimadamore wrote: >> I can't seem to be able to run tests - I get failures in the build: >> >> >> * For target support_test_micro_tools-classes__the.BUILD_INDIFY_batch: > > This patch: > > > diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk > index 1c89328a388..7c3f0293edc 100644 > --- a/make/test/BuildMicrobenchmark.gmk > +++ b/make/test/BuildMicrobenchmark.gmk > @@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \ > TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \ > SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \ > INCLUDE_FILES := indify/Indify.java, \ > - DISABLED_WARNINGS := rawtypes serial options, \ > + DISABLED_WARNINGS := this-escape rawtypes serial options, \ > BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \ > JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \ > )) > @@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \ > TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \ > SMALL_JAVA := false, \ > CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \ > - DISABLED_WARNINGS := processing rawtypes cast serial preview, \ > + DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \ > SRC := $(MICROBENCHMARK_SRC), \ > BIN := $(MICROBENCHMARK_CLASSES), \ > JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \ > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java > index 9d35c2fbc0a..4e2b1e558e7 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java > @@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner { > // Check for implicit 'this' reference > final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type; > final Type methodOwnerType = sym.owner.type; > + //if (currentClassType.tsym.isSubClass(sym.owner, types)) { > if (this.isSubtype(currentClassType, methodOwnerType)) { > if (this.refs.contains(ThisRef.direct())) > this.refs.add(ExprRef.direct(this.depth)); > @@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner { > } > > // Check for implicit outer 'this' reference > + // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) { > if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { > if (this.refs.contains(OuterRef.direct())) > this.refs.add(ExprRef.direct(this.depth)); > > > Fixes the build failure. This patch passes all tests: diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java index 9d35c2fbc0a..e755c54d0c8 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java @@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner { } // If the expression type is incompatible with 'this', discard it - if (type != null && !this.isSubtype(this.targetClass.sym.type, type)) + if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types)) this.refs.remove(ExprRef.direct(this.depth)); } } @@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner { if (explicitOuterThis != null) { this.scan(explicitOuterThis); this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct))); - } else if (this.types.hasOuterClass(type, this.methodClass.type)) { + } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) { if (this.refs.contains(ThisRef.direct())) outerRefs.add(OuterRef.direct()); if (this.refs.contains(ThisRef.indirect())) @@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner { // Explicit outer 'this' reference? final Type selectedType = this.types.erasure(tree.selected.type); if (selectedType.hasTag(CLASS)) { - final Type.ClassType selectedClassType = (Type.ClassType)selectedType; if (tree.name == this.names._this && - this.types.hasOuterClass(currentClassType, selectedClassType)) { + currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) { if (this.refs.contains(OuterRef.direct())) this.refs.add(ExprRef.direct(this.depth)); if (this.refs.contains(OuterRef.indirect())) @@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner { final MethodSymbol sym = (MethodSymbol)tree.sym; // Check for implicit 'this' reference - final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type; - final Type methodOwnerType = sym.owner.type; - if (this.isSubtype(currentClassType, methodOwnerType)) { + if (methodClass.sym.isSubClass(sym.owner, types)) { if (this.refs.contains(ThisRef.direct())) this.refs.add(ExprRef.direct(this.depth)); if (this.refs.contains(ThisRef.indirect())) @@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner { } // Check for implicit outer 'this' reference - if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { + if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) { if (this.refs.contains(OuterRef.direct())) this.refs.add(ExprRef.direct(this.depth)); Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 18:51:33 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 18:51:33 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Thu, 12 Jan 2023 18:37:06 GMT, Archie L. Cobbs wrote: >> I guess what I'm thinking about: >> >> class Foo { >> private Foo() { >> m(this); >> } >> >> public void m() { ... } // overridable >> >> static Foo makeFoo() { return new Foo(); } >> } > >> I guess what I'm thinking about: > > No leak is possible in that example. > * `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden > * Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 19:04:22 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 19:04:22 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 17:29:22 GMT, Maurizio Cimadamore wrote: >> I put it there because of switch expressions and `yeild`... ? > > Well, yield can... yield a value - `case` doesn't. So I'm confused. Also because the variable is called `referenceExpressionNode` and `CASE` is not an expression. Can `CASE` leave anything on the stack? YIELD does, but CASE? It's just an artifact of the way switch expressions are handled: @Override public void visitSwitchExpression(JCSwitchExpression tree) { visitScoped(tree, true, t -> { scan(t.selector); refs.discardExprs(depth); RefSet combinedRefs = new RefSet<>(); for (List cases = t.cases; cases.nonEmpty(); cases = cases.tail) { scan(cases.head); combinedRefs.addAll(refs.removeExprs(depth)); } refs.addAll(combinedRefs); }); } @Override public void visitCase(JCCase tree) { scan(tree.stats); // no need to scan labels } After scanning a switch expression case, the `yield`'ed value will be on the top of the stack. Then `visitCase` does NOT remove it, so that it can be picked up and removed by `visitSwitchExpression()`. But this can be cleaned up a little bit, by having `visitSwitchExpression()` not delegate to `visitCase()` but rather iterate through the case statements itself directly. Then we can remove the `CASE` as you suggest. Also I realized we need to handle `yield`'ed values like `return` values, i.e., collect and remember them until the entire case is complete. I'll fix. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 19:04:25 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 19:04:25 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 17:33:48 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 875: >> >>> 873: // Reference to this? >>> 874: if (tree.name == names._this || tree.name == names._super) { >>> 875: if (this.refs.contains(ThisRef.direct())) >> >> This idiom occurs quite a lot. If I'm correct, this basically amounts at asking as to whether the receiver of the method we're currently evaluating is direct or not (which is an invariant, given a method body - e.g. for a given method this "fact" should stay the same). If that's the case, perhaps capturing this in a flag could be better - then you could have just have a single method e.g. `XYZRef.create(boolean direct)`, and remove the branching (here and elsewhere). > > The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method. > > When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set. > > In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question). > > Regarding the optimization you mention, in light of the above I'm not sure it would still work. My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). There is also this bit in `visitReference`: case SUPER: if (this.refs.contains(ThisRef.direct())) receiverRefs.add(ThisRef.direct()); if (this.refs.contains(ThisRef.indirect())) receiverRefs.add(ThisRef.indirect()); break; But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation. The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects: * the set of variables that can point to this, whether directly or indirectly (this is truly a set) * whether the current context has a direct or indirect this (this seems more a flag to me) * whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set) When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 19:15:20 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 19:15:20 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 17:40:36 GMT, Maurizio Cimadamore wrote: > But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated). Ah, I see what you mean. Here's a more complete example: public class CastLeak { public CastLeak() { ((CastLeak)(Runnable)this).mightLeak(); } public void mightLeak() { } } That would be a leak for any subclass that implements `Runnable`. Yet no warning is generated. So the filtering by expression type is going to potentially create false negatives. But it also eliminates a bunch of false positives. And the false negatives are probably all somewhat pathological like the example above. So I still think it's worth doing. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 19:27:24 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 19:27:24 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com> Message-ID: On Thu, 12 Jan 2023 18:40:38 GMT, Maurizio Cimadamore wrote: >> This patch: >> >> >> diff --git a/make/test/BuildMicrobenchmark.gmk b/make/test/BuildMicrobenchmark.gmk >> index 1c89328a388..7c3f0293edc 100644 >> --- a/make/test/BuildMicrobenchmark.gmk >> +++ b/make/test/BuildMicrobenchmark.gmk >> @@ -76,7 +76,7 @@ $(eval $(call SetupJavaCompilation, BUILD_INDIFY, \ >> TARGET_RELEASE := $(TARGET_RELEASE_BOOTJDK), \ >> SRC := $(TOPDIR)/test/jdk/java/lang/invoke, \ >> INCLUDE_FILES := indify/Indify.java, \ >> - DISABLED_WARNINGS := rawtypes serial options, \ >> + DISABLED_WARNINGS := this-escape rawtypes serial options, \ >> BIN := $(MICROBENCHMARK_TOOLS_CLASSES), \ >> JAVAC_FLAGS := -XDstringConcat=inline -Xprefer:newer, \ >> )) >> @@ -91,7 +91,7 @@ $(eval $(call SetupJavaCompilation, BUILD_JDK_MICROBENCHMARK, \ >> TARGET_RELEASE := $(TARGET_RELEASE_NEWJDK_UPGRADED), \ >> SMALL_JAVA := false, \ >> CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \ >> - DISABLED_WARNINGS := processing rawtypes cast serial preview, \ >> + DISABLED_WARNINGS := this-escape processing rawtypes cast serial preview, \ >> SRC := $(MICROBENCHMARK_SRC), \ >> BIN := $(MICROBENCHMARK_CLASSES), \ >> JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \ >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java >> index 9d35c2fbc0a..4e2b1e558e7 100644 >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java >> @@ -897,6 +897,7 @@ class ThisEscapeAnalyzer extends TreeScanner { >> // Check for implicit 'this' reference >> final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type; >> final Type methodOwnerType = sym.owner.type; >> + //if (currentClassType.tsym.isSubClass(sym.owner, types)) { >> if (this.isSubtype(currentClassType, methodOwnerType)) { >> if (this.refs.contains(ThisRef.direct())) >> this.refs.add(ExprRef.direct(this.depth)); >> @@ -906,6 +907,7 @@ class ThisEscapeAnalyzer extends TreeScanner { >> } >> >> // Check for implicit outer 'this' reference >> + // if (currentClassType.tsym.isEnclosedBy((ClassSymbol)sym.owner)) { >> if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { >> if (this.refs.contains(OuterRef.direct())) >> this.refs.add(ExprRef.direct(this.depth)); >> >> >> Fixes the build failure. > > This patch passes all tests: > > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java > index 9d35c2fbc0a..e755c54d0c8 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java > @@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner { > } > > // If the expression type is incompatible with 'this', discard it > - if (type != null && !this.isSubtype(this.targetClass.sym.type, type)) > + if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types)) > this.refs.remove(ExprRef.direct(this.depth)); > } > } > @@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner { > if (explicitOuterThis != null) { > this.scan(explicitOuterThis); > this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct))); > - } else if (this.types.hasOuterClass(type, this.methodClass.type)) { > + } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) { > if (this.refs.contains(ThisRef.direct())) > outerRefs.add(OuterRef.direct()); > if (this.refs.contains(ThisRef.indirect())) > @@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner { > // Explicit outer 'this' reference? > final Type selectedType = this.types.erasure(tree.selected.type); > if (selectedType.hasTag(CLASS)) { > - final Type.ClassType selectedClassType = (Type.ClassType)selectedType; > if (tree.name == this.names._this && > - this.types.hasOuterClass(currentClassType, selectedClassType)) { > + currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) { > if (this.refs.contains(OuterRef.direct())) > this.refs.add(ExprRef.direct(this.depth)); > if (this.refs.contains(OuterRef.indirect())) > @@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner { > final MethodSymbol sym = (MethodSymbol)tree.sym; > > // Check for implicit 'this' reference > - final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type; > - final Type methodOwnerType = sym.owner.type; > - if (this.isSubtype(currentClassType, methodOwnerType)) { > + if (methodClass.sym.isSubClass(sym.owner, types)) { > if (this.refs.contains(ThisRef.direct())) > this.refs.add(ExprRef.direct(this.depth)); > if (this.refs.contains(ThisRef.indirect())) > @@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner { > } > > // Check for implicit outer 'this' reference > - if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { > + if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) { > if (this.refs.contains(OuterRef.direct())) > this.refs.add(ExprRef.direct(this.depth)); > > > Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. > > Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client. Weird. I don't get that build failure. Neither does github... I have been relying on the github build "Actions" succeeding to determine if "the build works" and according to that it is building. I will add the `DISABLED_WARNINGS` in any case. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From amenkov at openjdk.org Thu Jan 12 19:43:15 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 12 Jan 2023 19:43:15 GMT Subject: RFR: 8300024: Replace use of JNI_COMMIT mode with mode 0 In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 09:23:49 GMT, Daniel Jeli?ski wrote: > Please review this patch that fixes a few memory leaks in JNI code. > > [The latest documentation](https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#releaseprimitivetypearrayelements-routines) of JNI functions makes an explicit note about the use of JNI_COMMIT: > >> If `JNI_COMMIT` is passed as the `mode` argument when `elems` is a copy of the elements in `array`, then a final call to *ReleaseArrayElements* passing a `mode` argument of "0" or `JNI_ABORT`, should be made to free the `elems` buffer > > No new regression test. I manually verified the Linux fix using ClhdsbPstack test in root mode. Also, tier1-2 tests on mach5 continue to pass. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11963 From cjplummer at openjdk.org Thu Jan 12 21:05:18 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 12 Jan 2023 21:05:18 GMT Subject: RFR: 8300024: Replace use of JNI_COMMIT mode with mode 0 In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 09:23:49 GMT, Daniel Jeli?ski wrote: > Please review this patch that fixes a few memory leaks in JNI code. > > [The latest documentation](https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#releaseprimitivetypearrayelements-routines) of JNI functions makes an explicit note about the use of JNI_COMMIT: > >> If `JNI_COMMIT` is passed as the `mode` argument when `elems` is a copy of the elements in `array`, then a final call to *ReleaseArrayElements* passing a `mode` argument of "0" or `JNI_ABORT`, should be made to free the `elems` buffer > > No new regression test. I manually verified the Linux fix using ClhdsbPstack test in root mode. Also, tier1-2 tests on mach5 continue to pass. There are occurrences of JNI_COMMIT on macos in libawt and libsaproc. Is there a reason you did not fix these also? ------------- PR: https://git.openjdk.org/jdk/pull/11963 From duke at openjdk.org Thu Jan 12 21:07:28 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 21:07:28 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Thu, 12 Jan 2023 18:48:25 GMT, Maurizio Cimadamore wrote: >>> I guess what I'm thinking about: >> >> No leak is possible in that example. >> * `new Foo()` creates an instance of `Foo` (not a subclass of `Foo`) therefore `m()` is not overridden >> * Any subclass of `Foo` that may exist in the outside world cannot use the `Foo()` constructor that leaks because it's private > > but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo? Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal. We only care about bugs where a superclass and subclass are in separate compilation units. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Thu Jan 12 21:07:30 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 21:07:30 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <1vfnyE9dnZELUp1To60nQYEUIre7g5pcfXHKKHOug0I=.9af24b57-2627-45d8-a7cc-1b4235e99237@github.com> Message-ID: On Thu, 12 Jan 2023 19:24:50 GMT, Archie L. Cobbs wrote: >> This patch passes all tests: >> >> >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java >> index 9d35c2fbc0a..e755c54d0c8 100644 >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java >> @@ -451,7 +451,7 @@ class ThisEscapeAnalyzer extends TreeScanner { >> } >> >> // If the expression type is incompatible with 'this', discard it >> - if (type != null && !this.isSubtype(this.targetClass.sym.type, type)) >> + if (type != null && !this.targetClass.sym.isSubClass(type.tsym, types)) >> this.refs.remove(ExprRef.direct(this.depth)); >> } >> } >> @@ -672,7 +672,7 @@ class ThisEscapeAnalyzer extends TreeScanner { >> if (explicitOuterThis != null) { >> this.scan(explicitOuterThis); >> this.refs.removeExprs(this.depth, direct -> outerRefs.add(new OuterRef(direct))); >> - } else if (this.types.hasOuterClass(type, this.methodClass.type)) { >> + } else if (type.tsym.isEnclosedBy(this.methodClass.sym)) { >> if (this.refs.contains(ThisRef.direct())) >> outerRefs.add(OuterRef.direct()); >> if (this.refs.contains(ThisRef.indirect())) >> @@ -801,9 +801,8 @@ class ThisEscapeAnalyzer extends TreeScanner { >> // Explicit outer 'this' reference? >> final Type selectedType = this.types.erasure(tree.selected.type); >> if (selectedType.hasTag(CLASS)) { >> - final Type.ClassType selectedClassType = (Type.ClassType)selectedType; >> if (tree.name == this.names._this && >> - this.types.hasOuterClass(currentClassType, selectedClassType)) { >> + currentClassType.tsym.isEnclosedBy((ClassSymbol)selectedType.tsym)) { >> if (this.refs.contains(OuterRef.direct())) >> this.refs.add(ExprRef.direct(this.depth)); >> if (this.refs.contains(OuterRef.indirect())) >> @@ -895,9 +894,7 @@ class ThisEscapeAnalyzer extends TreeScanner { >> final MethodSymbol sym = (MethodSymbol)tree.sym; >> >> // Check for implicit 'this' reference >> - final Type.ClassType currentClassType = (Type.ClassType)this.methodClass.sym.type; >> - final Type methodOwnerType = sym.owner.type; >> - if (this.isSubtype(currentClassType, methodOwnerType)) { >> + if (methodClass.sym.isSubClass(sym.owner, types)) { >> if (this.refs.contains(ThisRef.direct())) >> this.refs.add(ExprRef.direct(this.depth)); >> if (this.refs.contains(ThisRef.indirect())) >> @@ -906,7 +903,7 @@ class ThisEscapeAnalyzer extends TreeScanner { >> } >> >> // Check for implicit outer 'this' reference >> - if (this.types.hasOuterClass(currentClassType, methodOwnerType)) { >> + if (methodClass.sym.isEnclosedBy((ClassSymbol)sym.owner)) { >> if (this.refs.contains(OuterRef.direct())) >> this.refs.add(ExprRef.direct(this.depth)); >> >> >> Btw, I believe a similar trick can be used in TreeInfo.isExplicitThisReference. If I'm correct, `hasOuterClass` should probably be removed as it duplicates already existing functionality. >> >> Since I'm bringing this up, as TreeInfo.isExplicitThisReference is only used by the new analyzer, it would be cleaner if it was defined there, at least until it's clear it might be needed by some other client. > > Weird. I don't get that build failure. > > Neither does github... I have been relying on the github build "Actions" succeeding to determine if "the build works" and according to that it is building. > > I will add the `DISABLED_WARNINGS` in any case. Thanks for the patch! The semantics of `hasOuterClass()` returns false if A and B are the same class, while `isEnclosedBy()` returns true if A and B are the same class. However, I don't think it would actually matter in practice... Regardless, I'll add the extra equality comparison and apply your patch and also the suggestions to integrate `isExplicitThisReference()` and eliminate `hasOuterClass()`. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From cjplummer at openjdk.org Thu Jan 12 21:29:15 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 12 Jan 2023 21:29:15 GMT Subject: RFR: 8300032: DwarfParser resource leak In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 12:08:51 GMT, Daniel Jeli?ski wrote: > Please review this fix for DwarfParser cleaner. > > The original code registered the cleaner using a lambda that captured a reference to the parser object; as a result, the object was never GCed, and the cleaner never ran. > > In this version I moved the lambda creation to a static method, so that it can't capture a reference to the parser. > > Additionally, the new code uses a static cleaner; the cleaner object creation and cleanup are heavy operations (every cleaner comes with its own thread), and it's preferable to use a single shared cleaner where possible. > > I verified manually that the native `destroyDwarfContext` method is called after this fix. No new automated test. Existing tier1-2 tests continue to pass. This seems like a pretty serious flaw with using Lambdas and Cleaners that probably should be brought up with the libs and language teams. I see other occurrences of this issue in these files (I may have missed some): src/java.base/share/classes/com/sun/crypto/provider/*Key.java (4 files) src/java.base/windows/classes/java/lang/ProcessImpl.java src/java.desktop/share/classes/javax/swing/border/TitledBorder.java src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ------------- PR: https://git.openjdk.org/jdk/pull/11965 From duke at openjdk.org Thu Jan 12 21:31:25 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Thu, 12 Jan 2023 21:31:25 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 19:01:10 GMT, Maurizio Cimadamore wrote: >> The code you quoted has nothing specifically to do with method invocations. This code is simply handing the evaluation of the expressions `this` and `super`. For example, `this` could just be a parameter we're passing to another method. >> >> When `this` or `super` expressions are evaluated, the thing left on top of the stack is a direct/indirect reference (i.e., an `ExprRef`) exactly when the there is a direct/indirect reference of type `ThisRef` in the current reference set. >> >> In cases where `this` is then "invoked", e.g., `this()`, the `ExprRef` (top of Java stack) becomes the method receiver, and when the method is "invoked" it turns back into a `ThisRef` (see earlier question). >> >> Regarding the optimization you mention, in light of the above I'm not sure it would still work. > > My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). > > There is also this bit in `visitReference`: > > > case SUPER: > if (this.refs.contains(ThisRef.direct())) > receiverRefs.add(ThisRef.direct()); > if (this.refs.contains(ThisRef.indirect())) > receiverRefs.add(ThisRef.indirect()); > break; > > > But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation. > > The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects: > > * the set of variables that can point to this, whether directly or indirectly (this is truly a set) > * whether the current context has a direct or indirect this (this seems more a flag to me) > * whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set) > > When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me. I get what you're saying - it seems silly to model what is essentially a fixed, boolean property with the membership of a singleton in a set field, rather than with a simple boolean field. There is a conceptual trade-off though... a lot of the code relates to converting `Ref`'s from one type to another. For example, as pointed out above, a method invocation might convert a `ExprRef` to a `ThisRef`, then to a `ReturnRef`'s, etc. Having these things all be considered part of the same family helps conceptually. The fact that a direct `ThisRef` is a singleton is just a coincidence in this way of looking at things. The benefit is the simplicity of being able to think of the data model as "just a set of references". For example, methods like `RefSet.replaceExprs()` become less elegant (or basically impossible) if there have to be special cases for each type of reference, whereas currently we can do clean stuff like this: @Override public void visitReturn(JCReturn tree) { scan(tree.expr); refs.replaceExprs(depth, ReturnRef::new); } But I'm also realizing now that several places can be cleaned up by taking this event further. E.g., we should replace this code: if (refs.contains(ThisRef.direct())) outerRefs.add(OuterRef.direct()); if (refs.contains(ThisRef.indirect())) outerRefs.add(OuterRef.indirect()); with something like this: refs.mapInto(outerRefs, ThisRef.class, OuterRef::new); I will go through and refactor to do that and clean things up a little more. > When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me. Probably my fault for not providing better documentation of the overall "set of references" conceptual approach. FWIW I added a little bit more in f83a9cf0. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Thu Jan 12 21:47:24 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 12 Jan 2023 21:47:24 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 21:28:12 GMT, Archie L. Cobbs wrote: >> My point is about who puts ThisRef in the set to begin with. It seems to me that ThisRef is put there at the start of a method analysis. After which, there's several code points where we say "if there's a direct ThisRef in the set, do this, otherwise, if there's an indirect ThisRef in the set, do that". But the ThisRef (whether indirect or direct) seems set once and for all (when we start the analysis, and then inside visitApply). >> >> There is also this bit in `visitReference`: >> >> >> case SUPER: >> if (this.refs.contains(ThisRef.direct())) >> receiverRefs.add(ThisRef.direct()); >> if (this.refs.contains(ThisRef.indirect())) >> receiverRefs.add(ThisRef.indirect()); >> break; >> >> >> But this doesn't change what I'm saying - there seems to be a general property when we execute this analysis which says whether the current execution context has a direct `this` or not. This seems to me better captured with a boolean, which is then fed back to all the other various downstream ref creation. >> >> The main observation, at least for me, is that the code unifies everything under refs, when in reality there are different aspects: >> >> * the set of variables that can point to this, whether directly or indirectly (this is truly a set) >> * whether the current context has a direct or indirect this (this seems more a flag to me) >> * whether the expression on top of stack is direct/indirect this reference or not (again, 3 possible values here) - but granted, there `depth` here to take into account, so you probably end up with a set (given that we don't want to model a scope with its own set) >> >> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me. > > I get what you're saying - it seems silly to model what is essentially a fixed, boolean property with the membership of a singleton in a set field, rather than with a simple boolean field. > > There is a conceptual trade-off though... a lot of the code relates to converting `Ref`'s from one type to another. For example, as pointed out above, a method invocation might convert a `ExprRef` to a `ThisRef`, then to a `ReturnRef`'s, etc. Having these things all be considered part of the same family helps conceptually. The fact that a direct `ThisRef` is a singleton is just a coincidence in this way of looking at things. > > The benefit is the simplicity of being able to think of the data model as "just a set of references". > > For example, methods like `RefSet.replaceExprs()` become less elegant (or basically impossible) if there have to be special cases for each type of reference, whereas currently we can do clean stuff like this: > > > @Override > public void visitReturn(JCReturn tree) { > scan(tree.expr); > refs.replaceExprs(depth, ReturnRef::new); > } > > > But I'm also realizing now that several places can be cleaned up by taking this event further. E.g., we should replace this code: > > if (refs.contains(ThisRef.direct())) > outerRefs.add(OuterRef.direct()); > if (refs.contains(ThisRef.indirect())) > outerRefs.add(OuterRef.indirect()); > > with something like this: > > refs.mapInto(outerRefs, ThisRef.class, OuterRef::new); > > > I will go through and refactor to do that and clean things up a little more. > >> When reading the code, seeing set expression like containment checks or removals for things that doesn't seem to be truly sets (unless I'm missing something) was genuinely confusing me. > > Probably my fault for not providing better documentation of the overall "set of references" conceptual approach. FWIW I added a little bit more in f83a9cf0. > ```java > ```java > if (refs.contains(ThisRef.direct())) > outerRefs.add(OuterRef.direct()); > if (refs.contains(ThisRef.indirect())) > outerRefs.add(OuterRef.indirect()); > ``` > > > > > > > > > > > > with something like this: > ```java > refs.mapInto(outerRefs, ThisRef.class, OuterRef::new); > ``` > ``` This sounds like a good idea, that idiom is quite widespread, so it should help avoiding repetition. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From sspitsyn at openjdk.org Fri Jan 13 04:02:54 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 04:02:54 GMT Subject: RFR: JDK-8299957: Enhance error logging in instrument coding with additional jplis_assert_msg In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 08:10:29 GMT, Matthias Baesken wrote: > There are a few places in the instrument coding where errors occur in our jtreg test, but the already existing error logging method jplis_assert_msg / jplis_assert is unfortunately missing so not much details are shown. This could be enhanced. Looks good. Thank you for fixing it. Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11960 From sspitsyn at openjdk.org Fri Jan 13 04:02:55 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 04:02:55 GMT Subject: RFR: 8300032: DwarfParser resource leak In-Reply-To: References: Message-ID: <04laDdwlDix8VuPvzIJngDfhJ0rhsfEtfvYct-lT0_Y=.1ee27ac4-bfe1-4ab0-a4a3-db9c0feda699@github.com> On Thu, 12 Jan 2023 12:08:51 GMT, Daniel Jeli?ski wrote: > Please review this fix for DwarfParser cleaner. > > The original code registered the cleaner using a lambda that captured a reference to the parser object; as a result, the object was never GCed, and the cleaner never ran. > > In this version I moved the lambda creation to a static method, so that it can't capture a reference to the parser. > > Additionally, the new code uses a static cleaner; the cleaner object creation and cleanup are heavy operations (every cleaner comes with its own thread), and it's preferable to use a single shared cleaner where possible. > > I verified manually that the native `destroyDwarfContext` method is called after this fix. No new automated test. Existing tier1-2 tests continue to pass. This looks good modulo there can be more issues like that as Chris mentioned. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11965 From sspitsyn at openjdk.org Fri Jan 13 04:02:58 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 04:02:58 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. This looks good. Thank you for fixing it. Serguei There are more uses of sprintf in some serviceability folders: src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c: sprintf(fname, "/proc/%d/status", pid); src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c: sprintf(fname, "/proc/%d/maps", ph->pid); src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c: s = filename + sprintf (filename, "%s/.build-id/", debug_file_directory); src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c: s += sprintf (s, "%02x", *data++); src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c: s += sprintf (s, "%02x", *data++); src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp: sprintf(errmsg, "%s (hr: 0x%08X)", str, hr); \ src/jdk.management/share/native/libmanagement_ext/management_ext.c: sprintf(errmsg, "errno: %d error: %s\n", errno, msg); src/java.management/share/native/libmanagement/VMManagementImpl.c: sprintf(buf, "%d.%d", major, minor); src/java.management/share/native/libmanagement/management.c: sprintf(errmsg, "errno: %d error: %s\n", errno, msg); src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: sprintf(msg, "handshake failed - received >%s< - expected >%s<", b, hello); src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: sprintf(buf, "%d", portNum); src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: sprintf(ebuf, "ERROR: Peer not allowed to connect: %s\n", src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c: sprintf(buf, "winsock error %d", error); src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c: sprintf(holder, "%s.dll", fname); ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11935 From sspitsyn at openjdk.org Fri Jan 13 04:02:58 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 04:02:58 GMT Subject: RFR: 8300024: Replace use of JNI_COMMIT mode with mode 0 In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 09:23:49 GMT, Daniel Jeli?ski wrote: > Please review this patch that fixes a few memory leaks in JNI code. > > [The latest documentation](https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#releaseprimitivetypearrayelements-routines) of JNI functions makes an explicit note about the use of JNI_COMMIT: > >> If `JNI_COMMIT` is passed as the `mode` argument when `elems` is a copy of the elements in `array`, then a final call to *ReleaseArrayElements* passing a `mode` argument of "0" or `JNI_ABORT`, should be made to free the `elems` buffer > > No new regression test. I manually verified the Linux fix using ClhdsbPstack test in root mode. Also, tier1-2 tests on mach5 continue to pass. Marked as reviewed by sspitsyn (Reviewer). Looks good. Thank you for taking care about it. Serguei ------------- PR: https://git.openjdk.org/jdk/pull/11963 From sspitsyn at openjdk.org Fri Jan 13 04:03:04 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 04:03:04 GMT Subject: RFR: 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method [v2] In-Reply-To: References: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> Message-ID: On Thu, 12 Jan 2023 16:44:44 GMT, Chris Plummer wrote: >> `VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object)` is not used. Furthermore it confuses the reader that runs across `removeObjectMirror()` calls, because what is actually being called is `removeObjectMirror(SoftObjectReference ref)`. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Make removeObjectMirror() private. Looks good and simple. :) Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11957 From duke at openjdk.org Fri Jan 13 04:04:36 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 04:04:36 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision: - Fix bug where all but the last yeild statement were being ignored. - Add method RefSet.mapInto() and use to refactor/clean up. - Fix possible assertion failure when handling if statements. - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff. Suggested-by: mcimadamore - Add comment regarding limitations of expresison type filtering. - Add a few more DISABLED_WARNINGS to unbreak build. - Clean up handling of switch expressions a bit. - Remove unused method variant of analyzeTree(). - Avoid all caps in comments. - Clarify confusing comment. - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/6e96a7d7..edf3c3f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=06-07 Stats: 540 lines in 8 files changed: 120 ins; 92 del; 328 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Fri Jan 13 04:04:37 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 13 Jan 2023 04:04:37 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 19:12:27 GMT, Archie L. Cobbs wrote: >> Uhm. Turns out I probably did not understand the filter correctly, and now I'm more dubious about what it actually does. Say you have this hierarchy: >> >> >> interface A { } >> class B { >> B() { >> A a = (A)this; >> ... >> } >> } >> class C extends B implements A { } >> ``` >> >> Pathological case, I know. But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated). > >> But the filtering will end up dropping the expression Ref on the floor, right? (because B and A are unrelated). > > Ah, I see what you mean. > > Here's a more complete example: > > public class CastLeak { > > public CastLeak() { > ((CastLeak)(Runnable)this).mightLeak(); > } > > public void mightLeak() { > } > } > > That would be a leak for any subclass that implements `Runnable`. Yet no warning is generated. > > So the filtering by expression type is going to potentially create false negatives. But it also eliminates a bunch of false positives. And the false negatives are probably all somewhat pathological like the example above. > > So I still think it's worth doing. Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern. I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 04:04:37 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 04:04:37 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Thu, 12 Jan 2023 21:47:28 GMT, Maurizio Cimadamore wrote: > Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern. You're right. I think at the time I reasoned that it would be unusual enough for the type of an expression to start as an instanceof X, then change to not being an instanceof X, and then change back, that it was worth it to go ahead and filter these out. But admittedly that was based on intuition, not science. > I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it. That's a nice idea... thanks. I'll play around with it some. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From djelinski at openjdk.org Fri Jan 13 07:16:35 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 13 Jan 2023 07:16:35 GMT Subject: RFR: 8300024: Replace use of JNI_COMMIT mode with mode 0 [v2] In-Reply-To: References: Message-ID: > Please review this patch that fixes a few memory leaks in JNI code. > > [The latest documentation](https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#releaseprimitivetypearrayelements-routines) of JNI functions makes an explicit note about the use of JNI_COMMIT: > >> If `JNI_COMMIT` is passed as the `mode` argument when `elems` is a copy of the elements in `array`, then a final call to *ReleaseArrayElements* passing a `mode` argument of "0" or `JNI_ABORT`, should be made to free the `elems` buffer > > No new regression test. I manually verified the Linux fix using ClhdsbPstack test in root mode. Also, tier1-2 tests on mach5 continue to pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: MacOS fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11963/files - new: https://git.openjdk.org/jdk/pull/11963/files/cecacd13..bea9f536 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11963&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11963&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11963.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11963/head:pull/11963 PR: https://git.openjdk.org/jdk/pull/11963 From djelinski at openjdk.org Fri Jan 13 07:33:14 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 13 Jan 2023 07:33:14 GMT Subject: RFR: 8300024: Replace use of JNI_COMMIT mode with mode 0 In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 21:02:23 GMT, Chris Plummer wrote: > There are occurrences of JNI_COMMIT on macos in libawt and libsaproc. Is there a reason you did not fix these also? My search for JNI_COMMIT filtered out all *.m files. Thanks for pointing that out. libsaproc is corrected now. I will fix AWT in a separate PR. ------------- PR: https://git.openjdk.org/jdk/pull/11963 From djelinski at openjdk.org Fri Jan 13 07:49:11 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 13 Jan 2023 07:49:11 GMT Subject: RFR: 8300032: DwarfParser resource leak In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 21:26:09 GMT, Chris Plummer wrote: > This seems like a pretty serious flaw with using Lambdas and Cleaners that probably should be brought up with the libs and language teams. They are aware of this issue; it's even mentioned in [this article](https://inside.java/2022/05/25/clean-cleaner/): > For example, if `chars` is a field, the lambda could refer to `this.chars` inadvertently capturing `this`. [...] One way to ensure that this is not captured is to create the lambda in a static method. Its scope does not have this so it cannot accidentally be captured. As far as I could tell, the cleaners you pointed out use local variables only. As long as the lambda does not reference any object fields or instance methods, `this` is not captured. ------------- PR: https://git.openjdk.org/jdk/pull/11965 From mbaesken at openjdk.org Fri Jan 13 08:01:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 13 Jan 2023 08:01:20 GMT Subject: Integrated: JDK-8299957: Enhance error logging in instrument coding with additional jplis_assert_msg In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 08:10:29 GMT, Matthias Baesken wrote: > There are a few places in the instrument coding where errors occur in our jtreg test, but the already existing error logging method jplis_assert_msg / jplis_assert is unfortunately missing so not much details are shown. This could be enhanced. This pull request has now been integrated. Changeset: be8e6d05 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/be8e6d05db2f623626506e64a2fb7caf755d5d06 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod 8299957: Enhance error logging in instrument coding with additional jplis_assert_msg Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11960 From sspitsyn at openjdk.org Fri Jan 13 08:06:13 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 08:06:13 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> References: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> Message-ID: On Thu, 12 Jan 2023 07:25:07 GMT, Xue-Lei Andrew Fan wrote: >>> This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail: >>> >> >> This is a question to me as well. I noticed there are still some use of sprintf, but the building passed on MacOS and Linux. I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters. >> >> >> FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); >> >> >>> I count ~30 sprintf:s that need updating. >>> >>> I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >> >> I'm new to hotspot. Do you know how could I enable C2? Thanks! > >> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >> >> I'm new to hotspot. Do you know how could I enable C2? Thanks! > > Never mind, I got it from configuration help message (use --with-jvm-features=compiler2). @XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed? ------------- PR: https://git.openjdk.org/jdk/pull/11935 From sspitsyn at openjdk.org Fri Jan 13 08:18:17 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 08:18:17 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. More cases with the same issue were found. ------------- Changes requested by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Fri Jan 13 08:45:16 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 13 Jan 2023 08:45:16 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> References: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> Message-ID: <831CK10pKtyMvjCIInY9jDxfXiLD68orvfLXhm6koRs=.d1b87cbc-0969-4d1a-a3c5-48c00a60a754@github.com> On Thu, 12 Jan 2023 07:25:07 GMT, Xue-Lei Andrew Fan wrote: >>> This PR does not address all the remaining sprintf:s in hotspot, and with it now explicitly forbidden the build will fail: >>> >> >> This is a question to me as well. I noticed there are still some use of sprintf, but the building passed on MacOS and Linux. I was wondering if the following update really work (if the '...' parameter works for the forbidden?), or something else matters. >> >> >> FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); >> >> >>> I count ~30 sprintf:s that need updating. >>> >>> I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >> >> I'm new to hotspot. Do you know how could I enable C2? Thanks! > >> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >> >> I'm new to hotspot. Do you know how could I enable C2? Thanks! > > Never mind, I got it from configuration help message (use --with-jvm-features=compiler2). > @XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed? Sure. That's on my plan. I am trying to figure out how to get these files included in the building. My build passed on MacOS and Linux, even with C2 enabled. The update on test may be different from src update. I may divide the fix into two PRs, if I figure out how to build the missing uses of sprintf:s. Thank for for the feedback. I appreciated it. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From mcimadamore at openjdk.org Fri Jan 13 11:01:24 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 13 Jan 2023 11:01:24 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Thu, 12 Jan 2023 21:04:09 GMT, Archie L. Cobbs wrote: >> but what if `m` is a static method in a separate compilation unit? Should it be able to observe a partially initialized Foo? > > Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal. > > We only care about bugs where a superclass and subclass are in separate compilation units. So, to clarify, in this case: import java.util.*; class B { final Object ref; private B(Object ref) { Foo.consume(this); this.ref = ref; } } Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized! That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Fri Jan 13 11:11:31 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 13 Jan 2023 11:11:31 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Fri, 13 Jan 2023 11:05:51 GMT, Maurizio Cimadamore wrote: >> So, to clarify, in this case: >> >> >> import java.util.*; >> >> class B { >> final Object ref; >> >> private B(Object ref) { >> Foo.consume(this); >> this.ref = ref; >> } >> } >> >> >> Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized! >> >> That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok. > > Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this: > > > this-escape Warn when a constructor invokes a method that could be overriden in a subclass; > > > Which indeed aligns well with what this PR is doing. So that's ok. Something seems to be up with the lint description for this-escape - compare this: serial Warn about Serializable classes that do not have a serialVersionUID field. Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces. with this: this-escape Warn when a constructor invokes a method that could be overriden in a subclass; such a method would execute before the subclass constructor completes its initialization. Indentation seems to be missing, which causes readability issues in the `--help-lint` output. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Fri Jan 13 11:11:31 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 13 Jan 2023 11:11:31 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Fri, 13 Jan 2023 10:58:33 GMT, Maurizio Cimadamore wrote: >> Caring about the proper initialization of any class in the _current_ compilation unit is an explicit non-goal. >> >> We only care about bugs where a superclass and subclass are in separate compilation units. > > So, to clarify, in this case: > > > import java.util.*; > > class B { > final Object ref; > > private B(Object ref) { > Foo.consume(this); > this.ref = ref; > } > } > > > Even though `this` leaks to a method clearly before it is fully initialized, we do not care because there can be no subclass involved observing this. I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well - we're effectively leaking a class whose final field has not been initialized! > > That said, if that was discussed, and it was decided for the warning not to deal with this case, that's ok. Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this: this-escape Warn when a constructor invokes a method that could be overriden in a subclass; Which indeed aligns well with what this PR is doing. So that's ok. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From vromero at openjdk.org Fri Jan 13 12:45:34 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 13 Jan 2023 12:45:34 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision: > > - Fix bug where all but the last yeild statement were being ignored. > - Add method RefSet.mapInto() and use to refactor/clean up. > - Fix possible assertion failure when handling if statements. > - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff. > > Suggested-by: mcimadamore > - Add comment regarding limitations of expresison type filtering. > - Add a few more DISABLED_WARNINGS to unbreak build. > - Clean up handling of switch expressions a bit. > - Remove unused method variant of analyzeTree(). > - Avoid all caps in comments. > - Clarify confusing comment. > - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516: > 514: Name name = TreeInfo.name(invoke.meth); > 515: if (name == names._super) { > 516: scanInitializers(); it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class ------------- PR: https://git.openjdk.org/jdk/pull/11874 From vromero at openjdk.org Fri Jan 13 14:34:40 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 13 Jan 2023 14:34:40 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision: > > - Fix bug where all but the last yeild statement were being ignored. > - Add method RefSet.mapInto() and use to refactor/clean up. > - Fix possible assertion failure when handling if statements. > - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff. > > Suggested-by: mcimadamore > - Add comment regarding limitations of expresison type filtering. > - Add a few more DISABLED_WARNINGS to unbreak build. > - Clean up handling of switch expressions a bit. > - Remove unused method variant of analyzeTree(). > - Avoid all caps in comments. > - Clarify confusing comment. > - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 533: > 531: if (sym != null && > 532: sym.owner.kind == TYP && > 533: ((ClassSymbol)sym.owner).fullname == names.java_lang_Object && nit: in general we use another idiom for this in the compiler: sym.owner.type.tsym == syms.objectType.tsym where `syms` is an instance of: `com.sun.tools.javac.code.Symtab` ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 15:11:48 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 15:11:48 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Fri, 13 Jan 2023 11:08:33 GMT, Maurizio Cimadamore wrote: >> Perhaps my confusion might come from the name `this-escape` of the lint warning - which seems overpromising in this respect. But I looked at the description of the lint warning using `javac --help-lint` and I got this: >> >> >> this-escape Warn when a constructor invokes a method that could be overriden in a subclass; >> >> >> Which indeed aligns well with what this PR is doing. So that's ok. > > Something seems to be up with the lint description for this-escape - compare this: > > > serial Warn about Serializable classes that do not have a serialVersionUID field. > Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces. > > with this: > > > this-escape Warn when a constructor invokes a method that could be overriden in a subclass; > such a method would execute before the subclass constructor completes its initialization. > > > Indentation seems to be missing, which causes readability issues in the `--help-lint` output. > I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well... Yes - and this very question did come up in the discussions around this warning (see amber-dev). The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself". But I think it's still an interesting question. Maybe experience will provide more guidance over time. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 15:11:49 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 15:11:49 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Fri, 13 Jan 2023 15:08:43 GMT, Archie L. Cobbs wrote: >> Something seems to be up with the lint description for this-escape - compare this: >> >> >> serial Warn about Serializable classes that do not have a serialVersionUID field. >> Also warn about other suspect declarations in Serializable and Externalizable classes and interfaces. >> >> with this: >> >> >> this-escape Warn when a constructor invokes a method that could be overriden in a subclass; >> such a method would execute before the subclass constructor completes its initialization. >> >> >> Indentation seems to be missing, which causes readability issues in the `--help-lint` output. > >> I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well... > > Yes - and this very question did come up in the discussions around this warning (see amber-dev). > > The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself". > > But I think it's still an interesting question. Maybe experience will provide more guidance over time. > Something seems to be up with the lint description for this-escape - compare this: Oops, will fix - thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 15:16:59 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 15:16:59 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 12:42:24 GMT, Vicente Romero wrote: >> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision: >> >> - Fix bug where all but the last yeild statement were being ignored. >> - Add method RefSet.mapInto() and use to refactor/clean up. >> - Fix possible assertion failure when handling if statements. >> - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff. >> >> Suggested-by: mcimadamore >> - Add comment regarding limitations of expresison type filtering. >> - Add a few more DISABLED_WARNINGS to unbreak build. >> - Clean up handling of switch expressions a bit. >> - Remove unused method variant of analyzeTree(). >> - Avoid all caps in comments. >> - Clarify confusing comment. >> - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516: > >> 514: Name name = TreeInfo.name(invoke.meth); >> 515: if (name == names._super) { >> 516: scanInitializers(); > > it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy. I'm happy to fix this if you think it is necessary though. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 533: > >> 531: if (sym != null && >> 532: sym.owner.kind == TYP && >> 533: ((ClassSymbol)sym.owner).fullname == names.java_lang_Object && > > nit: in general we use another idiom for this in the compiler: > > sym.owner.type.tsym == syms.objectType.tsym > > where `syms` is an instance of: `com.sun.tools.javac.code.Symtab` Thanks - will fix. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Fri Jan 13 16:09:37 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 13 Jan 2023 16:09:37 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Fri, 13 Jan 2023 15:08:59 GMT, Archie L. Cobbs wrote: >>> I guess I was confused because, while subclasses are a particularly sneaky case where uninitialized values can show up, the above leak seems potentially dangerous as well... >> >> Yes - and this very question did come up in the discussions around this warning (see amber-dev). >> >> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files - even when looking at any single one of those files, there doesn't seem to be any apparent problem. In other words, we decided "not to try to save any single source code from itself". >> >> But I think it's still an interesting question. Maybe experience will provide more guidance over time. > >> Something seems to be up with the lint description for this-escape - compare this: > > Oops, will fix - thanks. > The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files Sorry for being picky - you mention this "compilation unit" boundary before, but this is not really the reason here. Note that in my example B constructor calls out to a static method that is "outside" the boundary. The reason as to why my example is not flagged is simply that "escaping" is defined as "escaping into a subclass method", not just "escaping from the constructor (into some other compilation unit)". ------------- PR: https://git.openjdk.org/jdk/pull/11874 From vromero at openjdk.org Fri Jan 13 16:15:32 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 13 Jan 2023 16:15:32 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: Message-ID: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com> On Fri, 13 Jan 2023 15:14:05 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 516: >> >>> 514: Name name = TreeInfo.name(invoke.meth); >>> 515: if (name == names._super) { >>> 516: scanInitializers(); >> >> it seems like the code scan initializers every time it finds a super() invocation, I guess that this scanning could be done once per class > > Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy. > > I'm happy to fix this if you think it is necessary though. I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 16:23:39 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 16:23:39 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> <2yMCKO6JFLW6MlAxdn1cRivontgIkZO8fCy-BexB6cg=.beb90f18-40b5-41eb-83c9-ec179e2ae2ff@github.com> Message-ID: On Fri, 13 Jan 2023 16:06:04 GMT, Maurizio Cimadamore wrote: >>> Something seems to be up with the lint description for this-escape - compare this: >> >> Oops, will fix - thanks. > >> The decision was to go with drawing the "warning boundary" at the compilation unit. The reasoning is that (a) this aligns with the compiler's "knowledge boundary", i.e., we can know for sure from code inspection, and also (b) focuses the warning on the particularly pernicious aspect of these bugs, which is that they arise from the non-obvious interaction among two or more files > > Sorry for being picky - you mention this "compilation unit" boundary before, but this is not really the reason here. Note that in my example B constructor calls out to a static method that is "outside" the boundary. The reason as to why my example is not flagged is simply that "escaping" is defined as "escaping into a subclass method", not just "escaping from the constructor (into some other compilation unit)". Oops, you're right, I answered the wrong question so to speak. The "must involve a subclass" requirement is another dimension on which a "boundary" was declared. This was also part of the original discussion. So yes the requirement is: "requires involvement of a subclass" **AND** "that subclass lives in a separate compilation unit". ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 16:23:42 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 16:23:42 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com> References: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com> Message-ID: On Fri, 13 Jan 2023 16:12:50 GMT, Vicente Romero wrote: >> Yes... I did it that way is so that it doesn't require any adaptation if/when JDK-8194743 ever gets implemented. And it keeps the code a little simpler in exchange for a little redundancy. >> >> I'm happy to fix this if you think it is necessary though. > > I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration Sounds good - thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From coleenp at openjdk.org Fri Jan 13 16:51:22 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 13 Jan 2023 16:51:22 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 09:22:03 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated some copyright dates. This looks great. Very nice work! src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 306: > 304: // set relativized locals > 305: // this line can be changed into an assert when we have fixed the "frame padding problem" > 306: *f.addr_at(frame::interpreter_frame_locals_offset) = (bottom - 1) - f.fp(); Thank you for this comment. When you file the CR for this problem, can you point to this CR? src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp line 554: > 552: inline void ThawBase::set_interpreter_frame_bottom(const frame& f, intptr_t* bottom) { > 553: // set relativized locals > 554: // this line can be changed into an assert when we have fixed the "frame padding problem" Can you file an RFE (or is there already one) to describe this? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From vromero at openjdk.org Fri Jan 13 17:38:27 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 13 Jan 2023 17:38:27 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 04:04:36 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision: > > - Fix bug where all but the last yeild statement were being ignored. > - Add method RefSet.mapInto() and use to refactor/clean up. > - Fix possible assertion failure when handling if statements. > - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff. > > Suggested-by: mcimadamore > - Add comment regarding limitations of expresison type filtering. > - Add a few more DISABLED_WARNINGS to unbreak build. > - Clean up handling of switch expressions a bit. > - Remove unused method variant of analyzeTree(). > - Avoid all caps in comments. > - Clarify confusing comment. > - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5 src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685: > 683: > 684: @Override > 685: public void visitDoLoop(JCDoWhileLoop tree) { I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document ------------- PR: https://git.openjdk.org/jdk/pull/11874 From jcking at openjdk.org Fri Jan 13 17:39:41 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 17:39:41 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v8] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Apply patch from stefank@ Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/5d30170a..4aba784e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=06-07 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Fri Jan 13 17:39:43 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 17:39:43 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 15:08:23 GMT, Stefan Karlsson wrote: >>> I'm happy to see this flag getting removed. I'm less happy about seeing usages of the array allocators being replaced by macros. I'd rather see an effort towards getting rid of these macros. Could we limit this patch to only remove the ArrayAllocatorMallocLimit flag and ArrayAllocator class, and defer the discussion around what API to use for array allocations? >> >> `ArrayAllocator` with `ArrayAllocatorMallocLimit` removed is effectively `MallocArrayAllocator`. Are you suggesting leaving `MallocArrayAllocator` and `MmapArrayAllocator` thus update references to `ArrayAllocator` to be `MallocArrayAllocator`? >> >> As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). > >> ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and MmapArrayAllocator thus update references to ArrayAllocator to be MallocArrayAllocator? > > Yes, that was what I wanted. > >> As far as APIs, the majority of the codebase uses the macros. IMO consistency would be better and having two ways of doing things doesn't help. But if you feel strongly about it, we can punt and just surgically remove the bare minimum, assuming you clarify your expectation (see above). > > I agree about the argument about consistency, so I retract my objection. We can deal with these macros as a separate RFE (if we ever get to it). > > I would like to retain the usage of mmapped memory for ZGC to minimize the risk of any surprises for us. ZGC code also tend to initialize as much as possible in the initialization list, so the extra memset that comes after initialization lists sticks out a bit. Could you create a private `ZGranuleMap::allocate_array` function that uses os::reserve_memory/commmit_memory and change the code to be: > > inline ZGranuleMap::ZGranuleMap(size_t max_offset) : > _size(max_offset >> ZGranuleSizeShift), > _map(allocate_array(_size)) { > > > Or if you like, I can provide a patch on top of your branch to do that. Applied your patch @stefank ------------- PR: https://git.openjdk.org/jdk/pull/11931 From jcking at openjdk.org Fri Jan 13 17:50:50 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 17:50:50 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v9] In-Reply-To: References: Message-ID: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with two additional commits since the last revision: - Fix compilation error Signed-off-by: Justin King - Preserve mmap usage in gc/g1/g1ConcurrentMark Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/4aba784e..4b5ce84b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=07-08 Stats: 33 lines in 2 files changed: 30 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From duke at openjdk.org Fri Jan 13 17:52:31 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 17:52:31 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 17:35:08 GMT, Vicente Romero wrote: >> Archie L. Cobbs has updated the pull request incrementally with 16 additional commits since the last revision: >> >> - Fix bug where all but the last yeild statement were being ignored. >> - Add method RefSet.mapInto() and use to refactor/clean up. >> - Fix possible assertion failure when handling if statements. >> - Use Symbol methods isSubClass() and isEnclosedBy() instead of homebrew stuff. >> >> Suggested-by: mcimadamore >> - Add comment regarding limitations of expresison type filtering. >> - Add a few more DISABLED_WARNINGS to unbreak build. >> - Clean up handling of switch expressions a bit. >> - Remove unused method variant of analyzeTree(). >> - Avoid all caps in comments. >> - Clarify confusing comment. >> - ... and 6 more: https://git.openjdk.org/jdk/compare/6e96a7d7...edf3c3f5 > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685: > >> 683: >> 684: @Override >> 685: public void visitDoLoop(JCDoWhileLoop tree) { > > I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document Hah - I didn't think of that. But actually I don't think we would miss anything (see if you agree). The code "executes" every loop, in a sort-of simulation, adding references until the set of references converges. Moreover, that reference set is "append only" while this is happening. Therefore, during actual execution, a break or continue may cause less code to be executed than in our simulation, but never more code than our simulation. So during actual execution it might be that fewer actual 'this' references are created, but never more. Therefore, this effect might cause false positives (which of course we already have with loops and code in general because we take all possible branches), but never false negatives. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From jcking at openjdk.org Fri Jan 13 17:50:52 2023 From: jcking at openjdk.org (Justin King) Date: Fri, 13 Jan 2023 17:50:52 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v8] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 17:39:41 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. > > Justin King has updated the pull request incrementally with one additional commit since the last revision: > > Apply patch from stefank@ > > Signed-off-by: Justin King Restored `mmap` for G1, though in the future it might make sense to switch to just using malloc. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From sspitsyn at openjdk.org Fri Jan 13 18:34:13 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 13 Jan 2023 18:34:13 GMT Subject: RFR: 8300024: Replace use of JNI_COMMIT mode with mode 0 [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 07:16:35 GMT, Daniel Jeli?ski wrote: >> Please review this patch that fixes a few memory leaks in JNI code. >> >> [The latest documentation](https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#releaseprimitivetypearrayelements-routines) of JNI functions makes an explicit note about the use of JNI_COMMIT: >> >>> If `JNI_COMMIT` is passed as the `mode` argument when `elems` is a copy of the elements in `array`, then a final call to *ReleaseArrayElements* passing a `mode` argument of "0" or `JNI_ABORT`, should be made to free the `elems` buffer >> >> No new regression test. I manually verified the Linux fix using ClhdsbPstack test in root mode. Also, tier1-2 tests on mach5 continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > MacOS fix Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11963 From duke at openjdk.org Fri Jan 13 19:09:54 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 19:09:54 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision: - Use more idiomatic test for java.lang.Object. - Revert 27cb30129; the error was actually fixed in edf3c3f51. - Fix formatting issue with the "this-escape" --help-lint description. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/edf3c3f5..ae37ff7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=07-08 Stats: 12 lines in 3 files changed: 3 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From vromero at openjdk.org Fri Jan 13 19:20:29 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 13 Jan 2023 19:20:29 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: Message-ID: <9xqxePs8UvBJIyPMojy6Bjbl7h3VguJcIwjFhbPr_78=.5ed61dac-21e7-4214-8faf-85f5612f5b46@github.com> On Fri, 13 Jan 2023 17:49:05 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 685: >> >>> 683: >>> 684: @Override >>> 685: public void visitDoLoop(JCDoWhileLoop tree) { >> >> I was thinking, code can also loop using labels and `break` / `continue`, not something we need to cover as part of this prototype but could be a future TODO that we can document > > Hah - I didn't think of that. But actually I don't think we would miss anything (see if you agree). > > The code "executes" every loop, in a sort-of simulation, adding references until the set of references converges. Moreover, that reference set is "append only" while this is happening. > > Therefore, during actual execution, a break or continue may cause less code to be executed than in our simulation, but never more code than our simulation. So during actual execution it might be that fewer actual 'this' references are created, but never more. > > Therefore, this effect might cause false positives (which of course we already have with loops and code in general because we take all possible branches), but never false negatives. yep I agree ------------- PR: https://git.openjdk.org/jdk/pull/11874 From vromero at openjdk.org Fri Jan 13 20:19:53 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 13 Jan 2023 20:19:53 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 19:09:54 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision: > > - Use more idiomatic test for java.lang.Object. > - Revert 27cb30129; the error was actually fixed in edf3c3f51. > - Fix formatting issue with the "this-escape" --help-lint description. test/langtools/tools/javac/warnings/ThisEscape/ThisEscapeBasic.java line 8: > 6: */ > 7: > 8: public class ThisEscapeBasic { I wonder if it could be better to just fold most of these tests in particular the small ones and create just one, or a few tests, with several subclasses, that will reduce the overhead if in the future we change the code and we need to change the golden files. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From vromero at openjdk.org Fri Jan 13 20:24:46 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 13 Jan 2023 20:24:46 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 19:09:54 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision: > > - Use more idiomatic test for java.lang.Object. > - Revert 27cb30129; the error was actually fixed in edf3c3f51. > - Fix formatting issue with the "this-escape" --help-lint description. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088: > 1086: private void visitLooped(T tree, Consumer visitor) { > 1087: visitScoped(tree, false, t -> { > 1088: while (true) { I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times ------------- PR: https://git.openjdk.org/jdk/pull/11874 From cjplummer at openjdk.org Fri Jan 13 20:51:13 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 13 Jan 2023 20:51:13 GMT Subject: RFR: 8300024: Replace use of JNI_COMMIT mode with mode 0 [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 07:16:35 GMT, Daniel Jeli?ski wrote: >> Please review this patch that fixes a few memory leaks in JNI code. >> >> [The latest documentation](https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#releaseprimitivetypearrayelements-routines) of JNI functions makes an explicit note about the use of JNI_COMMIT: >> >>> If `JNI_COMMIT` is passed as the `mode` argument when `elems` is a copy of the elements in `array`, then a final call to *ReleaseArrayElements* passing a `mode` argument of "0" or `JNI_ABORT`, should be made to free the `elems` buffer >> >> No new regression test. I manually verified the Linux fix using ClhdsbPstack test in root mode. Also, tier1-2 tests on mach5 continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > MacOS fix Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11963 From cjplummer at openjdk.org Fri Jan 13 21:09:15 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 13 Jan 2023 21:09:15 GMT Subject: RFR: 8300032: DwarfParser resource leak In-Reply-To: References: Message-ID: <5HX1fA0dUuaZR0DcBljnWXp7jWK0WEBFime2NoWu68k=.ea96d96c-d37f-434d-b674-9a09671914a9@github.com> On Fri, 13 Jan 2023 07:45:59 GMT, Daniel Jeli?ski wrote: > As far as I could tell, the cleaners you pointed out use local variables only. As long as the lambda does not reference any object fields or instance methods, `this` is not captured. Ok. So the lambda needs to reference a field of the `this` in order to capture `this`. I guess that's why you see hacks like this: // Register a cleaning function to close the handle final long local_handle = handle; // local to prevent capture of this CleanerFactory.cleaner().register(this, () -> closeHandle(local_handle)); ------------- PR: https://git.openjdk.org/jdk/pull/11965 From cjplummer at openjdk.org Fri Jan 13 21:13:15 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 13 Jan 2023 21:13:15 GMT Subject: RFR: 8300032: DwarfParser resource leak In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 12:08:51 GMT, Daniel Jeli?ski wrote: > Please review this fix for DwarfParser cleaner. > > The original code registered the cleaner using a lambda that captured a reference to the parser object; as a result, the object was never GCed, and the cleaner never ran. > > In this version I moved the lambda creation to a static method, so that it can't capture a reference to the parser. > > Additionally, the new code uses a static cleaner; the cleaner object creation and cleanup are heavy operations (every cleaner comes with its own thread), and it's preferable to use a single shared cleaner where possible. > > I verified manually that the native `destroyDwarfContext` method is called after this fix. No new automated test. Existing tier1-2 tests continue to pass. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11965 From duke at openjdk.org Fri Jan 13 21:23:24 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 21:23:24 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 20:16:25 GMT, Vicente Romero wrote: >> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision: >> >> - Use more idiomatic test for java.lang.Object. >> - Revert 27cb30129; the error was actually fixed in edf3c3f51. >> - Fix formatting issue with the "this-escape" --help-lint description. > > test/langtools/tools/javac/warnings/ThisEscape/ThisEscapeBasic.java line 8: > >> 6: */ >> 7: >> 8: public class ThisEscapeBasic { > > I wonder if it could be better to just fold most of these tests in particular the small ones and create just one, or a few tests, with several subclasses, that will reduce the overhead if in the future we change the code and we need to change the golden files. I really don't have any informed opinion on this. I can see arguments both ways... putting all you eggs in one basket can be seen alternately as foolhardy or highly efficient :) FWIW in the past I've had problems with trying to combine multiples tests that generate errors into one file. The compiler seems to like to bail out early when it sees errors. I guess that experience was working subconsciously. Of course that doesn't apply here as these are all warnings. And a bunch of separate files make the test run slower. So I agree with you - I'll consolidate them. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 21:31:25 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 21:31:25 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 20:21:24 GMT, Vicente Romero wrote: >> Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision: >> >> - Use more idiomatic test for java.lang.Object. >> - Revert 27cb30129; the error was actually fixed in edf3c3f51. >> - Fix formatting issue with the "this-escape" --help-lint description. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088: > >> 1086: private void visitLooped(T tree, Consumer visitor) { >> 1087: visitScoped(tree, false, t -> { >> 1088: while (true) { > > I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop. That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`). If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here). ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 21:36:30 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 21:36:30 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com> Message-ID: On Fri, 13 Jan 2023 16:20:41 GMT, Archie L. Cobbs wrote: >> I'm OK either way we can revisit this later either as part of this PR or in a future one. I let it to your consideration > > Sounds good - thanks. Ah. I just realized that we need to do it your way because of the following bug: Suppose you have a constructor and a field with initializer that both leak, but you have `@SuppressWarnings("this-escape")` on the constructor. Then the leak for the field will never be reported because we never get to it. I'll fix. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From vromero at openjdk.org Fri Jan 13 22:04:03 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 13 Jan 2023 22:04:03 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v8] In-Reply-To: References: <77lMG_P3_ZGjTegQictMdNN1IKjWixuzLWy5-GbHYnI=.bdbfc529-2ac8-4bba-b3a6-d08f0977e372@github.com> Message-ID: <1ylDnjbWJwdsJP-dVL1zthfhVHZbcOgnC3gxgNuKBZk=.6367e3b4-18ae-4232-b43a-c469e58f9a2d@github.com> On Fri, 13 Jan 2023 21:33:02 GMT, Archie L. Cobbs wrote: >> Sounds good - thanks. > > Ah. I just realized that we need to do it your way because of the following bug: > > Suppose you have a constructor and a field with initializer that both leak, but you have `@SuppressWarnings("this-escape")` on the constructor. > > Then the leak for the field will never be reported because we never get to it. > > I'll fix. yep, right in that case that leak wouldn't be reported ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Fri Jan 13 22:48:59 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Fri, 13 Jan 2023 22:48:59 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v10] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Fix bug where field initializer warnings could be incorrectly suppressed. - Consolidate all the unit tests that generate warnings into one. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/ae37ff7c..0b06dc32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=08-09 Stats: 1454 lines in 35 files changed: 658 ins; 762 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From xuelei at openjdk.org Fri Jan 13 23:27:36 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 13 Jan 2023 23:27:36 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v2] In-Reply-To: References: Message-ID: <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com> > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: more in src/hotspot ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/1f7706f9..62a6be82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=00-01 Stats: 59 lines in 12 files changed: 2 ins; 2 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From cjplummer at openjdk.org Fri Jan 13 23:28:15 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 13 Jan 2023 23:28:15 GMT Subject: Integrated: 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method In-Reply-To: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> References: <-x9mPWnJSRPJzTF86Y0rNcL0UOf8YmEeFNrxrj4FI_Y=.26477a19-891c-4a5b-80fa-01bba825717a@github.com> Message-ID: On Thu, 12 Jan 2023 02:20:04 GMT, Chris Plummer wrote: > `VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object)` is not used. Furthermore it confuses the reader that runs across `removeObjectMirror()` calls, because what is actually being called is `removeObjectMirror(SoftObjectReference ref)`. This pull request has now been integrated. Changeset: f4e119d5 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/f4e119d5fcdf592f59a7d029070eba3878e24a7c Stats: 19 lines in 1 file changed: 0 ins; 17 del; 2 mod 8300012: Remove unused JDI VirtualMachineImpl.removeObjectMirror(ObjectReferenceImpl object) method Reviewed-by: alanb, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11957 From mikael at openjdk.org Sat Jan 14 00:44:11 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Sat, 14 Jan 2023 00:44:11 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v2] In-Reply-To: <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com> References: <9QM0jWWZ-iupPlS3I9Ym-VDl6egK0jHXGezReju0vCs=.b8396d23-68b6-4ea6-8ee3-4ab0fca39963@github.com> Message-ID: On Fri, 13 Jan 2023 23:27:36 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > more in src/hotspot Thank you for making these additional changes! I'm still seeing some issue building on linux-x64, for example: src/hotspot/share/opto/regalloc.hpp:130:17: note: candidate: 'virtual char* PhaseRegAlloc::dump_register(const Node*, char*, size_t) const' 130 | virtual char *dump_register( const Node *n, char *buf, size_t buf_size) const = 0; | ^~~~~~~~~~~~~ ------------- PR: https://git.openjdk.org/jdk/pull/11935 From sspitsyn at openjdk.org Sat Jan 14 01:43:20 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 14 Jan 2023 01:43:20 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: References: <-u9V0TIbZ41IPEmql4jeLKzAmT9OPIZAurEoN-K2BXc=.0b8e5b84-47be-4d49-b99c-9317b25258e4@github.com> Message-ID: On Wed, 4 Jan 2023 07:45:48 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 482: >> >>> 480: _VTMS_transition_disable_for_all_count > 0) { >>> 481: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); >>> 482: ml.notify_all(); >> >> Checking the counts outside the lock seems really racy. Maybe it is safe in the original code but now we have two counters it is very hard to ascertain this is correct. Overall I find it very hard to see exactly how these counters get used. > > This notification code is just an optimization. All related waiting fragments are with timeouts. > I agree this sync protocol is kind of complicated and also does not scale well. I'm still thinking on how to improve it. I have a two week vacation starting from Monday. Not sure, that I'll be able to see review comments this time. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From duke at openjdk.org Sat Jan 14 01:57:32 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Sat, 14 Jan 2023 01:57:32 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v7] In-Reply-To: References: <7lxiY8WIdkIkI5fqLn52qkq2fvSc04huqWL_fV2WSy8=.7bd29e16-bcee-473e-937e-aea32b211db3@github.com> Message-ID: On Fri, 13 Jan 2023 00:57:14 GMT, Archie L. Cobbs wrote: >> Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern. I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it. > >> Ok - I thought false negative was the thing to absolutely avoid - and that was the no. 1 concern. > > You're right. I think at the time I reasoned that it would be unusual enough for the type of an expression to start as an instanceof X, then change to not being an instanceof X, and then change back, that it was worth it to go ahead and filter these out. But admittedly that was based on intuition, not science. > >> I think a possible approach to keep both the filtering and the code more or less similar to what you have, is to save the type of the expression in the ExprRef. Then, I believe that, at the end of scan() you can just get whatever type is there, and check that it's the correct one, if not drop it. > > That's a nice idea... thanks. I'll play around with it some. I was curious how much of a difference this type filtering makes, so I built the JDK with and without it. The results were identical except for one case: package java.lang.invoke; ... public abstract sealed class CallSite permits ConstantCallSite, MutableCallSite, VolatileCallSite { ... CallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable { this(targetType); // need to initialize target to make CallSite.type() work in createTargetHook ConstantCallSite selfCCS = (ConstantCallSite) this; MethodHandle boundTarget = (MethodHandle) createTargetHook.invokeWithArguments(selfCCS); setTargetNormal(boundTarget); // ConstantCallSite doesn't publish CallSite.target UNSAFE.storeStoreFence(); // barrier between target and isFrozen updates } When we do type filtering, `(ConstantCallSite) this` causes the 'this' reference to be discarded so no leak is reported on the next line for `invokeWithArguments(selfCCS)`. Just a side note, there is also a leak on the next line because final method `setTargetNormal()` invokes `MethodHandleNatives.setCallSiteTargetNormal(this, newTarget)`, so a leak does get reported anyway even with type filtering. When type filtering is disabled, we report a leak at `invokeWithArguments(selfCCS)` - which is accurate. So what did we learn? First it looks like type filtering has very minimal effect. I think this is because it requires some version of two casts in a row in and out of type compatibility, and this is probably very rare. But looking at the one data point we do have, the type filtering did in fact cause a false negative. And when building the entire JDK, it causes zero net new false positives. So to me this is evidence that we should just remove the type filtering altogether... @vicente-romero-oracle your thoughts? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From xuelei at openjdk.org Sat Jan 14 03:37:26 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 14 Jan 2023 03:37:26 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v3] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: missed update for debug mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/62a6be82..98c7d3dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=01-02 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Sat Jan 14 06:36:33 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 14 Jan 2023 06:36:33 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v4] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: correction for ppc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/98c7d3dd..076f8b54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Sat Jan 14 18:52:09 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 14 Jan 2023 18:52:09 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: <2uKA4WjPxwJ_rBTfaHM6d60QEplxWxMDLlL8falWyD4=.889cee2f-9ec0-48b0-a34a-37080ae7e038@github.com> On Fri, 13 Jan 2023 01:56:23 GMT, Serguei Spitsyn wrote: > There are more uses of sprintf in some serviceability folders: Yes. There are at least 57 src files that use sprintf function, as far as I can see. This PR is pretty big now. I would like to clean them up in an other PR so that it is easier to review. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Sat Jan 14 19:01:52 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 14 Jan 2023 19:01:52 GMT Subject: RFR: 8299635: More test issues for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: Message-ID: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in test cases, and replace it with snprintf accordingly. Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge - correction for ppc - missed update for debug mode - more in src/hotspot - typo correction - 8299635: More test issues for deprecated sprintf in Xcode 14 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/076f8b54..143887e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=03-04 Stats: 8279 lines in 310 files changed: 5031 ins; 1837 del; 1411 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From djelinski at openjdk.org Mon Jan 16 07:00:18 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 16 Jan 2023 07:00:18 GMT Subject: Integrated: 8300032: DwarfParser resource leak In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 12:08:51 GMT, Daniel Jeli?ski wrote: > Please review this fix for DwarfParser cleaner. > > The original code registered the cleaner using a lambda that captured a reference to the parser object; as a result, the object was never GCed, and the cleaner never ran. > > In this version I moved the lambda creation to a static method, so that it can't capture a reference to the parser. > > Additionally, the new code uses a static cleaner; the cleaner object creation and cleanup are heavy operations (every cleaner comes with its own thread), and it's preferable to use a single shared cleaner where possible. > > I verified manually that the native `destroyDwarfContext` method is called after this fix. No new automated test. Existing tier1-2 tests continue to pass. This pull request has now been integrated. Changeset: fe7fca01 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/fe7fca0128ca3a7b514c49d1508ca64499a8bb8e Stats: 8 lines in 1 file changed: 5 ins; 1 del; 2 mod 8300032: DwarfParser resource leak Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11965 From djelinski at openjdk.org Mon Jan 16 07:02:16 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 16 Jan 2023 07:02:16 GMT Subject: Integrated: 8300024: Replace use of JNI_COMMIT mode with mode 0 In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 09:23:49 GMT, Daniel Jeli?ski wrote: > Please review this patch that fixes a few memory leaks in JNI code. > > [The latest documentation](https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#releaseprimitivetypearrayelements-routines) of JNI functions makes an explicit note about the use of JNI_COMMIT: > >> If `JNI_COMMIT` is passed as the `mode` argument when `elems` is a copy of the elements in `array`, then a final call to *ReleaseArrayElements* passing a `mode` argument of "0" or `JNI_ABORT`, should be made to free the `elems` buffer > > No new regression test. I manually verified the Linux fix using ClhdsbPstack test in root mode. Also, tier1-2 tests on mach5 continue to pass. This pull request has now been integrated. Changeset: 50e7df91 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/50e7df91c77d436937fff9134174ddb8a8dd4dd7 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod 8300024: Replace use of JNI_COMMIT mode with mode 0 Reviewed-by: amenkov, sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/11963 From duke at openjdk.org Mon Jan 16 11:34:47 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Mon, 16 Jan 2023 11:34:47 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v3] In-Reply-To: References: Message-ID: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Added references to JDK-8300197 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11902/files - new: https://git.openjdk.org/jdk/pull/11902/files/54a0931d..ac821a10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=01-02 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From mcimadamore at openjdk.org Mon Jan 16 11:56:24 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 16 Jan 2023 11:56:24 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v10] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 22:48:59 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ >> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) >> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor >> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly >> >> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. >> >> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. >> >> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. >> >> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. >> >> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. >> >> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. >> >> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. >> >> **Patch Navigation Guide** >> >> * Non-trivial compiler changes: >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` >> * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` >> >> * Javadoc additions of `@implNote`: >> >> * `src/java.base/share/classes/java/io/PipedReader.java` >> * `src/java.base/share/classes/java/io/PipedWriter.java` >> * `src/java.base/share/classes/java/lang/Throwable.java` >> * `src/java.base/share/classes/java/util/ArrayDeque.java` >> * `src/java.base/share/classes/java/util/EnumMap.java` >> * `src/java.base/share/classes/java/util/HashSet.java` >> * `src/java.base/share/classes/java/util/Hashtable.java` >> * `src/java.base/share/classes/java/util/LinkedList.java` >> * `src/java.base/share/classes/java/util/TreeMap.java` >> * `src/java.base/share/classes/java/util/TreeSet.java` >> >> * New unit tests >> * `test/langtools/tools/javac/warnings/ThisEscape/*.java` >> >> * **Everything else** is just adding `@SuppressWarnings("this-escape")` > > Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: > > - Fix bug where field initializer warnings could be incorrectly suppressed. > - Consolidate all the unit tests that generate warnings into one. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1096: > 1094: > 1095: // Perform the given action within a new scope > 1096: private void visitScoped(boolean promote, Runnable action) { type-variable unused here? ------------- PR: https://git.openjdk.org/jdk/pull/11874 From mcimadamore at openjdk.org Mon Jan 16 12:54:22 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 16 Jan 2023 12:54:22 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 21:28:51 GMT, Archie L. Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1088: >> >>> 1086: private void visitLooped(T tree, Consumer visitor) { >>> 1087: visitScoped(tree, false, t -> { >>> 1088: while (true) { >> >> I have also been thinking if the loop analysis could go wild and execute a large, unbound number of times. But it seems from Archie's experiments that this probably won't occur in "normal" code and worst case scenario if that were to occur we can always limit the number of times we will process loops to a set number of times > > The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop. > > That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`). > > If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here). I have played a bit with the patch, trying to disable certain features. The main reason to deal with loops and recursive calls the way the patch does is to eliminate false positives. If we see a loop, and we can't perform the analysis multiple times (as the PR does), then we'd have to conclude that the loop can be potentially escaping (as we might have missed an local var update). Same goes for recursive calls (e.g. a recursive call would be treated as escaping). Same goes for analyzing invoked methods that fall in the same compilation unit. If we don't do that, more methods might look as "escaping". So, here's what I found: * compiling the JDK with the current patch produces 2376 warnings * disabling support for recursive calls produces 2427 warnings * treating all method calls inside a loop to be escaping produces 2464 warnings * disabling scanning of methods in same compilation unit produces 4317 warnings (Note: the patches I used to do this analysis are a bit blunt, and perhaps can be made a bit less conservative, which might result in less false positives added - I just went for the simplest possible approach, just to test the contribute of each analysis). This seems to suggest that even a blunt approach to deal with recursion and loop does not result in a significant increase of false positives (~2% more). That said, disabling scanning of methods in the same compilation unit results in a big impact in terms of false positive (~100% increase). So, I'm pretty confident that, should performance problems arise, we could probably dial back the analysis not to do loops (or to do them in a bounded way, as Vicente suggest, which is much better of what I tried here) - and that will probably give us the same results we have today (or a very very minor increase of false positives). But scanning of dependent methods in same compilation unit seems to be more or less a must-have. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Mon Jan 16 13:41:13 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Mon, 16 Jan 2023 13:41:13 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 16:47:59 GMT, Coleen Phillimore wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated some copyright dates. > > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 306: > >> 304: // set relativized locals >> 305: // this line can be changed into an assert when we have fixed the "frame padding problem" >> 306: *f.addr_at(frame::interpreter_frame_locals_offset) = (bottom - 1) - f.fp(); > > Thank you for this comment. When you file the CR for this problem, can you point to this CR? Created JDK-8300197 and added references in the source to i. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From coleenp at openjdk.org Mon Jan 16 13:51:18 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 16 Jan 2023 13:51:18 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v10] In-Reply-To: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> References: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> Message-ID: On Wed, 11 Jan 2023 10:49:59 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable I have no further comments. This patch passes testing tier 1-7 for me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Mon Jan 16 15:49:28 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 16 Jan 2023 15:49:28 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v10] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 11:53:40 GMT, Maurizio Cimadamore wrote: >> Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix bug where field initializer warnings could be incorrectly suppressed. >> - Consolidate all the unit tests that generate warnings into one. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1096: > >> 1094: >> 1095: // Perform the given action within a new scope >> 1096: private void visitScoped(boolean promote, Runnable action) { > > type-variable unused here? Thanks - will fix. ------------- PR: https://git.openjdk.org/jdk/pull/11874 From duke at openjdk.org Mon Jan 16 16:32:25 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 16 Jan 2023 16:32:25 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9] In-Reply-To: References: Message-ID: <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com> On Mon, 16 Jan 2023 12:51:49 GMT, Maurizio Cimadamore wrote: >> The number of times around any single loop is bounded by the number of new references that can possibly be created during the analysis of that loop. >> >> That number is at most 2 * (1 + 1 + 1 + 1 + N) where N is the number of parameters and/or variables declared in that scope (the 2 is for direct or indirect, and the 1's are for each of the singleton reference types `ThisRef`, `OuterRef`, `ExprRef`, and `ReturnRef`). >> >> If you have nested scopes A, B, C each with Na, Nb, and Nc variables declared therein (respectively), then the bound would be something like 2 * (1 + 1 + 1 + 1 + Na + (Na * Nb) + (Na * Nb * Nc)) worst case (waving hands here). > > I have played a bit with the patch, trying to disable certain features. The main reason to deal with loops and recursive calls the way the patch does is to eliminate false positives. If we see a loop, and we can't perform the analysis multiple times (as the PR does), then we'd have to conclude that the loop can be potentially escaping (as we might have missed an local var update). Same goes for recursive calls (e.g. a recursive call would be treated as escaping). Same goes for analyzing invoked methods that fall in the same compilation unit. If we don't do that, more methods might look as "escaping". > > So, here's what I found: > > * compiling the JDK with the current patch produces 2376 warnings > * disabling support for recursive calls produces 2427 warnings > * treating all method calls inside a loop to be escaping produces 2464 warnings > * disabling scanning of methods in same compilation unit produces 4317 warnings > > (Note: the patches I used to do this analysis are a bit blunt, and perhaps can be made a bit less conservative, which might result in less false positives added - I just went for the simplest possible approach, just to test the contribute of each analysis). > > This seems to suggest that even a blunt approach to deal with recursion and loop does not result in a significant increase of false positives (~2% more). That said, disabling scanning of methods in the same compilation unit results in a big impact in terms of false positive (~100% increase). > > So, I'm pretty confident that, should performance problems arise, we could probably dial back the analysis not to do loops (or to do them in a bounded way, as Vicente suggest, which is much better of what I tried here) - and that will probably give us the same results we have today (or a very very minor increase of false positives). But scanning of dependent methods in same compilation unit seems to be more or less a must-have. Thanks for doing that analysis - very interesting. It looks like you might be counting the "here via invocation" lines as separate warnings. These are really part of the previous `possible 'this' escape` line, e.g.: .../java/awt/Frame.java:429: Note: possible 'this' escape before subclass is fully initialized init(title, null); ^ .../java/awt/Frame.java:460: Note: previous possible 'this' escape happens here via invocation SunToolkit.checkAndSetPolicy(this); ^ Semi-related... I was also curious what would happen if we changed the semantics of the warning from "subclass must be in a separate compilation unit" to "subclass must be in a separate package". I'm not proposing we change this definition, and obviously there are trade-offs in where you draw this boundary, but was curious anywan (at one point I thought it might be worth having an option for this, e.g., with variants like `-Xlint:this-escape` vs. `-Xlint:this-escape:package`, or even `-Xlint:this-escape:module`, etc.). In any case, here are the results: * Warnings for subclass in separate compilation unit: 2093 * Warnings for subclass in separate package: 1334 So a 36% reduction - not too surprising since the JDK includes a bunch of non-public implementation classes. FWIW this is the patch I used: diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java index e81df22b017..f309a4742aa 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java @@ -216,24 +217,24 @@ class ThisEscapeAnalyzer extends TreeScanner { private Lint lint = ThisEscapeAnalyzer.this.lint; private JCClassDecl currentClass; - private boolean privateOuter; + private boolean nonPublicOuter; @Override public void visitClassDef(JCClassDecl tree) { JCClassDecl currentClassPrev = currentClass; - boolean privateOuterPrev = privateOuter; + boolean nonPublicOuterPrev = nonPublicOuter; Lint lintPrev = lint; lint = lint.augment(tree.sym); try { currentClass = tree; - privateOuter |= tree.sym.isAnonymous(); - privateOuter |= (tree.mods.flags & Flags.PRIVATE) != 0; + nonPublicOuter |= tree.sym.isAnonymous(); + nonPublicOuter |= (tree.mods.flags & Flags.PUBLIC) == 0; // Recurse super.visitClassDef(tree); } finally { currentClass = currentClassPrev; - privateOuter = privateOuterPrev; + nonPublicOuter = nonPublicOuterPrev; lint = lintPrev; } } @@ -268,10 +269,10 @@ class ThisEscapeAnalyzer extends TreeScanner { // Determine if this is a constructor we should analyze boolean analyzable = currentClassIsExternallyExtendable() && TreeInfo.isConstructor(tree) && - !tree.sym.isPrivate() && + (tree.sym.isPublic() || (tree.sym.flags() & Flags.PROTECTED) != 0) && !suppressed.contains(tree.sym); - // Determine if this method is "invokable" in an analysis (can't be overridden) + // Determine if this method is "invokable" in an analysis (can't be overridden outside package) boolean invokable = !currentClassIsExternallyExtendable() || TreeInfo.isConstructor(tree) || (tree.mods.flags & (Flags.STATIC | Flags.PRIVATE | Flags.FINAL)) != 0; @@ -286,12 +287,13 @@ class ThisEscapeAnalyzer extends TreeScanner { } } - // Determines if the current class could be extended in some external compilation unit + // Determines if the current class could be extended in some other package private boolean currentClassIsExternallyExtendable() { return !currentClass.sym.isFinal() && + currentClass.sym.isPublic() && !(currentClass.sym.isSealed() && currentClass.permitting.isEmpty()) && !(currentClass.sym.owner.kind == MTH) && - !privateOuter; + !nonPublicOuter; } }.scan(env.tree); ------------- PR: https://git.openjdk.org/jdk/pull/11874 From ihse at openjdk.org Mon Jan 16 16:50:06 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Jan 2023 16:50:06 GMT Subject: RFR: 8298047: Remove all non-significant trailing whitespace from properties files [v2] In-Reply-To: References: Message-ID: > [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files. > > To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046). > > That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns. > > When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well. > > The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into properties-eol-clean-safe - 8298047: Remove all non-significant trailing whitespace from properties files ------------- Changes: https://git.openjdk.org/jdk/pull/11491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11491&range=01 Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod Patch: https://git.openjdk.org/jdk/pull/11491.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11491/head:pull/11491 PR: https://git.openjdk.org/jdk/pull/11491 From ihse at openjdk.org Mon Jan 16 16:52:12 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Jan 2023 16:52:12 GMT Subject: RFR: 8298047: Remove all non-significant trailing whitespace from properties files In-Reply-To: References: Message-ID: <_jLR_ky5hw9zllvt1MZyi3KWmGOefoRazd7sjzoUivo=.e0bc2d7a-05ad-4417-bc34-369c67c3bf5a@github.com> On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote: > [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files. > > To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046). > > That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns. > > When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well. > > The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. I know this is boring stuff, but please can I get some more reviews on this? Sergey has reviewed the client parts. It's just removing trailing whitespaces. You should be able to just quickly scroll through this and confirm that this is indeed the case. If someone can take pity on me and just quickly check the non-client parts, I'd be very grateful. ------------- PR: https://git.openjdk.org/jdk/pull/11491 From mcimadamore at openjdk.org Mon Jan 16 17:16:26 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 16 Jan 2023 17:16:26 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v9] In-Reply-To: <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com> References: <-vggQR3X6BuroIsmEmI6yohrVGF3MyE-ap7tokjc-7M=.077053ee-fcf9-43db-be53-a9c89ab38a15@github.com> Message-ID: On Mon, 16 Jan 2023 16:29:31 GMT, Archie L. Cobbs wrote: > It looks like you might be counting the "here via invocation" lines as separate warnings. These are really part of the previous `possible 'this' escape` line, e.g.: yes, I really did the simplest possible thing (e.g. just counting the number of escape-this warnings, regardless of their kinds). Perhaps some of my measurements might be skewed as a result - but I think that magnitude-wise they are still telling. > > ``` > .../java/awt/Frame.java:429: Note: possible 'this' escape before subclass is fully initialized > init(title, null); > ^ > .../java/awt/Frame.java:460: Note: previous possible 'this' escape happens here via invocation > SunToolkit.checkAndSetPolicy(this); > ^ > ``` > > Semi-related... I was also curious what would happen if we changed the semantics of the warning from "subclass must be in a separate compilation unit" to "subclass must be in a separate package". To be fair, this is what my brain was reading when you talked about "compilation unit" - but then saw that the code was doing it differently. You see, for "sealed" classes we have a notion of "maintenance domain". E.g. the classes in a `permits` clause of a `sealed` declaration must belong to the same module (if available) or same package (if no module is available). That's how you get the exhaustiveness analysis and all the goodies, by essentially making a close-world assumption on the classes that are passed to javac for a given compilation task. I think it would make a lot of sense to apply these very same boundaries to the escape-this analysis (and, in fact, when looking at warnings coming out of the JDK, I often found false positives that were caused by this). > > I'm not proposing we change this definition, and obviously there are trade-offs in where you draw this boundary, but was curious anywan (at one point I thought it might be worth having an option for this, e.g., with variants like `-Xlint:this-escape` vs. `-Xlint:this-escape:package`, or even `-Xlint:this-escape:module`, etc.). Perhaps - but, as said above, `sealed` already does this by default - so there's a (strong) precedent, I believe, should we want to bend the analysis that way. > > In any case, here are the results: > > * Warnings for subclass in separate compilation unit: 2093 > > * Warnings for subclass in separate package: 1334 > > > So a 36% reduction - not too surprising since the JDK includes a bunch of non-public implementation classes. That corresponds to what I've sampled (unscientifically). ------------- PR: https://git.openjdk.org/jdk/pull/11874 From rriggs at openjdk.org Mon Jan 16 17:25:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 16 Jan 2023 17:25:12 GMT Subject: RFR: 8298047: Remove all non-significant trailing whitespace from properties files [v2] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie wrote: >> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files. >> >> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046). >> >> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns. >> >> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well. >> >> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into properties-eol-clean-safe > - 8298047: Remove all non-significant trailing whitespace from properties files The non-client parts look fine. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11491 From ihse at openjdk.org Mon Jan 16 18:57:21 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Jan 2023 18:57:21 GMT Subject: RFR: 8298047: Remove all non-significant trailing whitespace from properties files [v2] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 17:22:36 GMT, Roger Riggs wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - Merge branch 'master' into properties-eol-clean-safe >> - 8298047: Remove all non-significant trailing whitespace from properties files > > The non-client parts look fine. @RogerRiggs Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11491 From ihse at openjdk.org Mon Jan 16 18:57:22 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 16 Jan 2023 18:57:22 GMT Subject: Integrated: 8298047: Remove all non-significant trailing whitespace from properties files In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote: > [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files. > > To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046). > > That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns. > > When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well. > > The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. This pull request has now been integrated. Changeset: 4073b685 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/4073b68565f9d5283be96ee6b75bab686f076bea Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod 8298047: Remove all non-significant trailing whitespace from properties files Reviewed-by: serb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/11491 From dholmes at openjdk.org Mon Jan 16 23:21:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 23:21:19 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v10] In-Reply-To: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> References: <1vK1PJLqYXa1wlcJrSnyFjtiumgX_nb8G178zv3X-c8=.ea74be21-8518-41d8-8fba-f2f5d6267a44@github.com> Message-ID: On Wed, 11 Jan 2023 10:49:59 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable Still have a couple of nits regarding comments and some uncertainty about API use/behaviour. But okay. Thanks for the updates. src/hotspot/share/prims/jvmtiTagMapTable.cpp line 80: > 78: } > 79: } remove_all; > 80: _table.unlink(&remove_all); This logic is a bit unclear - can you add some comments. I guess I need to understand what unlink does when reading this code. src/hotspot/share/prims/jvmtiTagMapTable.cpp line 101: > 99: JvmtiTagMapKey jtme(obj); > 100: jlong* found = _table.get(jtme); > 101: return found == NULL ? 0 : *found; Please use nullptr in new code ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Mon Jan 16 23:21:20 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 23:21:20 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: <31ZthS6SqGpb-qVWc9EOZFk0x2KYf16KDL5hecw8HmY=.b1ee5b8e-1be0-4c20-bb33-c68d7202d0b2@github.com> References: <31ZthS6SqGpb-qVWc9EOZFk0x2KYf16KDL5hecw8HmY=.b1ee5b8e-1be0-4c20-bb33-c68d7202d0b2@github.com> Message-ID: On Thu, 15 Dec 2022 01:53:32 GMT, David Holmes wrote: >> In the `iterate` method of ResourceHashTable, in respurceHash.hpp lines 227-240 copied here, requires a function that returns boolean. If returned false the iterate will break. >> >> template >> void iterate(Function function) const { // lambda enabled API >> Node* const* bucket = table(); >> const unsigned sz = table_size(); >> while (bucket < bucket_at(sz)) { >> Node* node = *bucket; >> while (node != NULL) { >> bool cont = function(node->_key, node->_value); // <--------------****** >> if (!cont) { return; } >> node = node->_next; >> } >> ++bucket; >> } >> } >> >> The other `iterate` methods are wrappers around this one. >> Always returning true means to continue iterating over all the existing items. >> The former base table for jvmtiTagMapTable needs the `do_entry` be `void`. > > Okay in that case please add to the comment preceding this method: > > // Always return true so the iteration continues. You didn't add the comment I requested. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Mon Jan 16 23:21:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 23:21:22 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v10] In-Reply-To: <0pbB8d_Ihehf2KgV16rg4dh7cLy_eeZE2lGwovLEiBs=.4a05bd73-4252-449a-ae46-448fda30e2e6@github.com> References: <0pbB8d_Ihehf2KgV16rg4dh7cLy_eeZE2lGwovLEiBs=.4a05bd73-4252-449a-ae46-448fda30e2e6@github.com> Message-ID: On Mon, 12 Dec 2022 00:44:29 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 88: >> >>> 86: } >>> 87: >>> 88: JvmtiTagMapTable::~JvmtiTagMapTable() { >> >> Is this the only use of `clear`? If so we can just inline its code here and remove it from the API. > > This issue is not resolved. For clarity `clear()` is also called from `JvmtiTagMap::clear()` ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Mon Jan 16 23:21:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 16 Jan 2023 23:21:23 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 10:01:57 GMT, Afshin Zafari wrote: >> The JvmtiTagMap code adds/updates and removes the entries like below in two places which could probably be simplified, but I think that's outside the scope of this RFE. I suggest removing the bool return from add, remove and update, and add the assert(true) in the remove case. There's already an assert that add/update happened in the other cases. >> >> ``` // if the object is not already tagged then we tag it >> if (found_tag == 0) { >> if (tag != 0) { >> hashmap->add(o, tag); >> } else { >> // no-op >> } >> } else { >> // if the object is already tagged then we either update >> // the tag (if a new tag value has been provided) >> // or remove the object if the new tag value is 0. >> if (tag == 0) { >> hashmap->remove(o); >> } else { >> hashmap->update(o, tag); >> } >> } > > The methods of HashmapTable are void and have assert to verify the expected function (add/update/remove) is done. I'm still somewhat concerned about the use of this API and how it will behave in product mode, but okay ... ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Mon Jan 16 23:22:00 2023 From: duke at openjdk.org (Archie L. Cobbs) Date: Mon, 16 Jan 2023 23:22:00 GMT Subject: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v11] In-Reply-To: References: Message-ID: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_ > * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit) > * Some constructor `B()` of `B` invokes `A()` as its superclass constructor > * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly > > In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly. > > Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up. > > From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday. > > For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`. > > More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background. > > Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`. > > Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally. > > **Patch Navigation Guide** > > * Non-trivial compiler changes: > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties` > * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties` > > * Javadoc additions of `@implNote`: > > * `src/java.base/share/classes/java/io/PipedReader.java` > * `src/java.base/share/classes/java/io/PipedWriter.java` > * `src/java.base/share/classes/java/lang/Throwable.java` > * `src/java.base/share/classes/java/util/ArrayDeque.java` > * `src/java.base/share/classes/java/util/EnumMap.java` > * `src/java.base/share/classes/java/util/HashSet.java` > * `src/java.base/share/classes/java/util/Hashtable.java` > * `src/java.base/share/classes/java/util/LinkedList.java` > * `src/java.base/share/classes/java/util/TreeMap.java` > * `src/java.base/share/classes/java/util/TreeSet.java` > > * New unit tests > * `test/langtools/tools/javac/warnings/ThisEscape/*.java` > > * **Everything else** is just adding `@SuppressWarnings("this-escape")` Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision: - Remove unused type variable on method visitScoped(). - Remove expression type filtering; it doesn't seem to be needed. - Clean up unused import. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11874/files - new: https://git.openjdk.org/jdk/pull/11874/files/0b06dc32..a0b4310d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11874&range=09-10 Stats: 21 lines in 2 files changed: 0 ins; 20 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11874/head:pull/11874 PR: https://git.openjdk.org/jdk/pull/11874 From dholmes at openjdk.org Tue Jan 17 01:31:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 01:31:14 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Sat, 14 Jan 2023 19:01:52 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - correction for ppc > - missed update for debug mode > - more in src/hotspot > - typo correction > - 8299635: More test issues for deprecated sprintf in Xcode 14 src/hotspot/os/windows/os_windows.cpp line 387: > 385: os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s", > 386: Arguments::get_java_home(), EXT_DIR, > 387: path, PACKAGE_DIR, EXT_DIR); When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Tue Jan 17 01:39:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 01:39:14 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Sat, 14 Jan 2023 19:01:52 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - correction for ppc > - missed update for debug mode > - more in src/hotspot > - typo correction > - 8299635: More test issues for deprecated sprintf in Xcode 14 I would suggest constraining this PR to src/hotspot and test/hotspot and deal with the JDK serviceability files in a different PR (and there may be other JDK files impacted too). src/hotspot/share/utilities/globalDefinitions.hpp line 191: > 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror"); > 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r"); > 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); I have to wonder whether this actually works too. Perhaps @kbarrett can comment? ------------- PR: https://git.openjdk.org/jdk/pull/11935 From duke at openjdk.org Tue Jan 17 08:35:45 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 17 Jan 2023 08:35:45 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Fredrik Bredberg 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: - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 - Added references to JDK-8300197 - Updated some copyright dates. - Changed copyright date to 2023 - 8299795: Relativize locals in interpreter frames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11902/files - new: https://git.openjdk.org/jdk/pull/11902/files/ac821a10..98354c6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=02-03 Stats: 8598 lines in 696 files changed: 4531 ins; 1692 del; 2375 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 17 08:43:13 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 17 Jan 2023 08:43:13 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 15:14:34 GMT, Martin Doerr wrote: > Works on PPC64. Thanks! Tests have passed on other platforms as well. Does "other platforms" include S390? ------------- PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 17 09:00:17 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 17 Jan 2023 09:00:17 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg 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: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames Hi @bulasevich, can you verify that this PR works on Arm32? I've done sanity checking on Arm32 using Qemu, but nothing extensive. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From rehn at openjdk.org Tue Jan 17 10:04:16 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 17 Jan 2023 10:04:16 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg 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: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames Thank you, looks good! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 17 10:56:56 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 17 Jan 2023 10:56:56 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v11] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/b5a93bd5..64b19330 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=09-10 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From vsitnikov at openjdk.org Tue Jan 17 11:47:26 2023 From: vsitnikov at openjdk.org (Vladimir Sitnikov) Date: Tue, 17 Jan 2023 11:47:26 GMT Subject: RFR: 8298047: Remove all non-significant trailing whitespace from properties files [v2] In-Reply-To: References: Message-ID: On Mon, 16 Jan 2023 18:52:24 GMT, Magnus Ihse Bursie wrote: >> The non-client parts look fine. > > @RogerRiggs Thanks! @magicus , have you considered adding `.editorconfig` file (see https://editorconfig.org/ ) so it configures developers' editors to trim the whitespace? Of course, `.editorconfig` does not enforce the policy, however, it would make it easier for those who use editors that support `.editorconfig`. For instance, IntelliJ editors support it by default. ------------- PR: https://git.openjdk.org/jdk/pull/11491 From ihse at openjdk.org Tue Jan 17 12:17:25 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 17 Jan 2023 12:17:25 GMT Subject: RFR: 8298047: Remove all non-significant trailing whitespace from properties files [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 11:44:32 GMT, Vladimir Sitnikov wrote: >> @RogerRiggs Thanks! > > @magicus , have you considered adding `.editorconfig` file (see https://editorconfig.org/ ) so it configures developers' editors to trim the whitespace? > > Of course, `.editorconfig` does not enforce the policy, however, it would make it easier for those who use editors that support `.editorconfig`. For instance, IntelliJ editors support it by default. @vlsi That is an interesting suggestion. My experience with `.editorconfig` is that it is a bit so-so about getting it to actually describe the coding practices of a project, but it can probably be used for a thing like stripping trailing whitespace. I suggest we continue that discussion in ide-support-dev at openjdk.org, to figure out exactly what can be added to an `.editorconfig file`, how it interacts with jcheck rules and test how different IDEs behave. ------------- PR: https://git.openjdk.org/jdk/pull/11491 From duke at openjdk.org Tue Jan 17 13:23:51 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 17 Jan 2023 13:23:51 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v12] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/64b19330..d953b0bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From mdoerr at openjdk.org Tue Jan 17 13:36:18 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 17 Jan 2023 13:36:18 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:40:18 GMT, Fredrik Bredberg wrote: > > Works on PPC64. Thanks! Tests have passed on other platforms as well. > > Does "other platforms" include S390? No, @backwaterred you may want to check. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From mdoerr at openjdk.org Tue Jan 17 13:36:24 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 17 Jan 2023 13:36:24 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg 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: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 1035: > 1033: __ sub(R12_scratch2, R18_locals, R1_SP); > 1034: __ srdi(R12_scratch2, R12_scratch2, Interpreter::logStackElementSize); > 1035: // Now &fp()[R12_scratch2] == R18_locals I think this comment makes no sense. Please remove it. Otherwise, PPC64 code LGTM. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Tue Jan 17 17:04:49 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Tue, 17 Jan 2023 17:04:49 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> References: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> Message-ID: On Tue, 17 Jan 2023 13:32:47 GMT, Martin Doerr wrote: >> Fredrik Bredberg 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: >> >> - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 >> - Added references to JDK-8300197 >> - Updated some copyright dates. >> - Changed copyright date to 2023 >> - 8299795: Relativize locals in interpreter frames > > src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 1035: > >> 1033: __ sub(R12_scratch2, R18_locals, R1_SP); >> 1034: __ srdi(R12_scratch2, R12_scratch2, Interpreter::logStackElementSize); >> 1035: // Now &fp()[R12_scratch2] == R18_locals > > I think this comment makes no sense. Please remove it. Otherwise, PPC64 code LGTM. My intention was to show how the contents of R18_locals (the absolute address to locals) can be recreated by using R12_scratch2 as an index from the frame pointer. Before we stored R18_locals in the stackframe, now we store R12_scratch2. Does that make more sense? ------------- PR: https://git.openjdk.org/jdk/pull/11902 From aph at openjdk.org Tue Jan 17 17:37:20 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 17 Jan 2023 17:37:20 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg 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: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Please explain for the record the purpose of this patch. Neither the PR nor the Jira issue explain. I presume it's something to do with making the mounting and unmounting of interpreter frames easier, but this must be said somewhere. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From rkennke at openjdk.org Tue Jan 17 19:20:52 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 17 Jan 2023 19:20:52 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme Message-ID: This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal pro tocols. The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. This change enables to simplify (and speed-up!) a lot of code: - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR Testing: - [x] tier1 x86_64 x aarch64 x +UseFastLocking - [x] tier2 x86_64 x aarch64 x +UseFastLocking - [x] tier3 x86_64 x aarch64 x +UseFastLocking - [x] tier4 x86_64 x aarch64 x +UseFastLocking - [x] tier1 x86_64 x aarch64 x -UseFastLocking - [x] tier2 x86_64 x aarch64 x -UseFastLocking - [x] tier3 x86_64 x aarch64 x -UseFastLocking - [x] tier4 x86_64 x aarch64 x -UseFastLocking - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet ### Performance #### Renaissance ? | x86_64 | ? | ? | ? | aarch64 | ? | ? -- | -- | -- | -- | -- | -- | -- | -- ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% ------------- Commit messages: - Use testb when testing for anon owner in fast-path - Merge branch 'master' into JDK-8291555-v2 - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread - x86 part of optimization to check for anon owner - Optimize the check-for-anon-owner fast-path - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 - Fix method signature of build_frame() on ppc, arm and s390 - Remove unnecessary assert - Refactorings and cleanups (runtime) - Some refactorings (x86) - ... and 72 more: https://git.openjdk.org/jdk/compare/e7fa150b...c4746710 Changes: https://git.openjdk.org/jdk/pull/10907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291555 Stats: 1924 lines in 74 files changed: 1212 ins; 97 del; 615 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From fyang at openjdk.org Tue Jan 17 19:20:53 2023 From: fyang at openjdk.org (Fei Yang) Date: Tue, 17 Jan 2023 19:20:53 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Hi, I have also updated the riscv part from https://github.com/openjdk/jdk/pull/10590. Could you please put these changes in this PR? Thanks. I can run non-trivial benchmark workloads with +UseFastLocking on linux-riscv64 platform. I will try to perform more tests as needed. [10907-riscv-v1.txt](https://github.com/openjdk/jdk/files/10012199/10907-riscv-v1.txt) ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Tue Jan 17 19:20:53 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 17 Jan 2023 19:20:53 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > Hi, I have also updated the riscv part from #10590. Could you please put these changes in this PR? Thanks. I can run non-trivial benchmark workloads with +UseFastLocking on linux-riscv64 platform. I will try to perform more tests as needed. > > [10907-riscv-v1.txt](https://github.com/openjdk/jdk/files/10012199/10907-riscv-v1.txt) Thanks, Fei! I have pushed your changes. I will very likely need your help with this again later, I am currently working on some optimizations that should make fast-locking even better. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rehn at openjdk.org Tue Jan 17 19:20:55 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 17 Jan 2023 19:20:55 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% src/hotspot/share/runtime/objectMonitor.hpp line 274: > 272: > 273: bool is_owner_anonymous() const { > 274: return _owner == ANONYMOUS_OWNER; This should be `return owner_raw() == ANONYMOUS_OWNER;` test/hotspot/jtreg/compiler/floatingpoint/TestFloatSyncJNIArgs.java line 30: > 28: * > 29: * > 30: * @run main/othervm/native -XX:TieredStopAtLevel=1 compiler.floatingpoint.TestFloatSyncJNIArgs Is this related somehow? ------------- PR: https://git.openjdk.org/jdk/pull/10907 From dholmes at openjdk.org Tue Jan 17 19:20:56 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 17 Jan 2023 19:20:56 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: <3qWct3v1u9hKt7N8ZWTZfOAyeVfY-N9x6B2O9aMAR-Q=.76f9b404-7e30-4472-b5b5-f23563ff7958@github.com> On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% src/hotspot/share/runtime/thread.cpp line 77: > 75: > 76: Thread::Thread() : > 77: _lock_stack() { Surely only needed for `JavaThread`? ------------- PR: https://git.openjdk.org/jdk/pull/10907 From cjplummer at openjdk.org Tue Jan 17 20:53:23 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 17 Jan 2023 20:53:23 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Tue, 17 Jan 2023 01:28:08 GMT, David Holmes wrote: >> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - correction for ppc >> - missed update for debug mode >> - more in src/hotspot >> - typo correction >> - 8299635: More test issues for deprecated sprintf in Xcode 14 > > src/hotspot/os/windows/os_windows.cpp line 387: > >> 385: os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s", >> 386: Arguments::get_java_home(), EXT_DIR, >> 387: path, PACKAGE_DIR, EXT_DIR); > > When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`. I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From darcy at openjdk.org Wed Jan 18 00:45:31 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 18 Jan 2023 00:45:31 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management Message-ID: Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. ------------- Commit messages: - JDK-8300357: Use generalized see and link tags in java.management Changes: https://git.openjdk.org/jdk/pull/12058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300357 Stats: 11 lines in 3 files changed: 0 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12058.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12058/head:pull/12058 PR: https://git.openjdk.org/jdk/pull/12058 From dholmes at openjdk.org Wed Jan 18 02:24:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 18 Jan 2023 02:24:29 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v12] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:23:51 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11288 From mdoerr at openjdk.org Wed Jan 18 05:10:26 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 18 Jan 2023 05:10:26 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> Message-ID: <968FbsOPB5eLgb9XhRv7RrOvFqWz6XW55YAbEtl-c-s=.2a5ff2a1-2e9f-4775-b4b7-8d06aec19f19@github.com> On Tue, 17 Jan 2023 17:02:04 GMT, Fredrik Bredberg wrote: >> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 1035: >> >>> 1033: __ sub(R12_scratch2, R18_locals, R1_SP); >>> 1034: __ srdi(R12_scratch2, R12_scratch2, Interpreter::logStackElementSize); >>> 1035: // Now &fp()[R12_scratch2] == R18_locals >> >> I think this comment makes no sense. Please remove it. Otherwise, PPC64 code LGTM. > > My intention was to show how the contents of R18_locals (the absolute address to locals) can be recreated by using R12_scratch2 as an index from the frame pointer. Before we stored R18_locals in the stackframe, now we store R12_scratch2. Does that make more sense? The code uses &sp()[R12_scratch2]. I think your comment is confusing. Please remove it or write something comprehensive. E.g. save R18_locals in compressed format relative to the frame's SP. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From alanb at openjdk.org Wed Jan 18 07:35:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Jan 2023 07:35:23 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 00:37:05 GMT, Joe Darcy wrote: > Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 38: > 36: * typically mapped to kernel threads scheduled by the operating system. > 37: * {@code ThreadMXBean} does not support monitoring or management of > 38: * {@linkplain Thread##virtual-threads virtual threads}. The use of ## looks fine but would you mind re-flowing the javadoc in this paragraph as the line break after platform-threads looks accidental. This paragraph is mostly new text since Java 19. ------------- PR: https://git.openjdk.org/jdk/pull/12058 From duke at openjdk.org Wed Jan 18 09:48:29 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 18 Jan 2023 09:48:29 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 17:34:53 GMT, Andrew Haley wrote: > > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Please explain for the record the purpose of this patch. Neither the PR nor the Jira issue explain. I presume it's something to do with making the mounting and unmounting of interpreter frames easier, but this must be said somewhere. This PR implements JDK-8299795 which is a subtask to JDK-8289296, which briefly explains the reasons for the RFE. Anyhow I've added more information in JDK-8299795 regarding this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From aph at openjdk.org Wed Jan 18 10:16:33 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 18 Jan 2023 10:16:33 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg 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: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 236: > 234: caller.set_sp(fp + frame::sender_sp_offset); > 235: frame f(frame_sp, frame_sp, fp, hf.pc()); > 236: // we need to set the locals now so that the caller of new_stack_frame() can call Suggestion: // we need to set the locals so that the caller of new_stack_frame() can call ------------- PR: https://git.openjdk.org/jdk/pull/11902 From dfuchs at openjdk.org Wed Jan 18 12:34:28 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 18 Jan 2023 12:34:28 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 00:37:05 GMT, Joe Darcy wrote: > Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 140: > 138: * implementation may choose to find providers by other means. For > 139: * example, it may support {@linkplain > 140: * java.base/java.util.ServiceLoader##developing-service-providers service providers}, is `java.base/` needed here? I am a bit surprised - it's first time I see a module name used in a regular link target. src/java.management/share/classes/javax/management/remote/JMXConnectorServerFactory.java line 129: > 127: * MalformedURLException if there is none. An > 128: * implementation may choose to find providers by other means. For > 129: * example, it may support {@linkplain Same remark regarding `java.base/` prefix. ------------- PR: https://git.openjdk.org/jdk/pull/12058 From duke at openjdk.org Wed Jan 18 13:25:04 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 18 Jan 2023 13:25:04 GMT Subject: Integrated: 8292741: Convert JvmtiTagMapTable to ResourceHashtable In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 14:48:11 GMT, Afshin Zafari wrote: > test of tier1-5 passed. This pull request has now been integrated. Changeset: c464ef1d Author: Afshin Zafari Committer: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/c464ef1d61c2ea4a37759546f0ee39b1f530ccdc Stats: 291 lines in 4 files changed: 46 ins; 124 del; 121 mod 8292741: Convert JvmtiTagMapTable to ResourceHashtable Reviewed-by: dholmes, coleenp, rehn ------------- PR: https://git.openjdk.org/jdk/pull/11288 From rehn at openjdk.org Wed Jan 18 13:27:55 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 18 Jan 2023 13:27:55 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Hi Roman, I get this error on aarch64 in random tests: # Internal Error (.../open/src/hotspot/share/runtime/lockStack.cpp:50), pid=422380, tid=422437 # assert(*loc1 != *loc2) failed: entries must be unique: pre-contains V [libjvm.so+0x12a9f48] LockStack::validate(char const*) const+0x118 (lockStack.cpp:50) V [libjvm.so+0x17c5e60] is_lock_owned(Thread*, oop)+0x70 (lockStack.inline.hpp:72) V [libjvm.so+0x17cac8c] ObjectSynchronizer::inflate(Thread*, oop, ObjectSynchronizer::InflateCause)+0x6cc (synchronizer.cpp:1323) V [libjvm.so+0x17d0648] ObjectSynchronizer::enter(Handle, BasicLock*, JavaThread*)+0x108 (synchronizer.cpp:544) V [libjvm.so+0x16a23b8] SharedRuntime::monitor_enter_helper(oopDesc*, BasicLock*, JavaThread*)+0x1e8 (sharedRuntime.cpp:2294) V [libjvm.so+0x16a2724] SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, JavaThread*)+0xb4 (sharedRuntime.cpp:2301) Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~RuntimeStub::_complete_monitor_locking_Java 0x0000fffd30576414 J 9196 c2 java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry; java.base at 21-internal (39 bytes) @ 0x0000fffd3154715c [0x0000fffd31546a80+0x00000000000006dc] ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Wed Jan 18 14:13:47 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 14:13:47 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 13:25:22 GMT, Robbin Ehn wrote: > Hi Roman, I get this error on aarch64 in random tests: > ... Ok, that is ... surprising! I'll re-run tests on aarch64. Meanwhile, can you let me know what exactly you have run to get these failures? Thank you! Roman ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rehn at openjdk.org Wed Jan 18 15:01:44 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 18 Jan 2023 15:01:44 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 20:17:37 GMT, Roman Kennke wrote: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Here are some tests that seems provide some reproducability (mac/linux aarch64): runtime/handshake/HandshakeDirectTest.java vmTestbase/gc/gctests/ObjectMonitorCleanup/ObjectMonitorCleanup.java (crashes in AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 594020ul>::oop_access_barrier(void*)+0x1c) vmTestbase/nsk/jdi/stress/serial/heapwalking00X (options don't seem to matter) ------------- PR: https://git.openjdk.org/jdk/pull/10907 From pchilanomate at openjdk.org Wed Jan 18 15:36:56 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 18 Jan 2023 15:36:56 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: <6Nx7afJLt0AfEGcg5in2RWspQGMYuVWHNRaw3XpM9jA=.9dfe61aa-7d8b-4df0-b424-2383e794cb02@github.com> On Tue, 17 Jan 2023 08:35:45 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg 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: > > - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 > - Added references to JDK-8300197 > - Updated some copyright dates. > - Changed copyright date to 2023 > - 8299795: Relativize locals in interpreter frames Looks good to me, thanks! Patricio ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From rkennke at openjdk.org Wed Jan 18 15:45:38 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 15:45:38 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v2] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Properly set ZF on anon-check path; avoid some conditional branches ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/c4746710..a270919e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=00-01 Stats: 19 lines in 1 file changed: 12 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Wed Jan 18 15:48:14 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 15:48:14 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 14:57:33 GMT, Robbin Ehn wrote: > Here are some tests that seems provide some reproducability (mac/linux aarch64): runtime/handshake/HandshakeDirectTest.java vmTestbase/gc/gctests/ObjectMonitorCleanup/ObjectMonitorCleanup.java (crashes in AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 594020ul>::oop_access_barrier(void*)+0x1c) vmTestbase/nsk/jdi/stress/serial/heapwalking00X > > (options don't seem to matter) > > Well of course you need to turn it on. I was running with this applied: > > ``` > diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp > index f07a37b3d9f..c01c4f450a6 100644 > --- a/src/hotspot/share/runtime/globals.hpp > +++ b/src/hotspot/share/runtime/globals.hpp > @@ -1986 +1986 @@ const int ObjectAlignmentInBytes = 8; > - product(bool, UseFastLocking, false, EXPERIMENTAL, \ > + product(bool, UseFastLocking, true, EXPERIMENTAL, \ > ``` Thanks, Robbin! Turns out that this bug has been caused by one of the most recent commits: I used tnbz to branch to the exit of fast_unlock, but this doesn't set the ZF properly. I need to use regular tst & br instead. I pushed a fix, together with a number of minor improvements (avoid some conditional branches). Could you re-test? Thank you! Roman ------------- PR: https://git.openjdk.org/jdk/pull/10907 From duke at openjdk.org Wed Jan 18 15:49:16 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 18 Jan 2023 15:49:16 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: <968FbsOPB5eLgb9XhRv7RrOvFqWz6XW55YAbEtl-c-s=.2a5ff2a1-2e9f-4775-b4b7-8d06aec19f19@github.com> References: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> <968FbsOPB5eLgb9XhRv7RrOvFqWz6XW55YAbEtl-c-s=.2a5ff2a1-2e9f-4775-b4b7-8d06aec19f19@github.com> Message-ID: On Wed, 18 Jan 2023 05:07:38 GMT, Martin Doerr wrote: >> My intention was to show how the contents of R18_locals (the absolute address to locals) can be recreated by using R12_scratch2 as an index from the frame pointer. Before we stored R18_locals in the stackframe, now we store R12_scratch2. Does that make more sense? > > The code uses &sp()[R12_scratch2]. I think your comment is confusing. Please remove it or write something comprehensive. E.g. save R18_locals in compressed format relative to the new top frame's FP (= current SP). See what you mean, the R1_SP being the frame pointer is confusing. So how about changing the comment into: "// Store relativized R18_locals, see frame::interpreter_frame_locals()." Would that work for you? If not I'll just remove it. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From mdoerr at openjdk.org Wed Jan 18 16:01:16 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 18 Jan 2023 16:01:16 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: <3mWF3cL69YLzYwYI7z0nQB66c_JxuTUMPfTHVn_YjiQ=.00a62b19-8dd8-42ba-9d71-078cf21f2657@github.com> <968FbsOPB5eLgb9XhRv7RrOvFqWz6XW55YAbEtl-c-s=.2a5ff2a1-2e9f-4775-b4b7-8d06aec19f19@github.com> Message-ID: On Wed, 18 Jan 2023 15:46:22 GMT, Fredrik Bredberg wrote: >> The code uses &sp()[R12_scratch2]. I think your comment is confusing. Please remove it or write something comprehensive. E.g. save R18_locals in compressed format relative to the new top frame's FP (= current SP). > > See what you mean, the R1_SP being the frame pointer is confusing. So how about changing the comment into: > "// Store relativized R18_locals, see frame::interpreter_frame_locals()." > Would that work for you? If not I'll just remove it. That's fine. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11902 From rehn at openjdk.org Wed Jan 18 17:55:16 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 18 Jan 2023 17:55:16 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 15:45:38 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Properly set ZF on anon-check path; avoid some conditional branches So far so good. If this passes I'll do some stressing. This one fails runtime/logging/MonitorInflationTest.java missing an output. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From kevinw at openjdk.org Wed Jan 18 17:56:43 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 18 Jan 2023 17:56:43 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: References: Message-ID: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> > The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. > javax.management.Attribute and AttributeList classes are also needed, and Query related classes. > > There are a number of Query-relate classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - filter properties update: more classes logged as ALLOWED during wider testing - Add a Notification test ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/97/files - new: https://git.openjdk.org/jdk20/pull/97/files/96cc5120..ab81891d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=00-01 Stats: 51 lines in 2 files changed: 48 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk20/pull/97.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/97/head:pull/97 PR: https://git.openjdk.org/jdk20/pull/97 From dfuchs at openjdk.org Wed Jan 18 18:00:24 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 18 Jan 2023 18:00:24 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> References: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> Message-ID: <4qEii_mc0E2BmzUeVjIjU8vNyr0LkYF9JaFerx8XpL0=.3c7f16b3-4d9d-4c62-a0b5-f4f70d32364c@github.com> On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls wrote: >> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. >> javax.management.Attribute and AttributeList classes are also needed, and Query related classes. >> >> There are a number of Query-relate classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - filter properties update: more classes logged as ALLOWED during wider testing > - Add a Notification test Thanks for adding the new testcases, especially WRT to notifications. Your filter might be a little wider than strictly required but it looks like a good first step, and is obviously better than no filter. I am approving on the condition that all JMX (and JCK?) tests are stable passing. Please obtain approval from a maintainer of this area before pushing. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk20/pull/97 From rkennke at openjdk.org Wed Jan 18 18:29:40 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 18:29:40 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v3] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Change log message inflate(locked) -> inflate(has_locker) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/a270919e..c35e5a34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Wed Jan 18 18:29:41 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 18:29:41 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 17:52:24 GMT, Robbin Ehn wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Properly set ZF on anon-check path; avoid some conditional branches > > So far so good. If this passes I'll do some stressing. > > This one fails runtime/logging/MonitorInflationTest.java missing an output. @robehn how have you found this? This apparently slipped my testing because the test requires vm.flagless, but I would run it with TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseFastLocking". I have changed the log message from inflate(locked) to inflate(has_locker) so that it matches the current stack-locking output. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From darcy at openjdk.org Wed Jan 18 18:50:18 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 18 Jan 2023 18:50:18 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management In-Reply-To: References: Message-ID: <3iS2nLKofrtSuEKFxOv0uqD1zgvBxt0Ic7eYlYhf22c=.f929507e-a853-4df5-8057-ef794922aed7@github.com> On Wed, 18 Jan 2023 07:32:15 GMT, Alan Bateman wrote: >> Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. > > src/java.management/share/classes/java/lang/management/ThreadMXBean.java line 38: > >> 36: * typically mapped to kernel threads scheduled by the operating system. >> 37: * {@code ThreadMXBean} does not support monitoring or management of >> 38: * {@linkplain Thread##virtual-threads virtual threads}. > > The use of ## looks fine but would you mind re-flowing the javadoc in this paragraph as the line break after platform-threads looks accidental. This paragraph is mostly new text since Java 19. Sure; I opted to not re-flow the paragraphs in the initial review to make seeing the diffs easier. ------------- PR: https://git.openjdk.org/jdk/pull/12058 From darcy at openjdk.org Wed Jan 18 18:59:33 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 18 Jan 2023 18:59:33 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management [v2] In-Reply-To: References: Message-ID: > Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Reflow paragraph per review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12058/files - new: https://git.openjdk.org/jdk/pull/12058/files/5813eb1c..01ac3743 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12058&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12058&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12058.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12058/head:pull/12058 PR: https://git.openjdk.org/jdk/pull/12058 From alanb at openjdk.org Wed Jan 18 19:05:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Jan 2023 19:05:16 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:59:33 GMT, Joe Darcy wrote: >> Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Reflow paragraph per review feedback. Thanks for the update, looks okay to me. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12058 From darcy at openjdk.org Wed Jan 18 19:13:41 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 18 Jan 2023 19:13:41 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management [v3] In-Reply-To: References: Message-ID: <4wkDOoPPtJFhkn40G6oqBeiRgzXqyHC-wmXIp111fTQ=.142eff3d-4962-4143-90c3-3a7ae041297a@github.com> > Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve link target per code review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12058/files - new: https://git.openjdk.org/jdk/pull/12058/files/01ac3743..f8c64422 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12058&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12058&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12058.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12058/head:pull/12058 PR: https://git.openjdk.org/jdk/pull/12058 From darcy at openjdk.org Wed Jan 18 19:13:44 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 18 Jan 2023 19:13:44 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management [v3] In-Reply-To: References: Message-ID: <0fZw04264nxTHhG3oV7FCqjR1BOq0C3zOf0zVUyUQOQ=.9b6aa686-516c-4fd1-8876-9ef4f101b2d4@github.com> On Wed, 18 Jan 2023 12:22:01 GMT, Daniel Fuchs wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve link target per code review comments. > > src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 140: > >> 138: * implementation may choose to find providers by other means. For >> 139: * example, it may support {@linkplain >> 140: * java.base/java.util.ServiceLoader##developing-service-providers service providers}, > > is `java.base/` needed here? I am a bit surprised - it's first time I see a module name used in a regular link target. Updated. > src/java.management/share/classes/javax/management/remote/JMXConnectorServerFactory.java line 129: > >> 127: * MalformedURLException if there is none. An >> 128: * implementation may choose to find providers by other means. For >> 129: * example, it may support {@linkplain > > Same remark regarding `java.base/` prefix. For the connector server factory, "java.util" is still needed in the link since I didn't want to change the import statements of the class. ------------- PR: https://git.openjdk.org/jdk/pull/12058 From xuelei at openjdk.org Wed Jan 18 19:34:46 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 19:34:46 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Tue, 17 Jan 2023 20:50:26 GMT, Chris Plummer wrote: >> src/hotspot/os/windows/os_windows.cpp line 387: >> >>> 385: os::snprintf_checked(buf, sizeof(buf), "%s%s;%s%s%s", >>> 386: Arguments::get_java_home(), EXT_DIR, >>> 387: path, PACKAGE_DIR, EXT_DIR); >> >> When the call is split across multiple lines like this, the subsequent lines should align with the first parameter i.e. align under `buf`. > > I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok. I can see both styles are used in this file. The current code here uses 8 whitespaces indent, I would like to keep it. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 18 19:34:55 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 19:34:55 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com> On Tue, 17 Jan 2023 01:34:49 GMT, David Holmes wrote: >> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - correction for ppc >> - missed update for debug mode >> - more in src/hotspot >> - typo correction >> - 8299635: More test issues for deprecated sprintf in Xcode 14 > > src/hotspot/share/utilities/globalDefinitions.hpp line 191: > >> 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror"); >> 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r"); >> 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); > > I have to wonder whether this actually works too. Perhaps @kbarrett can comment? I am not confident with it. Maybe it is better to remove this change and consider it later. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 18 19:41:11 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 19:41:11 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v6] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in hotspot iml and test cases. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: Remove FORBID_C_FUNCTION update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/143887e9..99d5c611 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 18 19:41:12 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 19:41:12 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Tue, 17 Jan 2023 01:36:43 GMT, David Holmes wrote: > I would suggest constraining this PR to src/hotspot and test/hotspot and deal with the JDK serviceability files in a different PR (and there may be other JDK files impacted too). I agreed. This PR is mainly focus on the hotspot, except two test files for jdk management. The test clean up is done with this PR, but there are still a lot (57+) use in other src component. One or more PR will be filed for the remaining clean up. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From cjplummer at openjdk.org Wed Jan 18 19:48:18 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 18 Jan 2023 19:48:18 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com> On Wed, 18 Jan 2023 19:28:42 GMT, Xue-Lei Andrew Fan wrote: >> I think the other acceptable approach is to put the first argument on the 2nd line, and then indent all the argument lines by 8. That works well if the first argument would otherwise start too far to the right. For the above, I think either approach would look ok. > > I can see both styles are used in this file. The current code here uses 8 whitespaces indent, I would like to keep it. I scanned the first 1000 lines and saw many cases of multi-line argument passing, and they all indent as David suggested. I'm not saying there are non in the file that indent has you have, but it seems if there are cases, they are the exception. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From dfuchs at openjdk.org Wed Jan 18 19:58:33 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 18 Jan 2023 19:58:33 GMT Subject: RFR: JDK-8300357: Use generalized see and link tags in java.management [v3] In-Reply-To: <4wkDOoPPtJFhkn40G6oqBeiRgzXqyHC-wmXIp111fTQ=.142eff3d-4962-4143-90c3-3a7ae041297a@github.com> References: <4wkDOoPPtJFhkn40G6oqBeiRgzXqyHC-wmXIp111fTQ=.142eff3d-4962-4143-90c3-3a7ae041297a@github.com> Message-ID: On Wed, 18 Jan 2023 19:13:41 GMT, Joe Darcy wrote: >> Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Improve link target per code review comments. LGTM now. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/12058 From rkennke at openjdk.org Wed Jan 18 20:10:21 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 18 Jan 2023 20:10:21 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Revert UseFastLocking to default to off ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/c35e5a34..4504c1ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From darcy at openjdk.org Wed Jan 18 20:12:35 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 18 Jan 2023 20:12:35 GMT Subject: Integrated: JDK-8300357: Use generalized see and link tags in java.management In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 00:37:05 GMT, Joe Darcy wrote: > Use new javadoc capabilities courtesy JDK-8200337 to have more-readable-in-javadoc-source links to anchors in several management types. Analogous change is out for review in core libs, JDK-8300133. This pull request has now been integrated. Changeset: 5473e8a1 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/5473e8a1c616a7004f4a154e235c5344b559104c Stats: 13 lines in 3 files changed: 0 ins; 1 del; 12 mod 8300357: Use generalized see and link tags in java.management Reviewed-by: alanb, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/12058 From xuelei at openjdk.org Wed Jan 18 20:07:31 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 20:07:31 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v7] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in hotspot iml and test cases. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: align splited lines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/99d5c611..62589ae5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 18 20:07:35 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 18 Jan 2023 20:07:35 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com> References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> <5RjH-SG_Tv8lcUfEwfnAx1LzLThe3Kl__Vv_O6W5sz4=.f9128d51-3bcf-4adb-9097-32c312d045ce@github.com> Message-ID: <29kkAIFV45-0r65aIMq0TnkQcfNE8q8tlvswoTmzv7k=.b35606a8-bb9e-4ba1-a419-a5f1c2dcbc62@github.com> On Wed, 18 Jan 2023 19:45:55 GMT, Chris Plummer wrote: >> I can see both styles are used in this file. The current code here uses 8 whitespaces indent, I would like to keep it. > > I scanned the first 1000 lines and saw many cases of multi-line argument passing, and they all indent as David suggested. I'm not saying there are non in the file that indent has you have, but it seems if there are cases, they are the exception. OK. I have no strong preference. Updated to align with the 1st parameter. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From cjplummer at openjdk.org Wed Jan 18 20:15:48 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 18 Jan 2023 20:15:48 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads Message-ID: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal. ------------- Commit messages: - Fix thread memory leak Changes: https://git.openjdk.org/jdk/pull/12081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297638 Stats: 194 lines in 3 files changed: 192 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12081/head:pull/12081 PR: https://git.openjdk.org/jdk/pull/12081 From alanb at openjdk.org Wed Jan 18 20:33:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 18 Jan 2023 20:33:41 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads In-Reply-To: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> Message-ID: On Wed, 18 Jan 2023 20:06:33 GMT, Chris Plummer wrote: > Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal. Maybe you've tried this already but if listeners were changed to be a WeakHashMap then this would expunge the stable entries. This would also avoid the O(n) search in removeUnreachableListeners and simplify many other operations. But maybe you are concerned about preserving the insertion order of the listeners? ------------- PR: https://git.openjdk.org/jdk/pull/12081 From cjplummer at openjdk.org Wed Jan 18 21:34:26 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 18 Jan 2023 21:34:26 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads In-Reply-To: References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> Message-ID: On Wed, 18 Jan 2023 20:30:47 GMT, Alan Bateman wrote: > Maybe you've tried this already but if listeners were changed to be a WeakHashMap then this would expunge the stable entries. This would also avoid the O(n) search in removeUnreachableListeners and simplify many other operations. But maybe you are concerned about preserving the insertion order of the listeners? I did read your JBS comment with this suggestion and considered it, but decided to keep the changes simple and stick with something I knew was working and would not risk introducing other issues. I'm also not so sure it would help performance much: When running the test case, IIRC I would see the listeners grow to about 2500 before a GC would trigger about 2/3 of them being released in a batch. So w.r.t. `removeUnreachableListeners()`, I'm not too concerned about performance since it's iterating over the listeners is only triggered after a GC, and most are getting removed. It's not having to iterate over the list for each listener removed, but instead iterates once for each new batch of unreachable listeners. It looks like listeners are also removed with `iter.remove()` in `processVMAction()`. This is probably the more common path to removal when not creating the special situation in the debugger described in this CR. However, it will also remove a batch of listeners with one iteration over the list. I just noticed that that `removeListener()` is never called. I'll file an RFE to remove it. In any case, we don't need to worry about its performance. ------------- PR: https://git.openjdk.org/jdk/pull/12081 From jpai at openjdk.org Thu Jan 19 00:51:35 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 19 Jan 2023 00:51:35 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads In-Reply-To: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> Message-ID: <1Xe-14T_7MoS3Dg3NjVzb1FIbFsg3tmCajiNEDXGgns=.1512da77-ab5b-461e-9929-1ee952db6fd1@github.com> On Wed, 18 Jan 2023 20:06:33 GMT, Chris Plummer wrote: > Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal. src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java line 177: > 175: private void removeUnreachableListeners() { > 176: boolean found = false; > 177: while (listenersReferenceQueue.poll() != null) { Hello Chris, I have no prior knowledge of this code, so this is just a casual observation - should this change here be a `if` instead of a `while`? I see that this `removeUnreachableListeners()` gets called whenever a new listener is being added in `addListener(...)`. With the use of `while`, is this intentionally waiting for the GC to kick in and add at least one reference object to this queue? ------------- PR: https://git.openjdk.org/jdk/pull/12081 From cjplummer at openjdk.org Thu Jan 19 01:10:27 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 19 Jan 2023 01:10:27 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads In-Reply-To: <1Xe-14T_7MoS3Dg3NjVzb1FIbFsg3tmCajiNEDXGgns=.1512da77-ab5b-461e-9929-1ee952db6fd1@github.com> References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> <1Xe-14T_7MoS3Dg3NjVzb1FIbFsg3tmCajiNEDXGgns=.1512da77-ab5b-461e-9929-1ee952db6fd1@github.com> Message-ID: On Thu, 19 Jan 2023 00:46:22 GMT, Jaikiran Pai wrote: >> Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal. > > src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java line 177: > >> 175: private void removeUnreachableListeners() { >> 176: boolean found = false; >> 177: while (listenersReferenceQueue.poll() != null) { > > Hello Chris, I have no prior knowledge of this code, so this is just a casual observation - should this change here be a `if` instead of a `while`? I see that this `removeUnreachableListeners()` gets called whenever a new listener is being added in `addListener(...)`. With the use of `while`, is this intentionally waiting for the GC to kick in and add at least one reference object to this queue? No, because we have to clear the queue. This code could have been written as: boolean found = listenersReferenceQueue.poll(); while (listenersReferenceQueue.poll() != null); But you are partly right in that `removeUnreachableListeners()` doesn't really do anything until after a GC has triggered adding some objects to the queue. When there is one, there are probably a bunch, and they'll all get handled by the code below the above code. If there are none on the queue, then this method doesn't really do anything and has almost no overhead. ------------- PR: https://git.openjdk.org/jdk/pull/12081 From jpai at openjdk.org Thu Jan 19 01:16:29 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 19 Jan 2023 01:16:29 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads In-Reply-To: References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> <1Xe-14T_7MoS3Dg3NjVzb1FIbFsg3tmCajiNEDXGgns=.1512da77-ab5b-461e-9929-1ee952db6fd1@github.com> Message-ID: On Thu, 19 Jan 2023 01:04:39 GMT, Chris Plummer wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java line 177: >> >>> 175: private void removeUnreachableListeners() { >>> 176: boolean found = false; >>> 177: while (listenersReferenceQueue.poll() != null) { >> >> Hello Chris, I have no prior knowledge of this code, so this is just a casual observation - should this change here be a `if` instead of a `while`? I see that this `removeUnreachableListeners()` gets called whenever a new listener is being added in `addListener(...)`. With the use of `while`, is this intentionally waiting for the GC to kick in and add at least one reference object to this queue? > > No, because we have to clear the queue. This code could have been written as: > > boolean found = listenersReferenceQueue.poll(); > while (listenersReferenceQueue.poll() != null); > > But you are partly right in that `removeUnreachableListeners()` doesn't really do anything until after a GC has triggered adding some objects to the queue. When there is one, there are probably a bunch, and they'll all get handled by the code below the above code. If there are none on the queue, then this method doesn't really do anything and has almost no overhead. Thank you for that explanation Chris. What you state makes sense. I originally misread that while construct. ------------- PR: https://git.openjdk.org/jdk/pull/12081 From dholmes at openjdk.org Thu Jan 19 07:13:30 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 07:13:30 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:25:15 GMT, Roman Kennke wrote: > This apparently slipped my testing because the test requires vm.flagless, but I would run it with TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseFastLocking". You need to test this by having it enabled by default, otherwise you may miss many tests that either won't run (flagless) or won't pass the flags through to any exec'd VMs. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From dholmes at openjdk.org Thu Jan 19 07:34:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 07:34:31 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v6] In-Reply-To: References: Message-ID: <83nPGVU0MkRtftZHs_NJN_5ZOzPb6lrWUyzTdZCkRNw=.e122aa01-d981-4d9e-bb23-65aa9670ebf1@github.com> On Wed, 18 Jan 2023 19:41:11 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > Remove FORBID_C_FUNCTION update src/hotspot/share/utilities/globalDefinitions.hpp line 191: > 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror"); > 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r"); > 191: FORBID_C_FUNCTION(int vsprintf(char*, const char*, va_list), "use os::vsnprintf"); At some point we would want this and as this should be the last PR to touch hotspot code in this area then this seems like the right PR to have it in. We just need to check that it is actually working as expected. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Thu Jan 19 07:37:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 07:37:28 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> Message-ID: On Wed, 18 Jan 2023 19:35:08 GMT, Xue-Lei Andrew Fan wrote: > This PR is mainly focus on the hotspot, except two test files for jdk management. I would suggest leaving those two management files for the serviceability PR. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From rehn at openjdk.org Thu Jan 19 08:24:03 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 19 Jan 2023 08:24:03 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:10:21 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert UseFastLocking to default to off I always change the flags in code for the reasons David state and I can't forget to add any flags. (Test batch is stilling running, no failures except MonitorInflationTest.java) ------------- PR: https://git.openjdk.org/jdk/pull/10907 From duke at openjdk.org Thu Jan 19 09:13:42 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Thu, 19 Jan 2023 09:13:42 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v5] In-Reply-To: References: Message-ID: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Updated after review. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11902/files - new: https://git.openjdk.org/jdk/pull/11902/files/98354c6e..3f2a8bdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11902&range=03-04 Stats: 12 lines in 9 files changed: 0 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11902.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11902/head:pull/11902 PR: https://git.openjdk.org/jdk/pull/11902 From duke at openjdk.org Thu Jan 19 09:37:44 2023 From: duke at openjdk.org (Amit Kumar) Date: Thu, 19 Jan 2023 09:37:44 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:33:34 GMT, Martin Doerr wrote: >>> Works on PPC64. Thanks! Tests have passed on other platforms as well. >> >> Does "other platforms" include S390? > >> > Works on PPC64. Thanks! Tests have passed on other platforms as well. >> >> Does "other platforms" include S390? > > No, @backwaterred you may want to check. Hi @TheRealMDoerr and @fbredber , I've executed tier1 & tier2 test on slow, fast and release build on s390 and test-result seems fine. But please let me know if any specific tier I need to test. I would happily do it. ------------- PR: https://git.openjdk.org/jdk/pull/11902 From rkennke at openjdk.org Thu Jan 19 12:11:48 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 19 Jan 2023 12:11:48 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 08:19:54 GMT, Robbin Ehn wrote: > I always change the flags in code for the reasons David state and I can't forget to add any flags. > > (Test batch is stilling running, no failures except MonitorInflationTest.java) Ok, right. I just re-ran tier1-3 with the flag changed in code, on aarch64 and x86_64 without regressions. Will run tier4 overnight. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From duke at openjdk.org Thu Jan 19 13:26:15 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Thu, 19 Jan 2023 13:26:15 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 13:33:34 GMT, Martin Doerr wrote: >>> Works on PPC64. Thanks! Tests have passed on other platforms as well. >> >> Does "other platforms" include S390? > >> > Works on PPC64. Thanks! Tests have passed on other platforms as well. >> >> Does "other platforms" include S390? > > No, @backwaterred you may want to check. > Hi @TheRealMDoerr and @fbredber , I've executed tier1 & tier2 test on slow, fast and release build on s390 and test-result seems fine. But please let me know if any specific tier I need to test. I would happily do it. Since I haven't done any major change in s390, I think it's good enough to know that it passes tier1-tier2. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11902 From jdowland at openjdk.org Thu Jan 19 13:29:48 2023 From: jdowland at openjdk.org (Jonathan Dowland) Date: Thu, 19 Jan 2023 13:29:48 GMT Subject: Integrated: 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems In-Reply-To: References: Message-ID: <018boAck_yCHnlWwBwPifsE4Od4q2l0bGoRWMfSF9I8=.31f266d4-2430-4316-9708-23c1ce87228f@github.com> On Wed, 18 Jan 2023 13:20:06 GMT, Jonathan Dowland wrote: > This is a fix for https://bugs.openjdk.org/browse/JDK-8300119 (CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems). Thanks to @jerboaa Severin Gehwolf for figuring out the solution. > > The problem is demonstrated by test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java which fails on 32-bit x86 in HEAD, and passes after applying this patch. > > I tested this on an amd64 system with a cross-compiled JDK. I needed to override the default docker container for the test, to get one with a 32-bit userland. (the precise choice was also dictated by ABI matching my main development machine): > > > $JT_HOME/bin/jtreg -v -Djdk.test.docker.retain.image=true -Djdk.test.docker.image.name=i386/debian -Djdk.test.docker.image.version=testing-slim -jdk:$JAVA_HOME test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java This pull request has now been integrated. Changeset: dea58efb Author: Jonathan Dowland Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/dea58efb6280bb1d94daf208ac909aa013439397 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/12069 From jcking at openjdk.org Thu Jan 19 17:23:19 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 19 Jan 2023 17:23:19 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v10] In-Reply-To: References: Message-ID: <1tLJ8wDSBDX9Zq3UYPG8ssYO2-FH2QrErn8DF4X6f9o=.7ce4c592-f973-41c1-9ce2-8acd3f5ed6e7@github.com> > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. Justin King has updated the pull request incrementally with one additional commit since the last revision: Do not pass nullptr to os::release_memory Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11931/files - new: https://git.openjdk.org/jdk/pull/11931/files/4b5ce84b..de7d3ab6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11931&range=08-09 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11931.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11931/head:pull/11931 PR: https://git.openjdk.org/jdk/pull/11931 From sgehwolf at openjdk.org Thu Jan 19 17:24:57 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 19 Jan 2023 17:24:57 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: > Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. > > *Testing* > - [x] Container tests on Linux x86_64 cgv1 and cgv2 > - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 > - [ ] GHA in progress > > Thoughts? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values ------------- Changes: https://git.openjdk.org/jdk/pull/12097/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=01 Stats: 44 lines in 3 files changed: 27 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/12097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12097/head:pull/12097 PR: https://git.openjdk.org/jdk/pull/12097 From jcking at openjdk.org Thu Jan 19 17:44:24 2023 From: jcking at openjdk.org (Justin King) Date: Thu, 19 Jan 2023 17:44:24 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v7] In-Reply-To: References: Message-ID: <6YyCx_tBArtnIrd5KMSoDN5EbeaUiqP0ndX_UgUmhzk=.8f727199-8b3b-48e0-a01e-a34c00889c32@github.com> On Thu, 12 Jan 2023 07:32:24 GMT, Stefan Karlsson wrote: > There's a FIXME about that allocation.inline.hpp file is now empty. Will you remove it in this patch? I'd prefer if you did. Alternatively, remove the FIXME from this patch and then immediately clean this up as a separate patch. Yeah, separate patch immediately after is probably best. Trying to avoid having to mass update includes and enter merge conflict hell for this patch. After is easier. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From xuelei at openjdk.org Thu Jan 19 18:54:08 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 19 Jan 2023 18:54:08 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in hotspot iml and test cases. Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: - remove serviceability update and add back forbid of sprintf - remove serviceability update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11935/files - new: https://git.openjdk.org/jdk/pull/11935/files/62589ae5..ec0bb486 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11935&range=06-07 Stats: 9 lines in 3 files changed: 1 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11935.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11935/head:pull/11935 PR: https://git.openjdk.org/jdk/pull/11935 From mikael at openjdk.org Thu Jan 19 21:10:11 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 19 Jan 2023 21:10:11 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: > > - remove serviceability update and add back forbid of sprintf > - remove serviceability update I was (still) puzzled by the remaining sprintf:s in the JDK and the fact that the build completed successfully even if not all of them had been address/updated, so I investigated it a bit and came to the conclusion that the Xcode/clang warning (which we turn into an error with `-Werror`) only seems to be generated for C++ files, not for C files. For many reasons we may still want to fix the remaining occurrences as well, but for the immediate case of the new Xcode version it seems to be sufficient to fix the C++ files. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From jsjolen at openjdk.org Thu Jan 19 21:11:50 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 21:11:50 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ Message-ID: Do the conversion in the share/jfr/ sub-directory and all of its files. ------------- Commit messages: - More manual fixes - Merge remote-tracking branch 'origin/master' into JDK-8300245 - Manual fixes - Replace NULL with nullptr in share/jfr/ Changes: https://git.openjdk.org/jdk/pull/12034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300245 Stats: 2079 lines in 126 files changed: 0 ins; 0 del; 2079 mod Patch: https://git.openjdk.org/jdk/pull/12034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12034/head:pull/12034 PR: https://git.openjdk.org/jdk/pull/12034 From jsjolen at openjdk.org Thu Jan 19 21:12:17 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 19 Jan 2023 21:12:17 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 11:26:12 GMT, Johan Sj?len wrote: > Do the conversion in the share/jfr/ sub-directory and all of its files. More manual fixes! Fixed the review comments I found, opening this for review. src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1157: > 1155: const int orig_stream_length = orig_stream->length(); > 1156: // allocate an identically sized buffer > 1157: u1* const new_buffer = NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_nullptr(THREAD, u1, orig_stream_length); fix src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1319: > 1317: // to be used in building up a modified class [B. > 1318: const jint new_buffer_size = extra_stream_bytes + orig_stream_size; > 1319: u1* const new_buffer = NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_nullptr(THREAD, u1, new_buffer_size); fix src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1558: > 1556: const jint stream_len = new_stream->length(); > 1557: JvmtiCachedClassFileData* p = > 1558: (JvmtiCachedClassFileData*)NEW_C_HEAP_ARRAY_RETURN_nullptr(u1, offset_of(JvmtiCachedClassFileData, data) + stream_len, mtInternal); fix src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 102: > 100: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(THREAD)); > 101: ThreadInVMfromNative tvmfn(THREAD); > 102: jclass* const classes = NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_nullptr(THREAD, jclass, classes_count); fix src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 97: > 95: jio_snprintf(pid_buf, sizeof(pid_buf), "%d", os::current_process_id()); > 96: jstring pid_string = env->NewStringUTF(pid_buf); > 97: return pid_string; // exception pending if nullptr fix src/hotspot/share/jfr/jni/jfrUpcalls.cpp line 144: > 142: assert(new_byte_array != nullptr, "invariant"); > 143: assert(new_bytes_length > 0, "invariant"); > 144: unsigned char* const new_bytes = NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_nullptr(THREAD, unsigned char, new_bytes_length); fix src/hotspot/share/jfr/jni/jfrUpcalls.cpp line 182: > 180: assert(new_byte_array != nullptr, "invariant"); > 181: assert(new_bytes_length > 0, "invariant"); > 182: unsigned char* const new_bytes = NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_nullptr(THREAD, unsigned char, new_bytes_length); fix src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp line 156: > 154: // might represent a primitive > 155: const Klass* const ak = java_lang_Class::array_klass_acquire(_object); > 156: // If ak is nullptr, this is most likely a mirror associated with a fix src/hotspot/share/jfr/periodic/jfrOSInterface.cpp line 191: > 189: > 190: int JfrOSInterface::JfrOSInterfaceImpl::system_processes(SystemProcess** system_processes, int* no_of_sys_processes) { > 191: assert(system_processes != nullptr, "system_processes pointer is nullptr!"); fix src/hotspot/share/jfr/periodic/jfrOSInterface.cpp line 205: > 203: // caller need to ensure proper ResourceMark placement. > 204: int JfrOSInterface::JfrOSInterfaceImpl::os_version(char** os_version) const { > 205: assert(os_version != nullptr, "os_version pointer is nullptr!"); fix src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 588: > 586: ThreadsListHandle tlh; > 587: // Resolve a sample session relative start position index into the thread list array. > 588: // In cases where the last sampled thread is nullptr or not-nullptr but stale, find_index() returns -1. fix src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp line 97: > 95: > 96: bool JfrRepository::set_path(const char* path) { > 97: assert(path != nullptr, "trying to set the repository path with a nullptr string!"); fix src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp line 147: > 145: const char* const canonical_chunk_path = JfrJavaSupport::c_str(path, jt); > 146: if (nullptr == canonical_chunk_path && !_chunkwriter->is_valid()) { > 147: // new output is nullptr and current output is nullptr fix src/hotspot/share/jfr/recorder/service/jfrMemorySizer.cpp line 364: > 362: // Unordered selection: > 363: // > 364: // C(4, 0) = {} = nullptr set = 1 fix src/hotspot/share/jfr/utilities/jfrAllocation.cpp line 127: > 125: > 126: char* JfrCHeapObj::realloc_array(char* old, size_t size) { > 127: char* const memory = ReallocateHeap(old, size, mtTracing, AllocFailStrategy::RETURN_nullptr); fix src/hotspot/share/jfr/utilities/jfrAllocation.cpp line 138: > 136: > 137: char* JfrCHeapObj::allocate_array_noinline(size_t elements, size_t element_size) { > 138: return AllocateHeap(elements * element_size, mtTracing, CALLER_PC, AllocFailStrategy::RETURN_nullptr); fix src/hotspot/share/jfr/utilities/jfrAllocation.hpp line 41: > 39: * tear down the VM she is about to inspect as a side effect. > 40: * > 41: * This allocator uses the RETURN_nullptr capabilities fix src/hotspot/share/jfr/writers/jfrEncoding.hpp line 33: > 31: > 32: enum JfrStringEncoding { > 33: nullptr_STRING = 0, fix src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp line 95: > 93: void WriterHost::write_utf8(const char* value) { > 94: if (nullptr == value) { > 95: // only write encoding byte indicating nullptr string fix ------------- PR: https://git.openjdk.org/jdk/pull/12034 From cjplummer at openjdk.org Thu Jan 19 21:59:22 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 19 Jan 2023 21:59:22 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads [v2] In-Reply-To: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> Message-ID: <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com> > Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Cleaned up removeUnreachableListeners(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12081/files - new: https://git.openjdk.org/jdk/pull/12081/files/894a33d6..f2acfacc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12081&range=00-01 Stats: 16 lines in 1 file changed: 5 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/12081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12081/head:pull/12081 PR: https://git.openjdk.org/jdk/pull/12081 From dholmes at openjdk.org Fri Jan 20 04:42:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 04:42:32 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: > > - remove serviceability update and add back forbid of sprintf > - remove serviceability update Nothing further from me. I think this is okay as-is now. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Fri Jan 20 04:42:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 04:42:34 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v5] In-Reply-To: <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com> References: <4LFtuPZ1ORE10ZZSFnAq2Tp462JlSjeyzQnLgRxlG1c=.4e5bbb19-63c8-4667-a1b2-90464fb74aa0@github.com> <1ClKpQgCeS1zWMqBwXYSR3Y0LzX_l2-uOHoy_lFDQuQ=.9fb3d52b-0421-4945-860b-e149e5c07a8c@github.com> Message-ID: On Wed, 18 Jan 2023 19:30:42 GMT, Xue-Lei Andrew Fan wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 191: >> >>> 189: FORBID_C_FUNCTION(char* strerror(int), "use os::strerror"); >>> 190: FORBID_C_FUNCTION(char* strtok(char*, const char*), "use strtok_r"); >>> 191: FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), "use os::snprintf"); >> >> I have to wonder whether this actually works too. Perhaps @kbarrett can comment? > > I am not confident with it. Maybe it is better to remove this change and consider it later. For the record I tested this standalone and it works fine in a C++ program. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From mdoerr at openjdk.org Fri Jan 20 04:59:31 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 20 Jan 2023 04:59:31 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v5] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 09:13:42 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated after review. Thanks! Your update and the PPC64 parts LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From fyang at openjdk.org Fri Jan 20 05:06:28 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 20 Jan 2023 05:06:28 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v5] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 09:13:42 GMT, Fredrik Bredberg wrote: >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. >> Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. >> Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Updated after review. The RISC-V specific changes looks good. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/11902 From rehn at openjdk.org Fri Jan 20 10:43:32 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 20 Jan 2023 10:43:32 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 17:34:53 GMT, Andrew Haley wrote: >> Fredrik Bredberg 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: >> >> - Merge branch 'master' into relativize-locals-JDK-8299795_2023-01-09 >> - Added references to JDK-8300197 >> - Updated some copyright dates. >> - Changed copyright date to 2023 >> - 8299795: Relativize locals in interpreter frames > >> Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. > > Please explain for the record the purpose of this patch. Neither the PR nor the Jira issue explain. I presume it's something to do with making the mounting and unmounting of interpreter frames easier, but this must be said somewhere. @theRealAph are you planning to provide additional feedback, or can it be shipped? ------------- PR: https://git.openjdk.org/jdk/pull/11902 From bulasevich at openjdk.org Fri Jan 20 11:02:28 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 20 Jan 2023 11:02:28 GMT Subject: RFR: 8299795: Relativize locals in interpreter frames [v4] In-Reply-To: References: Message-ID: <2Mijs6e9YpQ81_KD6W3aE9elAb30Tb343mnWuMNZSS8=.cf10dd9a-2907-4928-9004-a974264b58fe@github.com> On Tue, 17 Jan 2023 08:57:35 GMT, Fredrik Bredberg wrote: > Hi @bulasevich, can you verify that this PR works on Arm32? ARM32 part LGTM. Test results are fine. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11902 From sgehwolf at openjdk.org Fri Jan 20 12:59:26 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 20 Jan 2023 12:59:26 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote: >> Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. >> >> *Testing* >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 >> - [x] GHA in progress >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values GHA test failures seem unrelated. ------------- PR: https://git.openjdk.org/jdk/pull/12097 From mgronlun at openjdk.org Fri Jan 20 13:50:32 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 20 Jan 2023 13:50:32 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 20:44:33 GMT, Johan Sj?len wrote: >> Do the conversion in the share/jfr/ sub-directory and all of its files. > > src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1157: > >> 1155: const int orig_stream_length = orig_stream->length(); >> 1156: // allocate an identically sized buffer >> 1157: u1* const new_buffer = NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_nullptr(THREAD, u1, orig_stream_length); > > fix Propagating the term "nullptr" is weird when it is used conceptually, like for example in comments and macros. > src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1558: > >> 1556: const jint stream_len = new_stream->length(); >> 1557: JvmtiCachedClassFileData* p = >> 1558: (JvmtiCachedClassFileData*)NEW_C_HEAP_ARRAY_RETURN_nullptr(u1, offset_of(JvmtiCachedClassFileData, data) + stream_len, mtInternal); > > fix Not sure agree about the new macro. Why not in capitals, if it needs to be updated (which I am not sure it has)? > src/hotspot/share/jfr/writers/jfrEncoding.hpp line 33: > >> 31: >> 32: enum JfrStringEncoding { >> 33: nullptr_STRING = 0, > > fix This is a conceptual "NULL" more than a specific C++ nullptr. ------------- PR: https://git.openjdk.org/jdk/pull/12034 From sgehwolf at openjdk.org Fri Jan 20 16:06:13 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 20 Jan 2023 16:06:13 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote: >> Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. >> >> *Testing* >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 >> - [x] GHA in progress >> >> Thoughts? > > Severin Gehwolf 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 one additional commit since the last revision: > > 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values @MBaesken Hi! Could you please help review this as you've touched this area a bit? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/12097 From cjplummer at openjdk.org Fri Jan 20 16:52:18 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 20 Jan 2023 16:52:18 GMT Subject: RFR: 8300721: Cleanup ProblemList-svc-vthread.txt Message-ID: There are a number of entries in ProblemList-svc-vthread.txt that don't have any CRs associated with them. CRs have since been created and the problemlist needs to be updated to reflect this. Here are links to the relevant CRs: [JDK-8285414](https://bugs.openjdk.org/browse/JDK-8285414): [LOOM] Some nsk/jdi tests fail due to not expecting OPAQUE_FRAME from JVMTI PopFrame() [JDK-8300712](https://bugs.openjdk.org/browse/JDK-8300712): nsk/jvmti/scenarios/allocation/AP11/ap11t001 fails with the virtual thread wrapper [JDK-8300711](https://bugs.openjdk.org/browse/JDK-8300711): nsk/jvmti/CompiledMethodUnload/compmethunload001 fails with the virtual thread wrapper [JDK-8300709](https://bugs.openjdk.org/browse/JDK-8300709): nsk/jvmti/GetObjectMonitorUsage/objmonusage006 test asserts with virtual thread wrapper [JDK-8300708](https://bugs.openjdk.org/browse/JDK-8300708): some nsk jvmti tests fail with virtual thread wrapper due to missing jvmti missing some virtual thread support [JDK-8300707](https://bugs.openjdk.org/browse/JDK-8300707): jdb "list" and "repeat" tests fails with virtual thread wrapper Note the following two tests are covered by the pre-existing [JDK-8285414](https://bugs.openjdk.org/browse/JDK-8285414), and were move down to the section with other tests problemlisted under this CR: vmTestbase/nsk/jdb/pop_exception/pop_exception001/pop_exception001.java vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses002/TestDescription.java Also, the following test has been removed, so it is being removed from the problemlist: vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/TestDescription.java ------------- Commit messages: - update copyright - Updates for newly filed CRs. Changes: https://git.openjdk.org/jdk/pull/12109/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300721 Stats: 38 lines in 1 file changed: 4 ins; 12 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/12109.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12109/head:pull/12109 PR: https://git.openjdk.org/jdk/pull/12109 From alanb at openjdk.org Fri Jan 20 17:06:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 20 Jan 2023 17:06:00 GMT Subject: RFR: 8300721: Cleanup ProblemList-svc-vthread.txt In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 02:12:43 GMT, Chris Plummer wrote: > There are a number of entries in ProblemList-svc-vthread.txt that don't have any CRs associated with them. CRs have since been created and the problemlist needs to be updated to reflect this. Here are links to the relevant CRs: > > [JDK-8285414](https://bugs.openjdk.org/browse/JDK-8285414): [LOOM] Some nsk/jdi tests fail due to not expecting OPAQUE_FRAME from JVMTI PopFrame() > [JDK-8300712](https://bugs.openjdk.org/browse/JDK-8300712): nsk/jvmti/scenarios/allocation/AP11/ap11t001 fails with the virtual thread wrapper > [JDK-8300711](https://bugs.openjdk.org/browse/JDK-8300711): nsk/jvmti/CompiledMethodUnload/compmethunload001 fails with the virtual thread wrapper > [JDK-8300709](https://bugs.openjdk.org/browse/JDK-8300709): nsk/jvmti/GetObjectMonitorUsage/objmonusage006 test asserts with virtual thread wrapper > [JDK-8300708](https://bugs.openjdk.org/browse/JDK-8300708): some nsk jvmti tests fail with virtual thread wrapper due to missing jvmti missing some virtual thread support > [JDK-8300707](https://bugs.openjdk.org/browse/JDK-8300707): jdb "list" and "repeat" tests fails with virtual thread wrapper > > Note the following two tests are covered by the pre-existing [JDK-8285414](https://bugs.openjdk.org/browse/JDK-8285414), and were move down to the section with other tests problemlisted under this CR: > > > vmTestbase/nsk/jdb/pop_exception/pop_exception001/pop_exception001.java > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses002/TestDescription.java > > > Also, the following test has been removed, so it is being removed from the problemlist: > > > vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/TestDescription.java I sampled a few and they were linked to the right issue. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12109 From xuelei at openjdk.org Fri Jan 20 18:22:34 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 20 Jan 2023 18:22:34 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 In-Reply-To: References: <7NTMxoOgPK0vqq-XGKI350AKnIjnA8_OYKzZLhLMLOc=.cd43cc7d-eff3-4046-989a-98173ee98500@github.com> Message-ID: On Fri, 13 Jan 2023 08:00:55 GMT, Serguei Spitsyn wrote: >>> > I'm also curious: some of the sprintfs are C2 (src/hotspot/share/opto) - are your builds including C2? If so, why are you not running into the issue for those files? >>> >>> I'm new to hotspot. Do you know how could I enable C2? Thanks! >> >> Never mind, I got it from configuration help message (use --with-jvm-features=compiler2). > > @XueleiFan Could you, please, do not integrate until more cases with the same problem are fixed? @sspitsyn I'm going to integrate the changeset. Did you have further comment or need more time? ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Fri Jan 20 18:22:36 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 20 Jan 2023 18:22:36 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 04:39:13 GMT, David Holmes wrote: > Nothing further from me. I think this is okay as-is now. Thanks. @dholmes-ora Thank you for the review! ------------- PR: https://git.openjdk.org/jdk/pull/11935 From lmesnik at openjdk.org Fri Jan 20 19:37:14 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 20 Jan 2023 19:37:14 GMT Subject: RFR: 8300721: Cleanup ProblemList-svc-vthread.txt In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 02:12:43 GMT, Chris Plummer wrote: > There are a number of entries in ProblemList-svc-vthread.txt that don't have any CRs associated with them. CRs have since been created and the problemlist needs to be updated to reflect this. Here are links to the relevant CRs: > > [JDK-8285414](https://bugs.openjdk.org/browse/JDK-8285414): [LOOM] Some nsk/jdi tests fail due to not expecting OPAQUE_FRAME from JVMTI PopFrame() > [JDK-8300712](https://bugs.openjdk.org/browse/JDK-8300712): nsk/jvmti/scenarios/allocation/AP11/ap11t001 fails with the virtual thread wrapper > [JDK-8300711](https://bugs.openjdk.org/browse/JDK-8300711): nsk/jvmti/CompiledMethodUnload/compmethunload001 fails with the virtual thread wrapper > [JDK-8300709](https://bugs.openjdk.org/browse/JDK-8300709): nsk/jvmti/GetObjectMonitorUsage/objmonusage006 test asserts with virtual thread wrapper > [JDK-8300708](https://bugs.openjdk.org/browse/JDK-8300708): some nsk jvmti tests fail with virtual thread wrapper due to missing jvmti missing some virtual thread support > [JDK-8300707](https://bugs.openjdk.org/browse/JDK-8300707): jdb "list" and "repeat" tests fails with virtual thread wrapper > > Note the following two tests are covered by the pre-existing [JDK-8285414](https://bugs.openjdk.org/browse/JDK-8285414), and were move down to the section with other tests problemlisted under this CR: > > > vmTestbase/nsk/jdb/pop_exception/pop_exception001/pop_exception001.java > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses002/TestDescription.java > > > Also, the following test has been removed, so it is being removed from the problemlist: > > > vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/TestDescription.java Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12109 From cjplummer at openjdk.org Fri Jan 20 20:08:15 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 20 Jan 2023 20:08:15 GMT Subject: Integrated: 8300721: Cleanup ProblemList-svc-vthread.txt In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 02:12:43 GMT, Chris Plummer wrote: > There are a number of entries in ProblemList-svc-vthread.txt that don't have any CRs associated with them. CRs have since been created and the problemlist needs to be updated to reflect this. Here are links to the relevant CRs: > > [JDK-8285414](https://bugs.openjdk.org/browse/JDK-8285414): [LOOM] Some nsk/jdi tests fail due to not expecting OPAQUE_FRAME from JVMTI PopFrame() > [JDK-8300712](https://bugs.openjdk.org/browse/JDK-8300712): nsk/jvmti/scenarios/allocation/AP11/ap11t001 fails with the virtual thread wrapper > [JDK-8300711](https://bugs.openjdk.org/browse/JDK-8300711): nsk/jvmti/CompiledMethodUnload/compmethunload001 fails with the virtual thread wrapper > [JDK-8300709](https://bugs.openjdk.org/browse/JDK-8300709): nsk/jvmti/GetObjectMonitorUsage/objmonusage006 test asserts with virtual thread wrapper > [JDK-8300708](https://bugs.openjdk.org/browse/JDK-8300708): some nsk jvmti tests fail with virtual thread wrapper due to missing jvmti missing some virtual thread support > [JDK-8300707](https://bugs.openjdk.org/browse/JDK-8300707): jdb "list" and "repeat" tests fails with virtual thread wrapper > > Note the following two tests are covered by the pre-existing [JDK-8285414](https://bugs.openjdk.org/browse/JDK-8285414), and were move down to the section with other tests problemlisted under this CR: > > > vmTestbase/nsk/jdb/pop_exception/pop_exception001/pop_exception001.java > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses002/TestDescription.java > > > Also, the following test has been removed, so it is being removed from the problemlist: > > > vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/TestDescription.java This pull request has now been integrated. Changeset: 5784eb7b Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/5784eb7b68a880e130fda5f07c527187764038a2 Stats: 38 lines in 1 file changed: 4 ins; 12 del; 22 mod 8300721: Cleanup ProblemList-svc-vthread.txt Reviewed-by: alanb, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/12109 From tsteele at openjdk.org Fri Jan 20 23:16:05 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 20 Jan 2023 23:16:05 GMT Subject: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 18:10:47 GMT, Justin King wrote: > This leaves at least AIX as a potential problem. @backwaterred, does the AIX libc malloc() still exclusively use the data segment? Does free'd memory still stick to the process? I agree with @coleenp that AIX seems to still use the data segment and sbrk for dynamic memory allocation. I am not sure about memory sticking to the process. With these changes I see several of the gtests failing on AIX. [==========] 58 tests from 6 test cases ran. (3718 ms total) [ PASSED ] 53 tests. [ FAILED ] 5 tests, listed below: [ FAILED ] os.safefetchN_negative_vm [ FAILED ] os.safefetch32_negative_vm [ FAILED ] os.safefetchN_negative_current_null_vm [ FAILED ] os.safefetch32_negative_current_null_vm [ FAILED ] os.safefetch_negative_at_safepoint_vm I can experiment with the disclaim option as well. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From dholmes at openjdk.org Sun Jan 22 22:18:06 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 22 Jan 2023 22:18:06 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: <-dUevC7v-TgLD27ARVcoKTVMbxjBN5WAYxRjFqoNwxE=.0ebafba6-465d-48c9-b823-402c70a28d95@github.com> On Fri, 20 Jan 2023 18:20:10 GMT, Xue-Lei Andrew Fan wrote: >> Nothing further from me. I think this is okay as-is now. Thanks. > >> Nothing further from me. I think this is okay as-is now. Thanks. > > @dholmes-ora Thank you for the review! @XueleiFan You need two reviews before integrating a Hotspot change - thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11935 From dholmes at openjdk.org Mon Jan 23 03:24:47 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jan 2023 03:24:47 GMT Subject: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC Message-ID: There was one missing update in javac.1 from: [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac otherwise the change is limited to dropping the "-ea". Thanks. ------------- Commit messages: - Merge branch 'master' into 8290919-manpages - 8290919: Update nroff pages in JDK 20 before RC Changes: https://git.openjdk.org/jdk20/pull/112/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=112&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290919 Stats: 29 lines in 28 files changed: 1 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk20/pull/112.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/112/head:pull/112 PR: https://git.openjdk.org/jdk20/pull/112 From iris at openjdk.org Mon Jan 23 07:18:06 2023 From: iris at openjdk.org (Iris Clark) Date: Mon, 23 Jan 2023 07:18:06 GMT Subject: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes wrote: > There was one missing update in javac.1 from: > > [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac > > otherwise the change is limited to dropping the "-ea". > > Thanks. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/112 From alanb at openjdk.org Mon Jan 23 07:35:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 23 Jan 2023 07:35:07 GMT Subject: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes wrote: > There was one missing update in javac.1 from: > > [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac > > otherwise the change is limited to dropping the "-ea". > > Thanks. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/112 From dholmes at openjdk.org Mon Jan 23 07:39:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jan 2023 07:39:08 GMT Subject: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 07:15:08 GMT, Iris Clark wrote: >> There was one missing update in javac.1 from: >> >> [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac >> >> otherwise the change is limited to dropping the "-ea". >> >> Thanks. > > Marked as reviewed by iris (Reviewer). Thanks for the reviews @irisclark and @AlanBateman ! ------------- PR: https://git.openjdk.org/jdk20/pull/112 From dholmes at openjdk.org Mon Jan 23 07:53:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jan 2023 07:53:05 GMT Subject: [jdk20] Integrated: 8290919: Update nroff pages in JDK 20 before RC In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes wrote: > There was one missing update in javac.1 from: > > [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac > > otherwise the change is limited to dropping the "-ea". > > Thanks. This pull request has now been integrated. Changeset: fd752178 Author: David Holmes URL: https://git.openjdk.org/jdk20/commit/fd752178e364fb5deeec062bef3dde1fea1dcbe3 Stats: 29 lines in 28 files changed: 1 ins; 0 del; 28 mod 8290919: Update nroff pages in JDK 20 before RC Reviewed-by: iris, alanb ------------- PR: https://git.openjdk.org/jdk20/pull/112 From duke at openjdk.org Mon Jan 23 10:53:13 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Mon, 23 Jan 2023 10:53:13 GMT Subject: Integrated: 8299795: Relativize locals in interpreter frames In-Reply-To: References: Message-ID: On Mon, 9 Jan 2023 10:30:06 GMT, Fredrik Bredberg wrote: > Implementation of relativized locals in interpreter frames for x86. x64, arm, aarch64, ppc64le and riscv. > Not relativized locals on zero and s390 but done some changes to cope with the changed generic code. > Tested tier1-tier8 on supported platforms. The rest was sanity tested using Qemu, except s390, which was only tested by GitHub Actions. This pull request has now been integrated. Changeset: f307e8c6 Author: Fredrik Bredberg Committer: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/f307e8c667895c302e916124751456a5443353ce Stats: 224 lines in 40 files changed: 105 ins; 17 del; 102 mod 8299795: Relativize locals in interpreter frames Reviewed-by: coleenp, rehn, pchilanomate, mdoerr, fyang ------------- PR: https://git.openjdk.org/jdk/pull/11902 From dfuchs at openjdk.org Mon Jan 23 14:19:36 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 23 Jan 2023 14:19:36 GMT Subject: RFR: 8299234: JMX Repository.query performance [v3] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:09:21 GMT, Alexey Bakhtin wrote: >> Please find a patch to improve JMX Repository.query performance >> >> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: >> Before: >> >> $ java test 1000000 1000000 >> Test PASSED in 8943169791 ns. >> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 >> >> >> After: >> >> $ java test 1000000 1000000 >> Test PASSED in 4808213917 ns. >> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 >> >> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. >> >> All javax/management jtreg tests passed successfully. > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Fix parameters order for Util.wildmatch Hi Alexey - you have addressed most of my concerns but let me reinstate that the changes to ObjectName are observable by subclasses and thus will require a CSR. As such this fix may also not be a good candidate for backport (if that was your intention), as it comes with a potential regression risk. ------------- PR: https://git.openjdk.org/jdk/pull/11758 From duke at openjdk.org Mon Jan 23 18:36:27 2023 From: duke at openjdk.org (Egor Ushakov) Date: Mon, 23 Jan 2023 18:36:27 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads [v2] In-Reply-To: <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com> References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com> Message-ID: On Thu, 19 Jan 2023 21:59:22 GMT, Chris Plummer wrote: >> Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Cleaned up removeUnreachableListeners(). Looks good to me, thanks! ------------- PR: https://git.openjdk.org/jdk/pull/12081 From abakhtin at openjdk.org Mon Jan 23 20:25:17 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Mon, 23 Jan 2023 20:25:17 GMT Subject: RFR: 8299234: JMX Repository.query performance [v4] In-Reply-To: References: Message-ID: > Please find a patch to improve JMX Repository.query performance > > Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: > Before: > > $ java test 1000000 1000000 > Test PASSED in 8943169791 ns. > GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 > > > After: > > $ java test 1000000 1000000 > Test PASSED in 4808213917 ns. > GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 > > Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. > > All javax/management jtreg tests passed successfully. Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Revert changes in the ObjectName ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11758/files - new: https://git.openjdk.org/jdk/pull/11758/files/5ac859ae..594dfa5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=02-03 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11758.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11758/head:pull/11758 PR: https://git.openjdk.org/jdk/pull/11758 From jwilhelm at openjdk.org Mon Jan 23 20:27:19 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 23 Jan 2023 20:27:19 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge - 8290919: Update nroff pages in JDK 20 before RC The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=12150&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12150&range=00.1 Changes: https://git.openjdk.org/jdk/pull/12150/files Stats: 28 lines in 27 files changed: 1 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/12150.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12150/head:pull/12150 PR: https://git.openjdk.org/jdk/pull/12150 From abakhtin at openjdk.org Mon Jan 23 20:27:50 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Mon, 23 Jan 2023 20:27:50 GMT Subject: RFR: 8299234: JMX Repository.query performance [v3] In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 14:09:21 GMT, Alexey Bakhtin wrote: >> Please find a patch to improve JMX Repository.query performance >> >> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: >> Before: >> >> $ java test 1000000 1000000 >> Test PASSED in 8943169791 ns. >> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 >> >> >> After: >> >> $ java test 1000000 1000000 >> Test PASSED in 4808213917 ns. >> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 >> >> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. >> >> All javax/management jtreg tests passed successfully. > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Fix parameters order for Util.wildmatch Hi Daniel, Yes, I'd like to backport these changes to JDK11 and 8. Such changes to the OjectName could be unacceptable risky. I have reverted all changes in the ObjectName class. ------------- PR: https://git.openjdk.org/jdk/pull/11758 From jwilhelm at openjdk.org Mon Jan 23 21:07:12 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 23 Jan 2023 21:07:12 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 19:52:49 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: 56dc3b08 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/56dc3b08a62f651835c5bccca987d93ba2bb8961 Stats: 28 lines in 27 files changed: 1 ins; 0 del; 27 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/12150 From cjplummer at openjdk.org Mon Jan 23 21:22:54 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 23 Jan 2023 21:22:54 GMT Subject: RFR: 8300810: Get rid of unused JDI removeListener() methods Message-ID: Remove removeListener() methods. They are not called. ------------- Commit messages: - Remove removeListener() method. Changes: https://git.openjdk.org/jdk/pull/12151/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300810 Stats: 26 lines in 2 files changed: 0 ins; 24 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12151.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12151/head:pull/12151 PR: https://git.openjdk.org/jdk/pull/12151 From cjplummer at openjdk.org Mon Jan 23 22:41:59 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 23 Jan 2023 22:41:59 GMT Subject: RFR: 8300811: jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL Message-ID: jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all created threads. It creates them with the SUSPEND_ALL policy. This is unnecessary since jdb always immediately resumes all threads after doing the thread bookkeeping. There is no interaction with the jdb user like there would be with something like a Breakpoint event, and therefore no reason to suspend. I was debugging an app that does nothing except create threads and allow them to quickly exit. Changing the policy to SUSPEND_NONE sped up the execution of the app by about 100x (that's 100 times faster, not 100%) ------------- Commit messages: - Use SUSPEND_NONE for ThreadStartRequest and ThreadDeathRequest Changes: https://git.openjdk.org/jdk/pull/12152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300811 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12152/head:pull/12152 PR: https://git.openjdk.org/jdk/pull/12152 From dholmes at openjdk.org Mon Jan 23 23:21:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 23 Jan 2023 23:21:44 GMT Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21 Message-ID: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> Please review this simple update to the manpage to set the version to 21-ea. This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 Thanks. ------------- Commit messages: - 8290918: Initial nroff manpage generation for JDK 21 Changes: https://git.openjdk.org/jdk/pull/12154/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290918 Stats: 28 lines in 27 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/12154.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12154/head:pull/12154 PR: https://git.openjdk.org/jdk/pull/12154 From lancea at openjdk.org Mon Jan 23 23:27:05 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 23 Jan 2023 23:27:05 GMT Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21 In-Reply-To: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> Message-ID: On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 > > Thanks. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12154 From amenkov at openjdk.org Tue Jan 24 00:27:09 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 24 Jan 2023 00:27:09 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes Message-ID: classFileParser drops stack map frames for JDK classes (when verification is not required). As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. This code is old (from "initial load") and I don't understand the reason it was implemented this way. Testing: tier1-tier6 ------------- Commit messages: - removed trailing spaces - Fixes class parser to not drop stackmap frames Changes: https://git.openjdk.org/jdk/pull/12155/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8228604 Stats: 344 lines in 3 files changed: 338 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12155.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12155/head:pull/12155 PR: https://git.openjdk.org/jdk/pull/12155 From dholmes at openjdk.org Tue Jan 24 00:49:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 00:49:08 GMT Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21 In-Reply-To: References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> Message-ID: On Mon, 23 Jan 2023 23:24:06 GMT, Lance Andersen wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 >> >> Thanks. > > Marked as reviewed by lancea (Reviewer). Thanks for the review @LanceAndersen ------------- PR: https://git.openjdk.org/jdk/pull/12154 From iris at openjdk.org Tue Jan 24 01:32:03 2023 From: iris at openjdk.org (Iris Clark) Date: Tue, 24 Jan 2023 01:32:03 GMT Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21 In-Reply-To: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> Message-ID: On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 > > Thanks. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12154 From cjplummer at openjdk.org Tue Jan 24 03:16:06 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 24 Jan 2023 03:16:06 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > This code is old (from "initial load") and I don't understand the reason it was implemented this way. My guess is footprint reduction. The assumption was probably that the stackmaps are not needed if the method does not need verification. You might want to consider retaining this footprint reduction for minimalVM. Basically make it conditional on INCLUDE_JVMTI, but I'm ok with the changes as-is also. ------------- PR: https://git.openjdk.org/jdk/pull/12155 From cjplummer at openjdk.org Tue Jan 24 04:01:07 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 24 Jan 2023 04:01:07 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: <672UTbipXNoOK-cibNxBjYf7SQ6liXhCIGv5AW2JpeI=.31499f3f-58e5-4bf8-8393-4f6ab5c29f8d@github.com> On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > classFileParser drops stack map frames for JDK classes (when verification is not required). > As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. > Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. > This code is old (from "initial load") and I don't understand the reason it was implemented this way. > > Testing: tier1-tier6 Copyright needs updating. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 91: > 89: int frameCount = getStackMapFrameCount(classfileBuffer); > 90: log(" Has stack map frames: " + frameCount); > 91: if (frameCount == 0) { Shouldn't the check also be that the number of frames is the same in the "load" and "retransform" cases? test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 107: > 105: byte[] retransformBytes = retransformBytes(i); > 106: checkStackMapFrames(cls + "(load)", loadBytes); > 107: checkStackMapFrames(cls + "(retranform)", retransformBytes); "retransform" ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/12155 From dholmes at openjdk.org Tue Jan 24 05:42:02 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 05:42:02 GMT Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21 In-Reply-To: References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> Message-ID: On Tue, 24 Jan 2023 01:28:53 GMT, Iris Clark wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 >> >> Thanks. > > Marked as reviewed by iris (Reviewer). Thanks for the review @irisclark ! ------------- PR: https://git.openjdk.org/jdk/pull/12154 From darcy at openjdk.org Tue Jan 24 05:57:04 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 24 Jan 2023 05:57:04 GMT Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21 In-Reply-To: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> Message-ID: On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 > > Thanks. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12154 From dholmes at openjdk.org Tue Jan 24 06:16:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 06:16:03 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > classFileParser drops stack map frames for JDK classes (when verification is not required). > As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. > Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. > This code is old (from "initial load") and I don't understand the reason it was implemented this way. > > Testing: tier1-tier6 The StackMapTable attribute was introduced to support the new split-verifier by JSR-202. As it is only needed for verification it is elided if verification is not required. Looking at this issue it seems to me that ASM is incorrect to always expect/require that a StackMapTable be present as that is not a requirement of the VM spec. ------------- PR: https://git.openjdk.org/jdk/pull/12155 From dholmes at openjdk.org Tue Jan 24 06:23:02 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 06:23:02 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > classFileParser drops stack map frames for JDK classes (when verification is not required). > As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. > Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. > This code is old (from "initial load") and I don't understand the reason it was implemented this way. > > Testing: tier1-tier6 Also AFAICS the issue reported here ie. the crashes, have been fixed since JDK 12-b15, so I'm unclear why this change is proceeding? ------------- PR: https://git.openjdk.org/jdk/pull/12155 From dholmes at openjdk.org Tue Jan 24 06:31:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 06:31:11 GMT Subject: RFR: 8290918: Initial nroff manpage generation for JDK 21 In-Reply-To: References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> Message-ID: On Tue, 24 Jan 2023 05:54:44 GMT, Joe Darcy wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 >> >> Thanks. > > Marked as reviewed by darcy (Reviewer). Thanks for the review @jddarcy ! I think that suffices for this trivial change. ------------- PR: https://git.openjdk.org/jdk/pull/12154 From dholmes at openjdk.org Tue Jan 24 06:31:13 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 24 Jan 2023 06:31:13 GMT Subject: Integrated: 8290918: Initial nroff manpage generation for JDK 21 In-Reply-To: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> References: <_l9LWouUV22whyL4PTf1esOed9cZw1jyKKVBozovayE=.f79dbc18-b48e-4e52-8a16-f9e1b732ce50@github.com> Message-ID: On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 > > Thanks. This pull request has now been integrated. Changeset: 6dd8723f Author: David Holmes URL: https://git.openjdk.org/jdk/commit/6dd8723f66a22e626d98c74cff0b0b344a62626d Stats: 28 lines in 27 files changed: 0 ins; 0 del; 28 mod 8290918: Initial nroff manpage generation for JDK 21 Reviewed-by: lancea, iris, darcy ------------- PR: https://git.openjdk.org/jdk/pull/12154 From mbaesken at openjdk.org Tue Jan 24 08:51:06 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 24 Jan 2023 08:51:06 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote: >> Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. >> >> *Testing* >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 >> - [x] GHA in progress >> >> Thoughts? > > Severin Gehwolf 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 one additional commit since the last revision: > > 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values Hi Severin, what do you think about renaming the methods to WB_HostPhysicalMemory / WB_HostPhysicalSwap to make it even more clear that the host values are meant ? On Linux we have values `_physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * (julong)sysconf(_SC_PAGESIZE);` and `julong os::physical_memory()` from os_linux.cpp (including OSContainer::memory_limit_in_bytes()) so these could be 2 different values . And please adjust the COPYRIGHT years to 2023. ------------- PR: https://git.openjdk.org/jdk/pull/12097 From sgehwolf at openjdk.org Tue Jan 24 14:30:33 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 24 Jan 2023 14:30:33 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v3] In-Reply-To: References: Message-ID: > Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. > > *Testing* > - [x] Container tests on Linux x86_64 cgv1 and cgv2 > - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 > - [x] GHA in progress > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Rename to hostPhysicalMemory/Swap ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12097/files - new: https://git.openjdk.org/jdk/pull/12097/files/2f8225e5..06ab3d80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=01-02 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12097/head:pull/12097 PR: https://git.openjdk.org/jdk/pull/12097 From sgehwolf at openjdk.org Tue Jan 24 14:34:35 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 24 Jan 2023 14:34:35 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v4] In-Reply-To: References: Message-ID: > Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. > > *Testing* > - [x] Container tests on Linux x86_64 cgv1 and cgv2 > - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 > - [x] GHA in progress > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Update copyright year to 2023 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12097/files - new: https://git.openjdk.org/jdk/pull/12097/files/06ab3d80..9d72dbae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12097&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12097/head:pull/12097 PR: https://git.openjdk.org/jdk/pull/12097 From sgehwolf at openjdk.org Tue Jan 24 14:39:07 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 24 Jan 2023 14:39:07 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v2] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 08:48:13 GMT, Matthias Baesken wrote: >> Severin Gehwolf 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 one additional commit since the last revision: >> >> 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values > > Hi Severin, what do you think about renaming the methods to WB_HostPhysicalMemory / WB_HostPhysicalSwap to make it even more clear that the host values are meant ? On Linux we have values > `_physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * (julong)sysconf(_SC_PAGESIZE);` > and > `julong os::physical_memory()` from os_linux.cpp (including OSContainer::memory_limit_in_bytes()) so these could be 2 different values . > > And please adjust the COPYRIGHT years to 2023. @MBaesken Thanks for the review! > what do you think about renaming the methods to WB_HostPhysicalMemory / WB_HostPhysicalSwap to make it even more clear that the host values are meant? Sure, done. > On Linux we have values `_physical_memory = (julong)sysconf(_SC_PHYS_PAGES) * (julong)sysconf(_SC_PAGESIZE);` and `julong os::physical_memory()` from os_linux.cpp (including OSContainer::memory_limit_in_bytes()) so these could be 2 different values . Yes. `os::Linux::physical_memory()` returns the host physical memory. Added with [JDK-8293200](https://bugs.openjdk.org/browse/JDK-8293200). `os::physical_memory()` returns the container memory (if run with a limit). In this case we want the former. > And please adjust the COPYRIGHT years to 2023. Done. ------------- PR: https://git.openjdk.org/jdk/pull/12097 From mbaesken at openjdk.org Tue Jan 24 15:11:08 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 24 Jan 2023 15:11:08 GMT Subject: RFR: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values [v4] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:34:35 GMT, Severin Gehwolf wrote: >> Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. >> >> *Testing* >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 >> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 >> - [x] GHA in progress >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2023 LGTM ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.org/jdk/pull/12097 From xuelei at openjdk.org Tue Jan 24 15:33:07 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 24 Jan 2023 15:33:07 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 18:20:10 GMT, Xue-Lei Andrew Fan wrote: >> Nothing further from me. I think this is okay as-is now. Thanks. > >> Nothing further from me. I think this is okay as-is now. Thanks. > > @dholmes-ora Thank you for the review! > @XueleiFan You need two reviews before integrating a Hotspot change - thanks. May I get one more reviewer for this PR? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11935 From jsjolen at openjdk.org Tue Jan 24 20:48:08 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 20:48:08 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ In-Reply-To: References: Message-ID: On Tue, 17 Jan 2023 11:26:12 GMT, Johan Sj?len wrote: > Do the conversion in the share/jfr/ sub-directory and all of its files. Hi @mgronlun, the "fix" comments are there because I intend to revert the macros to regular old `NULL`. I'll copy paste a more informative comment next time :). Also, the goal for comments is to use "null" unless it's directly used in a code expression. Examples: ```c++ // This function returns null void* ret_null(); // This function returns true if x == nullptr bool is_nullptr(void* x); ------------- PR: https://git.openjdk.org/jdk/pull/12034 From jsjolen at openjdk.org Tue Jan 24 20:54:17 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 20:54:17 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ [v2] In-Reply-To: References: Message-ID: > Do the conversion in the share/jfr/ sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix two faulty NULL_STRING misses ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12034/files - new: https://git.openjdk.org/jdk/pull/12034/files/4ae78ad9..a8a4c75b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12034&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12034&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12034/head:pull/12034 PR: https://git.openjdk.org/jdk/pull/12034 From dnguyen at openjdk.org Tue Jan 24 20:57:43 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 20:57:43 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update Message-ID: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. All tests passed ------------- Commit messages: - Remove currency symbol entries - Remove whitespace using tool - Remove double quotes generated by translation tool - Revert translation's removal of text - Update files for localization Changes: https://git.openjdk.org/jdk20/pull/116/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300719 Stats: 1030 lines in 81 files changed: 218 ins; 115 del; 697 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From jsjolen at openjdk.org Tue Jan 24 20:58:27 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 20:58:27 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ [v3] In-Reply-To: References: Message-ID: <2VofLEIRBOA3PL3fwbuenBGEQL0slFAVlMOasw1BG8c=.fb131c95-1fab-492d-845f-1f0afd939895@github.com> > Do the conversion in the share/jfr/ sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Manual fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12034/files - new: https://git.openjdk.org/jdk/pull/12034/files/a8a4c75b..f1a0760c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12034&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12034&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12034/head:pull/12034 PR: https://git.openjdk.org/jdk/pull/12034 From dnguyen at openjdk.org Tue Jan 24 21:08:11 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 21:08:11 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: <4tI9y6FpAFrOiS4N4joygZHAHvPm-Ka2D9_3F8pyD6o=.fbb62ba6-4658-46b5-96f8-307ab3b41f81@github.com> On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed @prrace @wangweij @naotoj @JoeWang-Java @plummercj @alexeysemenyukoracle Could you review the changes from this localization drop? ------------- PR: https://git.openjdk.org/jdk20/pull/116 From jsjolen at openjdk.org Tue Jan 24 21:10:31 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 21:10:31 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ [v4] In-Reply-To: References: Message-ID: > Do the conversion in the share/jfr/ sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix outdated copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12034/files - new: https://git.openjdk.org/jdk/pull/12034/files/f1a0760c..48b5ee0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12034&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12034&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12034/head:pull/12034 PR: https://git.openjdk.org/jdk/pull/12034 From jsjolen at openjdk.org Tue Jan 24 21:10:36 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 21:10:36 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ [v3] In-Reply-To: <2VofLEIRBOA3PL3fwbuenBGEQL0slFAVlMOasw1BG8c=.fb131c95-1fab-492d-845f-1f0afd939895@github.com> References: <2VofLEIRBOA3PL3fwbuenBGEQL0slFAVlMOasw1BG8c=.fb131c95-1fab-492d-845f-1f0afd939895@github.com> Message-ID: On Tue, 24 Jan 2023 20:58:27 GMT, Johan Sj?len wrote: >> Do the conversion in the share/jfr/ sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Manual fix Found one file which now has no changes so copyright should be reverted. Went another round through and submitting for testing (tier1) src/hotspot/share/jfr/utilities/jfrAllocation.hpp line 2: > 1: /* > 2: * Copyright (c) 2014, 2023, Oracle and/or its affiliates. All rights reserved. Unchanged file, fix ------------- PR: https://git.openjdk.org/jdk/pull/12034 From jsjolen at openjdk.org Tue Jan 24 21:42:11 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 24 Jan 2023 21:42:11 GMT Subject: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ [v4] In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 21:10:31 GMT, Johan Sj?len wrote: >> Do the conversion in the share/jfr/ sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix outdated copyright Status: Clang fails building because it now finds 2 occurrences of tautological pointer comparisons. ------------- PR: https://git.openjdk.org/jdk/pull/12034 From dnguyen at openjdk.org Tue Jan 24 21:48:11 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 21:48:11 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed @magicus @LanceAndersen @jonathan-gibbons @pavelrappo @dougxc @lahodaj Could you review the changes from this localization drop for the areas you're familiar with? ------------- PR: https://git.openjdk.org/jdk20/pull/116 From cjplummer at openjdk.org Tue Jan 24 22:05:10 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 24 Jan 2023 22:05:10 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed jdk.console and jdk.management.agent changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 22:12:26 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 22:12:26 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2] In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Change German help of jar command ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/116/files - new: https://git.openjdk.org/jdk20/pull/116/files/4ced04fb..a2528015 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From naoto at openjdk.org Tue Jan 24 22:24:15 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 24 Jan 2023 22:24:15 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change German help of jar command Changes requested by naoto (Reviewer). src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174: > 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U) > 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5 > 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean: This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations. Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 38: > 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm > 37: resource.wxl-file=WiX-Lokalisierungsdatei > 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl Shouldn't this be `de`? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 38: > 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 > 37: resource.wxl-file=WiX\u30ED\u30FC\u30AB\u30EA\u30BC\u30FC\u30B7\u30E7\u30F3\u30FB\u30D5\u30A1\u30A4\u30EB > 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl Shouldn't this be `ja`? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 38: > 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C > 37: resource.wxl-file=WiX \u672C\u5730\u5316\u6587\u4EF6 > 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl Shouldn't this be `zh_CN`? src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: CNY=\uffe5 Do not remove this. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 22:24:16 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 22:24:16 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:05:55 GMT, Naoto Sato wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change German help of jar command > > src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174: > >> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U) >> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5 >> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean: > > This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations. > Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place. OK, I can make the manual edit for this > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 38: > >> 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C >> 37: resource.wxl-file=WiX \u672C\u5730\u5316\u6587\u4EF6 >> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl > > Shouldn't this be `zh_CN`? The translation tool seems to use the English source file's file name here, so it's replaced. I will handle these 3 occurrences now. I thought I handled all occurrences of this, but these 3 slipped in ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 22:33:24 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 22:33:24 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Change localization codes. Add CNY back ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/116/files - new: https://git.openjdk.org/jdk20/pull/116/files/a2528015..40291c61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=01-02 Stats: 4 lines in 4 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 22:33:28 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 22:33:28 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:12:02 GMT, Naoto Sato wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change German help of jar command > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 38: > >> 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm >> 37: resource.wxl-file=WiX-Lokalisierungsdatei >> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl > > Shouldn't this be `de`? Changed back similar to with zh_CN > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 38: > >> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >> 37: resource.wxl-file=WiX\u30ED\u30FC\u30AB\u30EA\u30BC\u30FC\u30B7\u30E7\u30F3\u30FB\u30D5\u30A1\u30A4\u30EB >> 38: resource.wxl-file-name=MsiInstallerStrings_en.wxl > > Shouldn't this be `ja`? Changed back similar to with zh_CN ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 22:33:29 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 22:33:29 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:14:36 GMT, Naoto Sato wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change localization codes. Add CNY back > > src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63: > >> 61: # written authorization of the copyright holder. >> 62: >> 63: CNY=\uffe5 > > Do not remove this. Added back. Thanks for catching this! ------------- PR: https://git.openjdk.org/jdk20/pull/116 From prr at openjdk.org Tue Jan 24 22:44:13 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 24 Jan 2023 22:44:13 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change German help of jar command Removing the trailing white space seems OK in the desktop resources. I checked the base (English) version of the files and none of them have trailing white space so it seems unlikely it is significant. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk20/pull/116 From jlu at openjdk.org Tue Jan 24 22:44:14 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 24 Jan 2023 22:44:14 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:20:22 GMT, Damon Nguyen wrote: >> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174: >> >>> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U) >>> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5 >>> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean: >> >> This looks like a prefix, so instead of removing the space, it should be replaced with `\u0020` like other locations. >> Also, it seems that other l10n files (de, ja) do not seem to have spaces in the first place. > > OK, I can make the manual edit for this This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped. I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space. Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`? ------------- PR: https://git.openjdk.org/jdk20/pull/116 From joehw at openjdk.org Tue Jan 24 22:59:07 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 24 Jan 2023 22:59:07 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: <8IAAljdZ35sxC22s2SeFdCTX5xmx83YUFr8dwOYtXzA=.028e67c7-0969-4204-b843-0c0f2d79574f@github.com> On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change localization codes. Add CNY back Marked as reviewed by joehw (Reviewer). java.xml changes look good to me. Thanks. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From naoto at openjdk.org Tue Jan 24 22:59:08 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 24 Jan 2023 22:59:08 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:40:55 GMT, Justin Lu wrote: >> OK, I can make the manual edit for this > > This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped. > > I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space. > > Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`? Confirmed that the message is for a label (`sun.tools.jconsole.LabeledComponent`), followed by a Component, so no space seems needed in each file. Sorry for the false alarm. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 22:59:08 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 22:59:08 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:49:20 GMT, Naoto Sato wrote: >> This change was made because it was compared to the original messages.properties. In that file, the respective line is given as `MANAGE_HOTSPOT_MBEANS_IN_COLON_=Manage Hotspot MBeans in:` with no trailing space. That's why in this file, to ensure consistency, the trailing space was stripped. >> >> I think either this space should be removed, or all 4 (en, ja, de, zh) should have the `\u0020` appended. I agree that since it is a prefix it would make sense for a space to be there, but there is no guarantee that what comes after, or even the code that loads the .properties file does not already handles that necessary space. >> >> Should the space remain removed like in the English source file and the other l10n files, or do you think all 4 should be changed to add `\u0020`? > > Confirmed that the message is for a label (`sun.tools.jconsole.LabeledComponent`), followed by a Component, so no space seems needed in each file. Sorry for the false alarm. Ok I left this change out of my most recent update just in case. I addressed all the other comments I believe. Thanks! ------------- PR: https://git.openjdk.org/jdk20/pull/116 From asemenyuk at openjdk.org Tue Jan 24 22:59:12 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 24 Jan 2023 22:59:12 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change localization codes. Add CNY back src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2: > 1: > 2: Please revert the value of the `Culture` attribute. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2: > 1: > 2: Please revert the value of the `Culture` attribute. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2: > 1: > 2: Please revert the value of the `Culture` attribute. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From jlu at openjdk.org Tue Jan 24 23:06:14 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 24 Jan 2023 23:06:14 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change localization codes. Add CNY back src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties line 62: > 60: dedup-legal-notices.usage=\ --dedup-legal-notices [error-if-not-same-content]\n \u3059\u3079\u3066\u306E\u6CD5\u5F8B\u4E0A\u306E\u6CE8\u610F\u70B9\u306E\u91CD\u8907\u3092\u9664\u5916\u3057\u307E\u3059\u3002\n error-if-not-same-content\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u3001\n \u540C\u3058\u30D5\u30A1\u30A4\u30EB\u540D\u306E2\u3064\u306E\u30D5\u30A1\u30A4\u30EB\u304C\u7570\u306A\u3063\u3066\u3044\u308B\u3068\n \u30A8\u30E9\u30FC\u306B\u306A\u308A\u307E\u3059\u3002 > 61: > 62: exclude-files.argument=\u9664\u5916\u3059\u308B\u30D5\u30A1\u30A4\u30EB\u306E It seems like the translation process added a space here, but it does not appear in the original. This should be removed. src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 194: > 192: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 > 193: > 194: main.plugin.category=\u7C7B\u522B Same as above. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From asemenyuk at openjdk.org Tue Jan 24 23:19:12 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 24 Jan 2023 23:19:12 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com> On Tue, 24 Jan 2023 22:33:24 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change localization codes. Add CNY back Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2: > 1: > 2: Please revert the value of the Culture attribute. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 23:38:23 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 23:38:23 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v4] In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Remove trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/116/files - new: https://git.openjdk.org/jdk20/pull/116/files/40291c61..fc32c37f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 23:56:23 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 23:56:23 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert culture attribute ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/116/files - new: https://git.openjdk.org/jdk20/pull/116/files/fc32c37f..616b2502 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=03-04 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 23:59:13 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 23:59:13 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 23:02:58 GMT, Justin Lu wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change localization codes. Add CNY back > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties line 62: > >> 60: dedup-legal-notices.usage=\ --dedup-legal-notices [error-if-not-same-content]\n \u3059\u3079\u3066\u306E\u6CD5\u5F8B\u4E0A\u306E\u6CE8\u610F\u70B9\u306E\u91CD\u8907\u3092\u9664\u5916\u3057\u307E\u3059\u3002\n error-if-not-same-content\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u3001\n \u540C\u3058\u30D5\u30A1\u30A4\u30EB\u540D\u306E2\u3064\u306E\u30D5\u30A1\u30A4\u30EB\u304C\u7570\u306A\u3063\u3066\u3044\u308B\u3068\n \u30A8\u30E9\u30FC\u306B\u306A\u308A\u307E\u3059\u3002 >> 61: >> 62: exclude-files.argument=\u9664\u5916\u3059\u308B\u30D5\u30A1\u30A4\u30EB\u306E > > It seems like the translation process added a space here, but it does not appear in the original. This should be removed. Removed both instances of the extra trailing whitespace. > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 194: > >> 192: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 >> 193: >> 194: main.plugin.category=\u7C7B\u522B > > Same as above. Addressed as above ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 23:59:17 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 23:59:17 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:55:43 GMT, Alexey Semenyuk wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change German help of jar command > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2: > >> 1: >> 2: > > Please revert the value of the `Culture` attribute. I resolved this for the German, Japanese, and Chinese files in the latest commit. > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2: > >> 1: >> 2: > > Please revert the value of the `Culture` attribute. Resolved in recent commit ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Tue Jan 24 23:59:19 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 24 Jan 2023 23:59:19 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v3] In-Reply-To: <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> <53tinlttCmtNrOBaz7F54bKSeftrurnsr9OVoQzzjC8=.191b9195-e775-4b4b-8811-d34789cec36e@github.com> Message-ID: On Tue, 24 Jan 2023 23:16:02 GMT, Alexey Semenyuk wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change localization codes. Add CNY back > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl line 2: > >> 1: >> 2: > > Please revert the value of the Culture attribute. Resolved in recent commit ------------- PR: https://git.openjdk.org/jdk20/pull/116 From asemenyuk at openjdk.org Wed Jan 25 00:12:09 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 25 Jan 2023 00:12:09 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert culture attribute jpackage changes look good ------------- Marked as reviewed by asemenyuk (Reviewer). PR: https://git.openjdk.org/jdk20/pull/116 From amenkov at openjdk.org Wed Jan 25 00:44:03 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 25 Jan 2023 00:44:03 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 06:19:51 GMT, David Holmes wrote: >> classFileParser drops stack map frames for JDK classes (when verification is not required). >> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. >> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. >> This code is old (from "initial load") and I don't understand the reason it was implemented this way. >> >> Testing: tier1-tier6 > > Also AFAICS the issue reported here ie. the crashes, have been fixed since JDK 12-b15, so I'm unclear why this change is proceeding? @dholmes-ora thank you for the background. I've read JSR-202 and re-read ASM and openjdk issues. >From ASM report it seems to me that crashes mentioned occurred when ASM instrumented a class without StackMapTable and returned new class bytes from CFLH. And it looks like this is actually ASM issue (it generates bad classbytes with COMPUTE_MAX_STACK_AND_LOCAL_FROM_FRAMES when StackMapTable is absent). Their reproducer does not cause the crash, it just checks if StackMapTable is present (and it checks only 2 classes: java.util.Date and java.text.SimpleDateFormat). With my testing I saw that classes from CDS have StackMapTable, so my guess is Date and SimpleDateFormat classes were added to CDS in JDK 12-b15. There are still some unclear points to me. Do we need verification for classes from CDS (I'm not familiar with the area)? Also current JVM behavior looks inconsistent. I think it would be better to always restore the attributes (as the current fix does) or update fileReconstituter to never restore it. ------------- PR: https://git.openjdk.org/jdk/pull/12155 From dholmes at openjdk.org Wed Jan 25 01:11:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 25 Jan 2023 01:11:05 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > classFileParser drops stack map frames for JDK classes (when verification is not required). > As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. > Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. > This code is old (from "initial load") and I don't understand the reason it was implemented this way. > > Testing: tier1-tier6 AFIUI if verification for a type is enabled then we keep the stackmap table, else we do not. Do we have an inconsistency with that rule? Do we make assumptions about verification being enabled, or not, that we should not be? ------------- PR: https://git.openjdk.org/jdk/pull/12155 From jlu at openjdk.org Wed Jan 25 01:11:15 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 25 Jan 2023 01:11:15 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert culture attribute Marked as reviewed by jlu (Author). ------------- PR: https://git.openjdk.org/jdk20/pull/116 From mikael at openjdk.org Wed Jan 25 02:08:05 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 25 Jan 2023 02:08:05 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 18:54:08 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. >> >> This patch is trying to find the use of sprintf in hotspot iml and test cases. > > Xue-Lei Andrew Fan has updated the pull request incrementally with two additional commits since the last revision: > > - remove serviceability update and add back forbid of sprintf > - remove serviceability update Looks good, thank you for doing this! ------------- Marked as reviewed by mikael (Reviewer). PR: https://git.openjdk.org/jdk/pull/11935 From amenkov at openjdk.org Wed Jan 25 04:17:04 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 25 Jan 2023 04:17:04 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: <-wePcDs-C1SSfQT5MbbWzMjmluh0foXuWdyKzQWMiKA=.f2508b1a-92fe-469c-9749-58c2858d89b1@github.com> On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > classFileParser drops stack map frames for JDK classes (when verification is not required). > As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. > Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. > This code is old (from "initial load") and I don't understand the reason it was implemented this way. > > Testing: tier1-tier6 we have 3 test classes: java.util.Date (JDK class in CDS archive) java.lang.ProcessBuilder (JDK class, but not in CDS archive) MissedStackMapFrames - application class I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement. But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable. AFAIU this is caused by the deleted condition in parse_stackmap_table: `if (!need_verify && !DumpSharedSpaces) { return NULL; }` For Date classes the attribute is not dropped during CDS dump and is stored in CDS. Later during test execution the class is loaded from CDS as is (with the attribute). ------------- PR: https://git.openjdk.org/jdk/pull/12155 From duke at openjdk.org Wed Jan 25 08:20:13 2023 From: duke at openjdk.org (danielpeintner) Date: Wed, 25 Jan 2023 08:20:13 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 22:12:26 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change German help of jar command src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 111: > 109: main.help.opt.main.update=\ -u, --update Ein vorhandenes JAR-Archiv aktualisieren > 110: main.help.opt.main.extract=\ -x, --extract Benannte (oder alle) Dateien aus dem Archiv extrahieren > 111: main.help.opt.main.describe-module=\ -d, --describe-module Gibt den Moduldeskriptor oder automatischen Modulnamen aus Just because I stumbled over this commit. I think the line should be translated as follows: `Gibt die Modulbeschreibung oder den automatischen Modulnamen aus` ------------- PR: https://git.openjdk.org/jdk20/pull/116 From sgehwolf at openjdk.org Wed Jan 25 10:27:18 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 25 Jan 2023 10:27:18 GMT Subject: Integrated: 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 13:57:57 GMT, Severin Gehwolf wrote: > Please review this refactoring of a container test. It now uses WhiteBox to retrieve the host values it asserts for. In terms of functionality this is basically a no-op except for the now more precise assertion on systems with swap accounting disabled at the kernel level. > > *Testing* > - [x] Container tests on Linux x86_64 cgv1 and cgv2 > - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with swapaccount=0 > - [x] GHA in progress > > Thoughts? This pull request has now been integrated. Changeset: 3c61d5aa Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/3c61d5aa48606dab2d2c639d5f0a56313476917d Stats: 47 lines in 3 files changed: 27 ins; 1 del; 19 mod 8300659: Refactor TestMemoryAwareness to use WhiteBox api for host values Reviewed-by: mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/12097 From lancea at openjdk.org Wed Jan 25 13:45:21 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 25 Jan 2023 13:45:21 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert culture attribute Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/116 From ihse at openjdk.org Wed Jan 25 13:56:21 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 25 Jan 2023 13:56:21 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: <-Mjbn1ko2InJOzXLccieEzU8h4bypdm9vTzHdmtA-JQ=.2e1f4d59-e30e-434a-8e62-25777adb3a07@github.com> On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert culture attribute I skimmed through this, basically looking for trailing white space changes only, and it generally looks okay. Note that some of these trailing whitespace fixes has been independently address in mainline. Forward-porting this might involve some (virtual) conflicts. It is also impossible to see in the Github interface if you are introducing *new* trailing white spaces in the added texts. I hope you are not, and that you have verified this. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/jdk20/pull/116 From jsjolen at openjdk.org Wed Jan 25 15:17:56 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 15:17:56 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ Message-ID: Do the conversion in the share/memory/ sub-directory and all of its files. ------------- Commit messages: - Fix manual issue - Replace NULL with nullptr in share/memory/ Changes: https://git.openjdk.org/jdk/pull/12185/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301070 Stats: 678 lines in 65 files changed: 0 ins; 0 del; 678 mod Patch: https://git.openjdk.org/jdk/pull/12185.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12185/head:pull/12185 PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Wed Jan 25 15:18:00 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 15:18:00 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Found one manual fix src/hotspot/share/memory/heap.cpp line 666: > 664: /** > 665: * Search freelist for an entry on the list with the best fit. > 666: * @return nullptr, if no one was found null ------------- PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Wed Jan 25 15:18:59 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 15:18:59 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ Message-ID: Do the conversion in the share/services/ sub-directory and all of its files. ------------- Commit messages: - Manual fixes - Replace NULL with nullptr in share/services/ Changes: https://git.openjdk.org/jdk/pull/12189/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12189&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301077 Stats: 856 lines in 44 files changed: 0 ins; 0 del; 856 mod Patch: https://git.openjdk.org/jdk/pull/12189.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12189/head:pull/12189 PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Wed Jan 25 15:19:10 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 15:19:10 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:47:18 GMT, Johan Sj?len wrote: > Do the conversion in the share/services/ sub-directory and all of its files. Found some things to manually fix. src/hotspot/share/services/attachListener.cpp line 368: > 366: { "printflag", print_flag }, > 367: { "jcmd", jcmd }, > 368: { nullptr, nullptr } Align src/hotspot/share/services/classLoadingService.cpp line 51: > 49: int len = 0; \ > 50: Symbol* name = (clss)->name(); \ > 51: if (name != nullptr) { \ Align src/hotspot/share/services/diagnosticFramework.cpp line 40: > 38: : _cmd(line), _cmd_len(0), _args(nullptr), _args_len(0) > 39: { > 40: assert(line != nullptr, "Command line string should not be nullptr"); String src/hotspot/share/services/heapDumper.cpp line 793: > 791: void allocate_internal_buffer() { > 792: assert(_buffer_queue != nullptr, "Internal buffer queue is not ready when allocate internal buffer"); > 793: assert(_buffer == nullptr && _buffer_base == nullptr, "current buffer must be nullptr before allocate"); String src/hotspot/share/services/heapDumper.cpp line 1293: > 1291: // creates HPROF_GC_CLASS_DUMP record for the given array class > 1292: void DumperSupport::dump_array_class(AbstractDumpWriter* writer, Klass* k) { > 1293: InstanceKlass* ik = nullptr; // bottom class for object arrays, null for primitive type arrays string src/hotspot/share/services/memReporter.cpp line 384: > 382: > 383: void MemDetailReporter::report_virtual_memory_region(const ReservedMemoryRegion* reserved_rgn) { > 384: assert(reserved_rgn != nullptr, "nullptr pointer"); string src/hotspot/share/services/memReporter.cpp line 820: > 818: outputStream* out = output(); > 819: > 820: assert(stack != nullptr, "nullptr stack"); string src/hotspot/share/services/memTracker.hpp line 98: > 96: static inline void* record_malloc(void* mem_base, size_t size, MEMFLAGS flag, > 97: const NativeCallStack& stack) { > 98: assert(mem_base != nullptr, "caller should handle nullptr"); String src/hotspot/share/services/memTracker.hpp line 108: > 106: static inline void* record_free(void* memblock) { > 107: // Never turned on > 108: assert(memblock != nullptr, "caller should handle nullptr"); String ------------- PR: https://git.openjdk.org/jdk/pull/12189 From xuelei at openjdk.org Wed Jan 25 15:43:16 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 25 Jan 2023 15:43:16 GMT Subject: RFR: 8299635: Hotspot update for deprecated sprintf in Xcode 14 [v8] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 02:05:31 GMT, Mikael Vidstedt wrote: > Looks good, thank you for doing this! @vidmik Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/11935 From xuelei at openjdk.org Wed Jan 25 15:47:52 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 25 Jan 2023 15:47:52 GMT Subject: Integrated: 8299635: Hotspot update for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 06:26:18 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for hotspot impl, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378) for building, but the test case was not covered. The failure was reported in [PR 11793](https://github.com/openjdk/jdk/pull/11793#issuecomment-1371151565), while running tier1 testing. > > This patch is trying to find the use of sprintf in hotspot iml and test cases. This pull request has now been integrated. Changeset: e80b5ea4 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/e80b5ea448c715519d14e238321ceb5ec40b37f4 Stats: 109 lines in 40 files changed: 4 ins; 2 del; 103 mod 8299635: Hotspot update for deprecated sprintf in Xcode 14 Reviewed-by: dholmes, mikael ------------- PR: https://git.openjdk.org/jdk/pull/11935 From coleenp at openjdk.org Wed Jan 25 16:03:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 25 Jan 2023 16:03:28 GMT Subject: RFR: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded Message-ID: We thought we didn't need the keep-alive call but we do for heap walking. Tested with failing test case locally, and tier1-4 in progress. ------------- Commit messages: - 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded Changes: https://git.openjdk.org/jdk/pull/12202/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300913 Stats: 14 lines in 2 files changed: 5 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12202.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12202/head:pull/12202 PR: https://git.openjdk.org/jdk/pull/12202 From jsjolen at openjdk.org Wed Jan 25 16:19:58 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 16:19:58 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:47:18 GMT, Johan Sj?len wrote: > Do the conversion in the share/services/ sub-directory and all of its files. Passes tier1. ------------- PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Wed Jan 25 16:20:01 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 25 Jan 2023 16:20:01 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Passes tier1. ------------- PR: https://git.openjdk.org/jdk/pull/12185 From eosterlund at openjdk.org Wed Jan 25 16:33:59 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 25 Jan 2023 16:33:59 GMT Subject: RFR: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote: > We thought we didn't need the keep-alive call but we do for heap walking. > Tested with failing test case locally, and tier1-4 in progress. Looks good! ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/12202 From naoto at openjdk.org Wed Jan 25 16:55:04 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 25 Jan 2023 16:55:04 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert culture attribute LGTM ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk20/pull/116 From dcubed at openjdk.org Wed Jan 25 17:19:30 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 25 Jan 2023 17:19:30 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:10:21 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert UseFastLocking to default to off This PR is currently baselined on jdk-21+6-289. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From weijun at openjdk.org Wed Jan 25 17:36:38 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 25 Jan 2023 17:36:38 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: <_THK1t7SrTRqoW0o0gfgmCo1Ea1WfgdfeB7jNJDKUKk=.05512373-8cb2-41d3-a71f-589075240bb7@github.com> On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert culture attribute src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32: > 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1} > 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0} > 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1} While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style. There should be a general rule on which style we should use throughout all display messages. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Wed Jan 25 17:47:19 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jan 2023 17:47:19 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v6] In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert translated punctuation ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/116/files - new: https://git.openjdk.org/jdk20/pull/116/files/616b2502..4222df9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Wed Jan 25 17:51:20 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jan 2023 17:51:20 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7] In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com> > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert one more punctuation ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/116/files - new: https://git.openjdk.org/jdk20/pull/116/files/4222df9a..9a5b45a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From weijun at openjdk.org Wed Jan 25 17:52:21 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 25 Jan 2023 17:52:21 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 23:56:23 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert culture attribute src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113: > 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc > 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0} > 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B Should `exception-type` be translated? ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Wed Jan 25 18:03:54 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jan 2023 18:03:54 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Wed, 25 Jan 2023 17:49:59 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert culture attribute > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113: > >> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc >> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0} >> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B > > Should `exception-type` be translated? The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is. > src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32: > >> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1} >> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0} >> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1} > > While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style. > > There should be a general rule on which style we should use throughout all display messages. Updated the punctuation (colons and comma) to be more consistent throughout the file. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From weijun at openjdk.org Wed Jan 25 18:03:55 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 25 Jan 2023 18:03:55 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Wed, 25 Jan 2023 17:56:15 GMT, Damon Nguyen wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 113: >> >>> 111: doclet.inheritDocWithinInappropriateTag=\u4E0D\u80FD\u5728\u6B64\u6807\u8BB0\u4E2D\u4F7F\u7528 @inheritDoc >>> 112: doclet.inheritDocNoDoc=\u88AB\u8986\u76D6\u7684\u65B9\u6CD5\u4E0D\u8BB0\u5F55\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B {0} >>> 113: doclet.throwsInheritDocUnsupported=\u4E0D\u662F\u7531\u65B9\u6CD5\u58F0\u660E\u7684 exception-type \u7C7B\u578B\u53C2\u6570\u4E0D\u652F\u6301 @inheritDoc\uFF1B\u76F4\u63A5\u8BB0\u5F55\u6B64\u7C7B\u5F02\u5E38\u9519\u8BEF\u7C7B\u578B >> >> Should `exception-type` be translated? > > The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is. I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it. >> src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties line 32: >> >>> 30: err.bad.constant.pool=\u8BFB\u53D6{0}\u7684\u5E38\u91CF\u6C60\u65F6\u51FA\u9519: {1} >>> 31: err.class.not.found=\u627E\u4E0D\u5230\u7C7B: {0} >>> 32: err.crash=\u51FA\u73B0\u4E25\u91CD\u7684\u5185\u90E8\u9519\u8BEF\uFF1A{0}\n\u8BF7\u586B\u5199 Bug \u62A5\u544A\uFF0C\u5E76\u5305\u62EC\u4EE5\u4E0B\u4FE1\u606F\uFF1A\n{1} >> >> While personally I like to see Chinese-style punctuation marks (Ex: `?`) used in Chinese contexts instead of their English-style ones (Ex: `:`), it's only updated on this single line and all the others are still using the English-style. >> >> There should be a general rule on which style we should use throughout all display messages. > > Updated the punctuation (colons and comma) to be more consistent throughout the file. Looks good now. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From jjg at openjdk.org Wed Jan 25 18:24:55 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 25 Jan 2023 18:24:55 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7] In-Reply-To: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com> Message-ID: On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert one more punctuation I don't see anything absurdly wrong in the jdk.compiler files. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.org/jdk20/pull/116 From cjplummer at openjdk.org Wed Jan 25 18:32:51 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 25 Jan 2023 18:32:51 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:47:18 GMT, Johan Sj?len wrote: > Do the conversion in the share/services/ sub-directory and all of its files. Changes requested by cjplummer (Reviewer). src/hotspot/share/services/heapDumper.cpp line 1850: > 1848: > 1849: void prepare_parallel_dump(uint num_total) { > 1850: assert (_dumper_controller == nullptr, "dumper controller must be nullptr"); The string should say "null", not "nullptr". src/hotspot/share/services/mallocTracker.hpp line 332: > 330: > 331: static inline MallocHeader* malloc_header(void *memblock) { > 332: assert(memblock != nullptr, "nullptr pointer"); String should say "null", not "nullptr" src/hotspot/share/services/mallocTracker.hpp line 336: > 334: } > 335: static inline const MallocHeader* malloc_header(const void *memblock) { > 336: assert(memblock != nullptr, "nullptr pointer"); String should say "null", not "nullptr" src/hotspot/share/services/management.cpp line 1646: > 1644: typeArrayHandle times) { > 1645: assert(names() != nullptr, "names was nullptr"); > 1646: assert(times() != nullptr, "times was nullptr"); String should say "null", not "nullptr" src/hotspot/share/services/management.cpp line 1660: > 1658: void ThreadTimesClosure::do_thread(Thread* thread) { > 1659: assert(Threads_lock->owned_by_self(), "Must hold Threads_lock"); > 1660: assert(thread != nullptr, "thread was nullptr"); String should say "null", not "nullptr" src/hotspot/share/services/threadService.cpp line 224: > 222: // FIXME: JVMTI should call this function > 223: Handle ThreadService::get_current_contended_monitor(JavaThread* thread) { > 224: assert(thread != nullptr, "should be non-nullptr"); String should say "null", not "nullptr" ------------- PR: https://git.openjdk.org/jdk/pull/12189 From weijun at openjdk.org Wed Jan 25 18:58:57 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 25 Jan 2023 18:58:57 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v7] In-Reply-To: <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> <5QDH5Zhiji1PTh-833JdIopABeDoDCLA5e-u1Q3pkUE=.98a38bd3-3e52-4b51-9287-dc70454c4b89@github.com> Message-ID: On Wed, 25 Jan 2023 17:51:20 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert one more punctuation zh_cn translations look fine. Thanks. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.org/jdk20/pull/116 From prappo at openjdk.org Wed Jan 25 20:06:53 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 25 Jan 2023 20:06:53 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Wed, 25 Jan 2023 18:00:33 GMT, Weijun Wang wrote: >> The translation tool didn't seem to translate this. Either because it couldn't or because it somehow missed it. I'm not sure which, but I'm open to replacing this with a translation suggestion you have. Or I can leave it as is. > > I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it. It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows: doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \ that are not declared by a method; document such exception types directly JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type. @jonathan-gibbons thoughts? ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Wed Jan 25 22:02:45 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jan 2023 22:02:45 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v8] In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update German translation ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/116/files - new: https://git.openjdk.org/jdk20/pull/116/files/9a5b45a2..35829a25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Wed Jan 25 22:19:34 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jan 2023 22:19:34 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v2] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Wed, 25 Jan 2023 08:17:26 GMT, danielpeintner wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change German help of jar command > > src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 111: > >> 109: main.help.opt.main.update=\ -u, --update Ein vorhandenes JAR-Archiv aktualisieren >> 110: main.help.opt.main.extract=\ -x, --extract Benannte (oder alle) Dateien aus dem Archiv extrahieren >> 111: main.help.opt.main.describe-module=\ -d, --describe-module Gibt den Moduldeskriptor oder automatischen Modulnamen aus > > Just because I stumbled over this commit. I think the line should be translated as follows: > > `Gibt die Modulbeschreibung oder den automatischen Modulnamen aus` Resolved ------------- PR: https://git.openjdk.org/jdk20/pull/116 From jjg at openjdk.org Wed Jan 25 22:41:34 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 25 Jan 2023 22:41:34 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Wed, 25 Jan 2023 20:03:48 GMT, Pavel Rappo wrote: >> I'm not sure either. You can ask a javadoc expert whether this is a proper noun or just plain English. I noticed it's also not translated in the Japanese version but the German version has translated it. > > It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows: > > doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \ > that are not declared by a method; document such exception types directly > > JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type. > > @jonathan-gibbons thoughts? While the text is technically correct, it may not be as clear as it could be to all folk that will read this message for whom English is not their primary language. I would suggest translating the phrase as if it were something like @inheritDoc is not supported for type parameters that are exception types and not declared by a method and secondarily, changing the English resource to something like that as well. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Wed Jan 25 22:56:59 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jan 2023 22:56:59 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v9] In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Replace exception-type ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/116/files - new: https://git.openjdk.org/jdk20/pull/116/files/35829a25..53a86ef2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=116&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk20/pull/116.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/116/head:pull/116 PR: https://git.openjdk.org/jdk20/pull/116 From dnguyen at openjdk.org Wed Jan 25 22:56:59 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jan 2023 22:56:59 GMT Subject: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5] In-Reply-To: References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Wed, 25 Jan 2023 22:38:38 GMT, Jonathan Gibbons wrote: >> It's not a noun. It's an adjective that I had to synthesize for extra clarity and closeness to Java Language Specification (JLS). The English version of that entry is as follows: >> >> doclet.throwsInheritDocUnsupported=@inheritDoc is not supported for exception-type type parameters \ >> that are not declared by a method; document such exception types directly >> >> JLS _8.4.6. Method Throws_ defines BNF which conveniently labels elements, a list of which may appear in the `throws` clause, as `ExceptionType`. To make it more English-like and separate two otherwise consecutive occurrences of "type" in that sentence, I split the words with a hyphen and lower-cased them: exception-type. >> >> @jonathan-gibbons thoughts? > > While the text is technically correct, it may not be as clear as it could be to all folk that will read this message for whom English is not their primary language. > > I would suggest translating the phrase as if it were something like > > @inheritDoc is not supported for type parameters that are exception types and not declared by a method > > > and secondarily, changing the English resource to something like that as well. Updated this line with `exception-type` translated. Hopefully this will be addressed in future drops with changes to the translation tool after some bug fixes. ------------- PR: https://git.openjdk.org/jdk20/pull/116 From stefank at openjdk.org Thu Jan 26 09:41:31 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 26 Jan 2023 09:41:31 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Marked as reviewed by stefank (Reviewer). src/hotspot/share/memory/guardedMemory.hpp line 196: > 194: */ > 195: void* wrap_with_guards(void* base_ptr, size_t user_size, const void* tag = nullptr) { > 196: assert(base_ptr != nullptr, "Attempt to wrap nullptr with memory guard"); wrap nullptr => wrap null? src/hotspot/share/memory/guardedMemory.hpp line 229: > 227: * Return the general purpose tag. > 228: * > 229: * @return the general purpose tag, defaults to nullptr. nullptr => null? src/hotspot/share/memory/guardedMemory.hpp line 306: > 304: * @param tag optional general purpose tag (see GuardedMemory::get_tag()) > 305: * > 306: * @return guarded wrapped memory pointer to the user area, or nullptr if OOM. nullptr => null? ------------- PR: https://git.openjdk.org/jdk/pull/12185 From stuefe at openjdk.org Thu Jan 26 09:55:49 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 26 Jan 2023 09:55:49 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: <0aCQc0pJSXBfXOhQScn8rnaC_dlDZV_sGYbvILnhDvY=.f16bfcbe-dc56-448d-8de1-ead0f3322f77@github.com> On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Metaspace changes are good. src/hotspot/share/memory/metaspace/blockTree.hpp line 228: > 226: DEBUG_ONLY(check_node(insertion_point);) > 227: if (n->_word_size == insertion_point->_word_size) { > 228: add_to_list(n, insertion_point); // parent stays null in this case. Small nit. Do we have a unified naming scheme for comments? "null" reads like a java null. I prefer keeping NULL in comments. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/12185 From xuelei at openjdk.org Thu Jan 26 10:14:08 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 26 Jan 2023 10:14:08 GMT Subject: RFR: 8301132: Test update for deprecated sprintf in Xcode 14 Message-ID: The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test. ------------- Commit messages: - 8301132: Test update for deprecated sprintf in Xcode 14 Changes: https://git.openjdk.org/jdk/pull/12211/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12211&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301132 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/12211.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12211/head:pull/12211 PR: https://git.openjdk.org/jdk/pull/12211 From kevinw at openjdk.org Thu Jan 26 11:12:42 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 26 Jan 2023 11:12:42 GMT Subject: RFR: 8300810: Get rid of unused JDI removeListener() methods In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 20:58:20 GMT, Chris Plummer wrote: > Remove removeListener() methods. They are not called. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/12151 From rkennke at openjdk.org Thu Jan 26 12:34:18 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 26 Jan 2023 12:34:18 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: - Merge branch 'master' into JDK-8291556-v2 - Revert UseFastLocking to default to off - Change log message inflate(locked) -> inflate(has_locker) - Properly set ZF on anon-check path; avoid some conditional branches - Use testb when testing for anon owner in fast-path - Merge branch 'master' into JDK-8291555-v2 - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread - x86 part of optimization to check for anon owner - Optimize the check-for-anon-owner fast-path - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c ------------- Changes: https://git.openjdk.org/jdk/pull/10907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=04 Stats: 1936 lines in 74 files changed: 1219 ins; 94 del; 623 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rehn at openjdk.org Thu Jan 26 13:07:26 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 26 Jan 2023 13:07:26 GMT Subject: RFR: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote: > We thought we didn't need the keep-alive call but we do for heap walking. > Tested with failing test case locally, and tier1-4 in progress. Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12202 From coleenp at openjdk.org Thu Jan 26 13:07:27 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jan 2023 13:07:27 GMT Subject: RFR: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote: > We thought we didn't need the keep-alive call but we do for heap walking. > Tested with failing test case locally, and tier1-4 in progress. Thanks Erik and Robbin! ------------- PR: https://git.openjdk.org/jdk/pull/12202 From coleenp at openjdk.org Thu Jan 26 13:07:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 26 Jan 2023 13:07:28 GMT Subject: Integrated: 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote: > We thought we didn't need the keep-alive call but we do for heap walking. > Tested with failing test case locally, and tier1-4 in progress. This pull request has now been integrated. Changeset: 3f633814 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/3f6338146e9d4103ca427986d61af9c23c9651fd Stats: 14 lines in 2 files changed: 5 ins; 8 del; 1 mod 8300913: ZGC: assert(to_addr != 0) failed: Should be forwarded Reviewed-by: eosterlund, rehn ------------- PR: https://git.openjdk.org/jdk/pull/12202 From rehn at openjdk.org Thu Jan 26 13:48:19 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 26 Jan 2023 13:48:19 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 12:09:27 GMT, Roman Kennke wrote: > > I always change the flags in code for the reasons David state and I can't forget to add any flags. > > (Test batch is stilling running, no failures except MonitorInflationTest.java) > > Ok, right. > > I just re-ran tier1-3 with the flag changed in code, on aarch64 and x86_64 without regressions. Will run tier4 overnight. I did a bigger batch of testing, there were some ThreadMXBean failures with wrong state. I'll investigate, otherwise passed. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From jsjolen at openjdk.org Thu Jan 26 15:02:54 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:02:54 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: References: Message-ID: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> > Do the conversion in the share/services/ sub-directory and all of its files. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: plummercj's fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12189/files - new: https://git.openjdk.org/jdk/pull/12189/files/d2b39efa..64eae876 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12189&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12189&range=00-01 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12189.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12189/head:pull/12189 PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Thu Jan 26 15:02:57 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:02:57 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 18:30:00 GMT, Chris Plummer wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> plummercj's fixes > > Changes requested by cjplummer (Reviewer). Thanks @plummercj , I've pushed your fixes. ------------- PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Thu Jan 26 15:08:40 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:08:40 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ [v2] In-Reply-To: References: Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/memory/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix stefank's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12185/files - new: https://git.openjdk.org/jdk/pull/12185/files/def9b5f3..1b09b9a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12185&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12185&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12185.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12185/head:pull/12185 PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Thu Jan 26 15:08:42 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:08:42 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ [v2] In-Reply-To: <0aCQc0pJSXBfXOhQScn8rnaC_dlDZV_sGYbvILnhDvY=.f16bfcbe-dc56-448d-8de1-ead0f3322f77@github.com> References: <0aCQc0pJSXBfXOhQScn8rnaC_dlDZV_sGYbvILnhDvY=.f16bfcbe-dc56-448d-8de1-ead0f3322f77@github.com> Message-ID: On Thu, 26 Jan 2023 09:48:06 GMT, Thomas Stuefe wrote: >Small nit. Do we have a unified naming scheme for comments? Yeah, I forgot to update the PR message with all of the info. If you check now you can see what's been decided upon. The discussions can be found in previous PRs, I can link to them if you're curious. >"null" reads like a java null. I prefer keeping NULL in comments. That's true, but this probably can be inferred from context which one is meant quite easily? I'd be more keen on explicitly saying that something is a Java null. ------------- PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Thu Jan 26 15:08:42 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 15:08:42 GMT Subject: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/ [v2] In-Reply-To: References: <0aCQc0pJSXBfXOhQScn8rnaC_dlDZV_sGYbvILnhDvY=.f16bfcbe-dc56-448d-8de1-ead0f3322f77@github.com> Message-ID: On Thu, 26 Jan 2023 15:04:06 GMT, Johan Sj?len wrote: >> src/hotspot/share/memory/metaspace/blockTree.hpp line 228: >> >>> 226: DEBUG_ONLY(check_node(insertion_point);) >>> 227: if (n->_word_size == insertion_point->_word_size) { >>> 228: add_to_list(n, insertion_point); // parent stays null in this case. >> >> Small nit. Do we have a unified naming scheme for comments? >> >> "null" reads like a java null. I prefer keeping NULL in comments. > >>Small nit. Do we have a unified naming scheme for comments? > > Yeah, I forgot to update the PR message with all of the info. If you check now you can see what's been decided upon. The discussions can be found in previous PRs, I can link to them if you're curious. > >>"null" reads like a java null. I prefer keeping NULL in comments. > > That's true, but this probably can be inferred from context which one is meant quite easily? I'd be more keen on explicitly saying that something is a Java null. FWIW, from fixing these reviews I've never seen us referring to a Java null when we meant a C++ nullptr. ------------- PR: https://git.openjdk.org/jdk/pull/12185 From jsjolen at openjdk.org Thu Jan 26 16:31:23 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:31:23 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <7AClZZSVSDx2-mMev-jjguFL3ARBT1UtXQGtKcBNs_I=.ddb55903-fb21-4f39-b888-45784cfc1159@github.com> On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! Passes tier1. src/hotspot/share/prims/jni.cpp line 2234: > 2232: if (s_value != nullptr) { > 2233: size_t length = java_lang_String::utf8_length(java_string, s_value); > 2234: /* JNI Specification states return nullptr on OOM */ null src/hotspot/share/prims/jni.cpp line 2420: > 2418: *isCopy = JNI_FALSE; \ > 2419: } \ > 2420: /* Empty array: legal but useless, can't return nullptr. \ null src/hotspot/share/prims/jni.cpp line 2425: > 2423: result = (ElementType*)get_bad_address(); \ > 2424: } else { \ > 2425: /* JNI Specification states return nullptr on OOM */ \ null src/hotspot/share/prims/jni.cpp line 2839: > 2837: int s_len = java_lang_String::length(s, s_value); > 2838: ret = NEW_C_HEAP_ARRAY_RETURN_NULL(jchar, s_len + 1, mtInternal); // add one for zero termination > 2839: /* JNI Specification states return nullptr on OOM */ null src/hotspot/share/prims/jniCheck.cpp line 95: > 93: result_type JNICALL header { \ > 94: Thread* cur = Thread::current_or_null(); \ > 95: if (cur == nullptr || !cur->is_Java_thread()) { \ align src/hotspot/share/prims/jniCheck.cpp line 935: > 933: va_list args; \ > 934: IN_VM( \ > 935: jniCheck::validate_call(thr, nullptr, methodID, obj); \ align src/hotspot/share/prims/jniCheck.cpp line 953: > 951: functionEnter(thr); \ > 952: IN_VM(\ > 953: jniCheck::validate_call(thr, nullptr, methodID, obj); \ align src/hotspot/share/prims/jniCheck.cpp line 969: > 967: functionEnter(thr); \ > 968: IN_VM( \ > 969: jniCheck::validate_call(thr, nullptr, methodID, obj); \ align ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Thu Jan 26 16:31:11 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:31:11 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ Message-ID: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. Here are some typical things to look out for: 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. An example of this: ```c++ // This function returns null void* ret_null(); // This function returns true if *x == nullptr bool is_nullptr(void** x); Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. Thanks! ------------- Commit messages: - Fixes - nullptr_CHECK -> NULL_CHECK - Replace NULL with nullptr in share/prims/ Changes: https://git.openjdk.org/jdk/pull/12188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301076 Stats: 2040 lines in 47 files changed: 0 ins; 0 del; 2040 mod Patch: https://git.openjdk.org/jdk/pull/12188.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12188/head:pull/12188 PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Thu Jan 26 16:31:26 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:31:26 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <7AClZZSVSDx2-mMev-jjguFL3ARBT1UtXQGtKcBNs_I=.ddb55903-fb21-4f39-b888-45784cfc1159@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> <7AClZZSVSDx2-mMev-jjguFL3ARBT1UtXQGtKcBNs_I=.ddb55903-fb21-4f39-b888-45784cfc1159@github.com> Message-ID: <1H7b0XMLwl92eWr13mS-7612t_VeVUHfBsL8o909cok=.1302aa16-4c65-43d2-ae75-baa45c32f0a5@github.com> On Thu, 26 Jan 2023 16:11:14 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we >> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. >> >> Here are some typical things to look out for: >> >> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). >> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. >> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. >> >> An example of this: >> >> ```c++ >> // This function returns null >> void* ret_null(); >> // This function returns true if *x == nullptr >> bool is_nullptr(void** x); >> >> >> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. >> >> Thanks! > > src/hotspot/share/prims/jniCheck.cpp line 935: > >> 933: va_list args; \ >> 934: IN_VM( \ >> 935: jniCheck::validate_call(thr, nullptr, methodID, obj); \ > > align Not aligned from start, not fixing. > src/hotspot/share/prims/jniCheck.cpp line 953: > >> 951: functionEnter(thr); \ >> 952: IN_VM(\ >> 953: jniCheck::validate_call(thr, nullptr, methodID, obj); \ > > align Not aligned from start, not fixing. > src/hotspot/share/prims/jniCheck.cpp line 969: > >> 967: functionEnter(thr); \ >> 968: IN_VM( \ >> 969: jniCheck::validate_call(thr, nullptr, methodID, obj); \ > > align Not aligned from start, not fixing. ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Thu Jan 26 16:33:32 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 26 Jan 2023 16:33:32 GMT Subject: Integrated: JDK-8301070: Replace NULL with nullptr in share/memory/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/memory/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! This pull request has now been integrated. Changeset: d98a323a Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/d98a323a8b972c17a066c597a81b164681ad5589 Stats: 678 lines in 65 files changed: 0 ins; 0 del; 678 mod 8301070: Replace NULL with nullptr in share/memory/ Reviewed-by: stefank, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/12185 From mikael at openjdk.org Thu Jan 26 18:11:18 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 26 Jan 2023 18:11:18 GMT Subject: RFR: 8301132: Test update for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 06:38:00 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test. test/jdk/sun/management/windows/exerevokeall.c line 102: > 100: > 101: // S-SID_REVISION > 102: snprintf(name, sizeof(name), "S-%lu-", SID_REVISION ); Name is a `char *` so sizeof will return the size of the pointer, not the length of the allocate data. ------------- PR: https://git.openjdk.org/jdk/pull/12211 From dnguyen at openjdk.org Thu Jan 26 22:36:39 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 26 Jan 2023 22:36:39 GMT Subject: [jdk20] Integrated: 8300719: JDK 20 RDP2 L10n resource files update In-Reply-To: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> References: <0fuTtDy_5ZjAaxfJV75WRG8xQ76Tj-oM5hdYpG-yfkk=.a4ce241d-52a8-422a-9e1e-40de0afa78cb@github.com> Message-ID: On Tue, 24 Jan 2023 20:50:00 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. Whitespace tool has been ran on files. > All tests passed This pull request has now been integrated. Changeset: a67b1e77 Author: Damon Nguyen Committer: Naoto Sato URL: https://git.openjdk.org/jdk20/commit/a67b1e77d33339f5db36c6d15bac0423a31eb5ee Stats: 1023 lines in 82 files changed: 218 ins; 114 del; 691 mod 8300719: JDK 20 RDP2 L10n resource files update Reviewed-by: cjplummer, naoto, prr, joehw, asemenyuk, jlu, lancea, ihse, jjg, weijun ------------- PR: https://git.openjdk.org/jdk20/pull/116 From dcubed at openjdk.org Thu Jan 26 22:52:19 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 26 Jan 2023 22:52:19 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: <8rlBFtD2u34qhm_YUrdTR7mNcRDR2n7XVMRnUUFYUOA=.4ed35f18-e017-48ef-a2a2-9ead17595a11@github.com> On Thu, 26 Jan 2023 12:34:18 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: > > - Merge branch 'master' into JDK-8291556-v2 > - Revert UseFastLocking to default to off > - Change log message inflate(locked) -> inflate(has_locker) > - Properly set ZF on anon-check path; avoid some conditional branches > - Use testb when testing for anon owner in fast-path > - Merge branch 'master' into JDK-8291555-v2 > - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread > - x86 part of optimization to check for anon owner > - Optimize the check-for-anon-owner fast-path > - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 > - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c This PR is currently baselined on jdk-21+8-485. Now I get to see what happens to the comments that I'm in the process of making... :-) ------------- PR: https://git.openjdk.org/jdk/pull/10907 From cjplummer at openjdk.org Fri Jan 27 01:49:19 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 27 Jan 2023 01:49:19 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> References: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> Message-ID: On Thu, 26 Jan 2023 15:02:54 GMT, Johan Sj?len wrote: >> Do the conversion in the share/services/ sub-directory and all of its files. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > plummercj's fixes Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12189 From dholmes at openjdk.org Fri Jan 27 02:16:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 27 Jan 2023 02:16:16 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: <-wePcDs-C1SSfQT5MbbWzMjmluh0foXuWdyKzQWMiKA=.f2508b1a-92fe-469c-9749-58c2858d89b1@github.com> References: <-wePcDs-C1SSfQT5MbbWzMjmluh0foXuWdyKzQWMiKA=.f2508b1a-92fe-469c-9749-58c2858d89b1@github.com> Message-ID: On Wed, 25 Jan 2023 04:14:24 GMT, Alex Menkov wrote: >I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement. Generally speaking yes - they are both loaded by bootstrap loader and so would both have verification disabled by default. Bt as you note the behaviour can change when CDS is involved and only one class gets dumped. > But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable. This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment on why we treat things differently during dumping. ------------- PR: https://git.openjdk.org/jdk/pull/12155 From iklam at openjdk.org Fri Jan 27 04:19:17 2023 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 27 Jan 2023 04:19:17 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: <-wePcDs-C1SSfQT5MbbWzMjmluh0foXuWdyKzQWMiKA=.f2508b1a-92fe-469c-9749-58c2858d89b1@github.com> Message-ID: <3nmdxhyFNIRLpS31OeKoSaFicF_j_4irbzcpYLZqWMs=.fb25fb9e-9581-4c60-9e62-9d55912115c7@github.com> On Fri, 27 Jan 2023 02:13:28 GMT, David Holmes wrote: > > I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement. > > Generally speaking yes - they are both loaded by bootstrap loader and so would both have verification disabled by default. Bt as you note the behaviour can change when CDS is involved and only one class gets dumped. > > > But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable. > > This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment on why we treat things differently during dumping. We always enable verification for all classes during -Xshare:dump. That avoid problems where the classes were dumped without verification but at run time you enable verification. ------------- PR: https://git.openjdk.org/jdk/pull/12155 From lmesnik at openjdk.org Fri Jan 27 05:12:53 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 27 Jan 2023 05:12:53 GMT Subject: RFR: 8298979: Remove duplicated serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java Message-ID: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com> PR adds fix "8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing" to new test and remove duplication. ------------- Commit messages: - cp - fix Changes: https://git.openjdk.org/jdk/pull/12240/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298979 Stats: 856 lines in 11 files changed: 45 ins; 782 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/12240.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12240/head:pull/12240 PR: https://git.openjdk.org/jdk/pull/12240 From lmesnik at openjdk.org Fri Jan 27 05:20:28 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 27 Jan 2023 05:20:28 GMT Subject: RFR: 8298979: Remove duplicated serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java [v2] In-Reply-To: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com> References: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com> Message-ID: > PR adds fix "8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing" to new test and remove duplication. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - cleanup - used get_thread_name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12240/files - new: https://git.openjdk.org/jdk/pull/12240/files/661a6082..01479d0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12240&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12240&range=00-01 Stats: 26 lines in 1 file changed: 1 ins; 15 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/12240.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12240/head:pull/12240 PR: https://git.openjdk.org/jdk/pull/12240 From xuelei at openjdk.org Fri Jan 27 05:27:41 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 27 Jan 2023 05:27:41 GMT Subject: RFR: 8301132: Test update for deprecated sprintf in Xcode 14 [v2] In-Reply-To: References: Message-ID: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test. Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: incorrect use of sizeof ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12211/files - new: https://git.openjdk.org/jdk/pull/12211/files/3030620a..c9b3d889 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12211&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12211&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/12211.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12211/head:pull/12211 PR: https://git.openjdk.org/jdk/pull/12211 From xuelei at openjdk.org Fri Jan 27 05:27:42 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 27 Jan 2023 05:27:42 GMT Subject: RFR: 8301132: Test update for deprecated sprintf in Xcode 14 [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 18:07:42 GMT, Mikael Vidstedt wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: >> >> incorrect use of sizeof > > test/jdk/sun/management/windows/exerevokeall.c line 102: > >> 100: >> 101: // S-SID_REVISION >> 102: snprintf(name, sizeof(name), "S-%lu-", SID_REVISION ); > > Name is a `char *` so sizeof will return the size of the pointer, not the length of the allocate data. Ooooops. Thank you for the catch! ------------- PR: https://git.openjdk.org/jdk/pull/12211 From coleenp at openjdk.org Fri Jan 27 14:07:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 27 Jan 2023 14:07:29 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> References: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> Message-ID: On Thu, 26 Jan 2023 15:02:54 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/services/. Unfortunately the script that does the change isn't perfect, and so we >> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. >> >> Here are some typical things to look out for: >> >> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). >> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. >> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. >> >> An example of this: >> >> ```c++ >> // This function returns null >> void* ret_null(); >> // This function returns true if *x == nullptr >> bool is_nullptr(void** x); >> >> >> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > plummercj's fixes Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Fri Jan 27 15:46:31 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 15:46:31 GMT Subject: RFR: JDK-8301077: Replace NULL with nullptr in share/services/ [v2] In-Reply-To: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> References: <_X0IZpW-Kd8SmMSgkUR9XvwYxKuqer65A6i6GjCYhyM=.8c0fe68f-ca64-4acb-a80e-e043758f0c5b@github.com> Message-ID: On Thu, 26 Jan 2023 15:02:54 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/services/. Unfortunately the script that does the change isn't perfect, and so we >> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. >> >> Here are some typical things to look out for: >> >> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). >> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. >> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. >> >> An example of this: >> >> ```c++ >> // This function returns null >> void* ret_null(); >> // This function returns true if *x == nullptr >> bool is_nullptr(void** x); >> >> >> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > plummercj's fixes Still passes tier1! ------------- PR: https://git.openjdk.org/jdk/pull/12189 From jsjolen at openjdk.org Fri Jan 27 15:46:34 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 27 Jan 2023 15:46:34 GMT Subject: Integrated: JDK-8301077: Replace NULL with nullptr in share/services/ In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 11:47:18 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/services/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! This pull request has now been integrated. Changeset: 5c1ec826 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/5c1ec82656323872c4628026662fe5b62e7a61e3 Stats: 856 lines in 44 files changed: 0 ins; 0 del; 856 mod 8301077: Replace NULL with nullptr in share/services/ Reviewed-by: cjplummer, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/12189 From mikael at openjdk.org Fri Jan 27 18:13:18 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 27 Jan 2023 18:13:18 GMT Subject: RFR: 8301132: Test update for deprecated sprintf in Xcode 14 [v2] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 05:27:41 GMT, Xue-Lei Andrew Fan wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > incorrect use of sizeof Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12211 From duke at openjdk.org Fri Jan 27 18:43:34 2023 From: duke at openjdk.org (duke) Date: Fri, 27 Jan 2023 18:43:34 GMT Subject: Withdrawn: 8296546: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From xuelei at openjdk.org Fri Jan 27 19:04:26 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 27 Jan 2023 19:04:26 GMT Subject: Integrated: 8301132: Test update for deprecated sprintf in Xcode 14 In-Reply-To: References: Message-ID: <4S8I0v4s9Sui7kdmAyQBxtDSRO445IvsCX6aAl6BwmY=.b04b6ba0-a1e2-4525-bb76-5af8d7daa8c2@github.com> On Thu, 26 Jan 2023 06:38:00 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812)/[JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635), but the test was not fully covered yet. This would be the last effort to fix the issue in test. This pull request has now been integrated. Changeset: 9c4bc2c3 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/9c4bc2c3954b97821a2bf371cab61edbc3d81d36 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod 8301132: Test update for deprecated sprintf in Xcode 14 Reviewed-by: mikael ------------- PR: https://git.openjdk.org/jdk/pull/12211 From amenkov at openjdk.org Fri Jan 27 20:41:15 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 27 Jan 2023 20:41:15 GMT Subject: RFR: 8300810: Get rid of unused JDI removeListener() methods In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 20:58:20 GMT, Chris Plummer wrote: > Remove removeListener() methods. They are not called. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12151 From amenkov at openjdk.org Fri Jan 27 20:46:17 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 27 Jan 2023 20:46:17 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <1Q1fwnHYAz969STCOnR9otQ7QUJhxgeLzSEuWXQCjEk=.062759a8-2658-47bb-9ef9-ce7d02e9d309@github.com> On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! src/hotspot/share/prims/jvmtiImpl.hpp line 553: > 551: > 552: // Utility macro that checks for null pointers: > 553: #NULL nullptr_CHECK(X, Y) if ((X) == nullptr) { return (Y); } causes compilation error ------------- PR: https://git.openjdk.org/jdk/pull/12188 From xuelei at openjdk.org Fri Jan 27 21:02:59 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 27 Jan 2023 21:02:59 GMT Subject: RFR: 8301279: update for deprecated sprintf for management components Message-ID: The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components. ------------- Commit messages: - 8301279: update for deprecated sprintf for management components Changes: https://git.openjdk.org/jdk/pull/12266/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12266&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301279 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12266.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12266/head:pull/12266 PR: https://git.openjdk.org/jdk/pull/12266 From jwilhelm at openjdk.org Fri Jan 27 21:08:40 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Fri, 27 Jan 2023 21:08:40 GMT Subject: RFR: Merge jdk20 Message-ID: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com> Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8301206: Fix issue with LocaleData after JDK-8300719 - 8300953: ClassDesc::ofInternalName missing @since tag - 8300719: JDK 20 RDP2 L10n resource files update The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=12267&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=12267&range=00.1 Changes: https://git.openjdk.org/jdk/pull/12267/files Stats: 1078 lines in 85 files changed: 220 ins; 114 del; 744 mod Patch: https://git.openjdk.org/jdk/pull/12267.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12267/head:pull/12267 PR: https://git.openjdk.org/jdk/pull/12267 From jwilhelm at openjdk.org Fri Jan 27 22:49:26 2023 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Fri, 27 Jan 2023 22:49:26 GMT Subject: Integrated: Merge jdk20 In-Reply-To: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com> References: <7o8i6xuRhpJrSJJg2EUyu-JPcawJAytTWS3yHX3PZd0=.0157940a-bbb2-4dc0-a645-5cde446d5052@github.com> Message-ID: On Fri, 27 Jan 2023 21:00:03 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: 5c59de52 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/5c59de52a31da937663ad2cef055213489b0516e Stats: 1078 lines in 85 files changed: 220 ins; 114 del; 744 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/12267 From amenkov at openjdk.org Fri Jan 27 23:14:17 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 27 Jan 2023 23:14:17 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > classFileParser drops stack map frames for JDK classes (when verification is not required). > As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. > Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. > This code is old (from "initial load") and I don't understand the reason it was implemented this way. > > Testing: tier1-tier6 Now it becomes clearer why it was implemented this way. I suppose there is a reason why CDS does not elide the attributes when verification is not required. Looking at the code history I see that in former times the method allocated memory for the returned attribute (now it returns pointer in the source stream), so this code reduced the footprint. I agree that this inconsistency is not a bug itself - RetransformClasses spec says "Some attributes may not be present" (in the class bytes passed to CFLH), and JDK-8228604 may be closed as "not an issue". But I still think it make sense to simplify the logic and just keep stackmap table for all classes is class bytes contain them. @dholmes-ora what do you think? ------------- PR: https://git.openjdk.org/jdk/pull/12155 From lmesnik at openjdk.org Fri Jan 27 23:31:12 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 27 Jan 2023 23:31:12 GMT Subject: RFR: 8298907: nsk JDI tests pass if the debuggee failed to launch Message-ID: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> Updated run() to return exitCode and make testExitCode non-static to don't use it in run() ------------- Commit messages: - fixed cp - 8298907: nsk JDI tests pass if the debuggee failed to launch Changes: https://git.openjdk.org/jdk/pull/12270/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12270&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298907 Stats: 367 lines in 186 files changed: 0 ins; 0 del; 367 mod Patch: https://git.openjdk.org/jdk/pull/12270.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12270/head:pull/12270 PR: https://git.openjdk.org/jdk/pull/12270 From dcubed at openjdk.org Fri Jan 27 23:31:21 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 27 Jan 2023 23:31:21 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 12:34:18 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: > > - Merge branch 'master' into JDK-8291556-v2 > - Revert UseFastLocking to default to off > - Change log message inflate(locked) -> inflate(has_locker) > - Properly set ZF on anon-check path; avoid some conditional branches > - Use testb when testing for anon owner in fast-path > - Merge branch 'master' into JDK-8291555-v2 > - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread > - x86 part of optimization to check for anon owner > - Optimize the check-for-anon-owner fast-path > - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 > - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c This is a partial review of this PR. I've only reviewed the following files so far: src/hotspot/share/oops/markWord.hpp src/hotspot/share/oops/oop.cpp src/hotspot/share/runtime/javaThread.hpp src/hotspot/share/runtime/lockStack.cpp src/hotspot/share/runtime/lockStack.cpp src/hotspot/share/runtime/objectMonitor.cpp src/hotspot/share/runtime/synchronizer.cpp src/hotspot/share/runtime/thread.cpp src/hotspot/share/runtime/threads.cpp src/hotspot/share/runtime/threads.hpp I've also created a patch with editorial changes. Please see: https://github.com/openjdk/jdk/pull/12271 src/hotspot/share/runtime/synchronizer.cpp line 1301: > 1299: // We could always eliminate polling by parking the thread on some auxiliary list. > 1300: // NOTE: We need to check UseFastLocking here, because with fast-locking, the header > 1301: // may legitimately be zero: cleared lock-bits and all upper header bits zero. The `markWord::INFLATING()` value was picked to be zero because the header could never be zero except for the inflating case. With fast-locking, in the locked case with no hashcode, the header can be all zeros. Hmmm... gotta mull on that one... fast-locking does not use the `markWord::INFLATING()`, but that protocol exists with the stack-locking implementation to prevent races. Here's the gory comment from the "Case stack-locked" portion of `ObjectSynchronizer::inflate()`: // We've successfully installed INFLATING (0) into the mark-word. // This is the only case where 0 will appear in a mark-word. // Only the singular thread that successfully swings the mark-word // to 0 can perform (or more precisely, complete) inflation. // // Why do we CAS a 0 into the mark-word instead of just CASing the // mark-word from the stack-locked value directly to the new inflated state? // Consider what happens when a thread unlocks a stack-locked object. // It attempts to use CAS to swing the displaced header value from the // on-stack BasicLock back into the object header. Recall also that the // header value (hash code, etc) can reside in (a) the object header, or // (b) a displaced header associated with the stack-lock, or (c) a displaced // header in an ObjectMonitor. The inflate() routine must copy the header // value from the BasicLock on the owner's stack to the ObjectMonitor, all // the while preserving the hashCode stability invariants. If the owner // decides to release the lock while the value is 0, the unlock will fail // and control will eventually pass from slow_exit() to inflate. The owner // will then spin, waiting for the 0 value to disappear. Put another way, // the 0 causes the owner to stall if the owner happens to try to // drop the lock (restoring the header from the BasicLock to the object) // while inflation is in-progress. This protocol avoids races that might // would otherwise permit hashCode values to change or "flicker" for an object. // Critically, while object->mark is 0 mark.displaced_mark_helper() is stable. // 0 serves as a "BUSY" inflate-in-progress indicator. So how does fast-locking avoid hashCode value flickering for an object when there are races between exiting an monitor and inflation? With fast-locking the owner of the monitor does not stall due to an INFLATING value being present in the header so the owner thread will race with the inflating thread. However, unlike with stack-locking, the owner thread in fast-locking is not restoring a saved header value from the BasicLock to the object's header; it is simply changing the `locked_value` to the `unlocked_value` in the lower two bits. If there's a hashCode in the header, then that hashCode remains untouched. The other callers of `read_stable_mark()`: `ObjectSynchronizer::FastHashCode()` - Does not need to stall in `read_stable_mark()` due to a racing inflation because the hashCode value will either be found in the header or in the ObjectMonitor and it will be the same value in both locations. `ObjectSynchronizer::current_thread_holds_lock()` - Does not need to stall in `read_stable_mark()` due to a racing inflation because the current thread either owns the lock or it does not and that state cannot change while the current thread is executing this function. `ObjectSynchronizer::get_lock_owner()` - I think this function does need to stall in `read_stable_mark()` due to a racing inflation. If the calling thread in this case gets a header value where `mark.is_fast_locked() == true`, then it will search the ThreadsList for the thread that has the object on its lock stack. If thread that's inflating the lock is the owner of the lock, then it will remove the object from its lock stack after it has changed the owner in the ObjectMonitor to itself. If that happens before the `get_lock_owner()` calling thread reaches the owning thread in its ThreadsList search, then the `get_lock_owner()` calling thread won't find the owner of the lock. If the `get_lock_owner()` calling thread happens to "know" that the lock is supposed to be owned by _someone_, then the inconsistency could be detected. It might even be possible to write a test to detect this. I'll mull on that a bit... `ObjectSynchronizer::inflate()` - Only calls read_stable_mark() when stack-locking is in use and the `INFLATING()` value is seen. Otherwise, `object->mark_acquire()` is used for the read of the header at the top of the `inflate()` loop and all the code that updates the object's mark use `cas_set_mark()` to only change the object's mark when the current value matches the expected current value. Otherwise, we loop around and try again. src/hotspot/share/runtime/synchronizer.cpp line 1336: > 1334: // Success! Return inflated monitor. > 1335: if (own) { > 1336: assert(current->is_Java_thread(), "must be: checked in is_lock_owned()"); `is_lock_owned()` currently does this: static bool is_lock_owned(Thread* thread, oop obj) { assert(UseFastLocking, "only call this with fast-locking enabled"); return thread->is_Java_thread() ? reinterpret_cast(thread)->lock_stack().contains(obj) : false; } so I would not say "checked in is_locked_owned()" since `is_locked_owned()` does not enforce that the caller is a JavaThread. ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10907 From dcubed at openjdk.org Fri Jan 27 23:31:26 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 27 Jan 2023 23:31:26 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:10:21 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Renaissance >> >> >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Revert UseFastLocking to default to off src/hotspot/share/oops/markWord.hpp line 183: > 181: } > 182: markWord set_fast_locked() const { > 183: return markWord(value() & ~lock_mask_in_place); Perhaps add a comment above L183: // Clear the lock_mask_in_place bits to set locked_value: src/hotspot/share/runtime/lockStack.cpp line 34: > 32: > 33: LockStack::LockStack() : > 34: _base(UseFastLocking && !UseHeavyMonitors ? NEW_C_HEAP_ARRAY(oop, INITIAL_CAPACITY, mtSynchronizer) : NULL), Okay so `UseFastLocking && UseHeavyMonitors`, then we don't need the lock stack. src/hotspot/share/runtime/lockStack.inline.hpp line 81: > 79: } > 80: } > 81: validate("post-contains"); You only do the `validate("post-contains")` call when `false` is returned. Why not also validate for the `true` branch? src/hotspot/share/runtime/objectMonitor.cpp line 1141: > 1139: assert(_recursions == 0, "invariant"); > 1140: set_owner_from_BasicLock(cur, current); // Convert from BasicLock* to Thread*. > 1141: _recursions = 0; Hmmm... fast-locking also has two different ways that a thread can own an ObjectMonitor: 1) owner == thread* and 2) owner == anonymous and lock on the owning thread's lock stack. If `UseFastLocking` is enabled and `ObjectMonitor::exit()` is called by a thread that owns the ObjectMonitor in the secondary way, then this code will fail the assert on L1158 in non-product bits. There needs to be check to see if the current thread owns the fast-lock and then update the owner in the ObjectMonitor after asserting about recursions and resetting recursions to 0. src/hotspot/share/runtime/synchronizer.cpp line 568: > 566: monitor->set_owner_from_anonymous(current); > 567: monitor->exit(current); > 568: } Hmmm... We're in `ObjectSynchronizer::exit()` so we should be the owner of the ObjectMonitor so I'm not yet sure what "Another thread beat us" means. XXX ------------- PR: https://git.openjdk.org/jdk/pull/10907 From cjplummer at openjdk.org Fri Jan 27 23:42:18 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 27 Jan 2023 23:42:18 GMT Subject: RFR: 8298907: nsk JDI tests pass if the debuggee failed to launch In-Reply-To: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> References: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> Message-ID: <2sowZQfp7z2srNHfkuWI4INHswzWcWDALS15uac0DMY=.91bb46ca-b10f-4e52-9096-a2993dd7629d@github.com> On Fri, 27 Jan 2023 23:24:43 GMT, Leonid Mesnik wrote: > Updated run() to return exitCode and make testExitCode non-static to don't use it in run() Thanks for cleaning this up. The changes look good. Did you experiment with any of the tests to make sure an invalid arg passed to the debuggee results in a failure? You can add the arg to the start of `-debugee.vmkeys` in TestDescriptions.java. ------------- PR: https://git.openjdk.org/jdk/pull/12270 From duke at openjdk.org Sat Jan 28 00:37:32 2023 From: duke at openjdk.org (duke) Date: Sat, 28 Jan 2023 00:37:32 GMT Subject: Withdrawn: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11490 From lmesnik at openjdk.org Sat Jan 28 00:47:47 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 28 Jan 2023 00:47:47 GMT Subject: RFR: 8298907: nsk JDI tests pass if the debuggee failed to launch [v2] In-Reply-To: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> References: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> Message-ID: > Updated run() to return exitCode and make testExitCode non-static to don't use it in run() Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: cp updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12270/files - new: https://git.openjdk.org/jdk/pull/12270/files/93d58bac..a6f35d41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12270&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12270&range=00-01 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12270.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12270/head:pull/12270 PR: https://git.openjdk.org/jdk/pull/12270 From lmesnik at openjdk.org Sat Jan 28 00:54:16 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 28 Jan 2023 00:54:16 GMT Subject: RFR: 8298907: nsk JDI tests pass if the debuggee failed to launch [v2] In-Reply-To: <2sowZQfp7z2srNHfkuWI4INHswzWcWDALS15uac0DMY=.91bb46ca-b10f-4e52-9096-a2993dd7629d@github.com> References: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> <2sowZQfp7z2srNHfkuWI4INHswzWcWDALS15uac0DMY=.91bb46ca-b10f-4e52-9096-a2993dd7629d@github.com> Message-ID: On Fri, 27 Jan 2023 23:39:11 GMT, Chris Plummer wrote: > Thanks for cleaning this up. The changes look good. Did you experiment with any of the tests to make sure an invalid arg passed to the debuggee results in a failure? You can add the arg to the start of `-debugee.vmkeys` in TestDescriptions.java. Yes, test fails with # ERROR: ##> debugger: ERROR: Exception : nsk.share.Failure: Caught exception while starting debugee VM: # ERROR: com.sun.jdi.connect.VMStartException: VM initialization failed for: /home/lmesnik/ws/jdk-jdi/build/linux-x64/images/jdk/bin/java -XX:MaxRAMPercentage=1.5625 -Dtest.boot.jdk=/var/tmp/jib-lmesnik/install/jdk/19/36/bundles/linux-x64/jdk-19_l inux-x64_bin.tar.gz/jdk-19 -Djava.io.tmpdir=/home/lmesnik/ws/jdk-jdi/build/linux-x64/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi_DoubleType_itself_doubletype001_TestDescription_java/tmp -XX:NONE -Xdebug -Xrunjdwp:transport=dt_socket,add ress=localhost:48711,suspend=y,includevirtualthreads=y nsk.jdi.DoubleType._itself_.doubletype001a -vbs -verbose -arch=linux-x64 -waittime=5 -debugee.vmkind=java -transport.address=dynamic -debugee.vmkeys="-XX:MaxRAMPercentage=1.5625 -Dtest.boot.jdk=/var/ tmp/jib-lmesnik/install/jdk/19/36/bundles/linux-x64/jdk-19_linux-x64_bin.tar.gz/jdk-19 -Djava.io.tmpdir=/home/lmesnik/ws/jdk-jdi/build/linux-x64/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jdi_DoubleType_itself_doubletype001_TestDescription _java/tmp -XX:NONE" -pipe.port=43001 # ERROR: stdout: # ERROR: stderr: Unrecognized VM option 'NONE' # ERROR: Error: Could not create the Java Virtual Machine. # ERROR: Error: A fatal exception has occurred. Program will exit. ------------- PR: https://git.openjdk.org/jdk/pull/12270 From cjplummer at openjdk.org Sat Jan 28 00:58:18 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 28 Jan 2023 00:58:18 GMT Subject: RFR: 8298907: nsk JDI tests pass if the debuggee failed to launch [v2] In-Reply-To: References: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> Message-ID: On Sat, 28 Jan 2023 00:47:47 GMT, Leonid Mesnik wrote: >> Updated run() to return exitCode and make testExitCode non-static to don't use it in run() > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > cp updated Marked as reviewed by cjplummer (Reviewer). Ok. thanks! ------------- PR: https://git.openjdk.org/jdk/pull/12270 From rriggs at openjdk.org Sat Jan 28 15:13:25 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Sat, 28 Jan 2023 15:13:25 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. It appears that the suggested changes could be include to resume this issue. ------------- PR: https://git.openjdk.org/jdk/pull/11490 From duke at openjdk.org Sat Jan 28 18:38:58 2023 From: duke at openjdk.org (Afshin Zafari) Date: Sat, 28 Jan 2023 18:38:58 GMT Subject: RFR: 8267935: Replace BasicHashtable and Hashtable Message-ID: ### Description Hashtable class to be replaced with ResourceHashtable class in all source code. ### Patch The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. ### Test mach5 tier1 all platforms. ------------- Commit messages: - 8267935: Replace BasicHashtable and Hashtable Changes: https://git.openjdk.org/jdk/pull/12275/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12275&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8267935 Stats: 596 lines in 4 files changed: 0 ins; 596 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12275.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12275/head:pull/12275 PR: https://git.openjdk.org/jdk/pull/12275 From kbarrett at openjdk.org Sun Jan 29 00:10:26 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 29 Jan 2023 00:10:26 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! Changes requested by kbarrett (Reviewer). src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 151: > 149: } > 150: > 151: // Use _thread_saved if cthread is detached from JavaThread (_thread == null). s/null/nullptr/ or s/==/is/ src/hotspot/share/prims/jvmtiImpl.cpp line 125: > 123: GrowableElement *e1 = (GrowableElement *) v; > 124: assert(e1 != nullptr, "e1 != null"); > 125: assert(e2 != nullptr, "e2 != null"); s/null/nullptr/ ? src/hotspot/share/prims/jvmtiImpl.cpp line 162: > 160: GrowableElement* GrowableCache::at(int index) { > 161: GrowableElement *e = (GrowableElement *) _elements->at(index); > 162: assert(e != nullptr, "e != null"); s/null/nullptr/ ? src/hotspot/share/prims/jvmtiImpl.cpp line 180: > 178: void GrowableCache::remove (int index) { > 179: GrowableElement *e = _elements->at(index); > 180: assert(e != nullptr, "e != null"); s/null/nullptr/ ? src/hotspot/share/prims/jvmtiImpl.cpp line 412: > 410: if (_jvmti_breakpoints != nullptr) return (*_jvmti_breakpoints); > 411: _jvmti_breakpoints = new JvmtiBreakpoints(listener_fun); > 412: assert(_jvmti_breakpoints != nullptr, "_jvmti_breakpoints != null"); s/null/nullptr/ ? src/hotspot/share/prims/jvmtiImpl.cpp line 418: > 416: void JvmtiCurrentBreakpoints::listener_fun(void *this_obj, address *cache) { > 417: JvmtiBreakpoints *this_jvmti = (JvmtiBreakpoints *) this_obj; > 418: assert(this_jvmti != nullptr, "this_jvmti != null"); s/null/nullptr/ ? src/hotspot/share/prims/methodHandles.cpp line 1024: > 1022: #define VALUE_COMMA(scope,value) scope::value, > 1023: static const int con_values[con_value_count+1] = { EACH_NAMED_CON(VALUE_COMMA, IGNORE_REQ) 0 }; > 1024: #define STRING_nullptr(scope,value) #value "\0" Should not be changed. src/hotspot/share/prims/methodHandles.cpp line 1025: > 1023: static const int con_values[con_value_count+1] = { EACH_NAMED_CON(VALUE_COMMA, IGNORE_REQ) 0 }; > 1024: #define STRING_nullptr(scope,value) #value "\0" > 1025: static const char con_names[] = { EACH_NAMED_CON(STRING_nullptr, IGNORE_REQ) }; Should not be changed. src/hotspot/share/prims/methodHandles.cpp line 1046: > 1044: #undef ONE_PLUS > 1045: #undef VALUE_COMMA > 1046: #undef STRING_nullptr Should not be changed. src/hotspot/share/prims/upcallLinker.cpp line 100: > 98: > 99: // For the profiler, the last_Java_frame information in thread must always be in > 100: // legal state. We have no last Java frame if last_Java_sp == null so s/null/nullptr/ ? ------------- PR: https://git.openjdk.org/jdk/pull/12188 From dholmes at openjdk.org Sun Jan 29 23:14:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 29 Jan 2023 23:14:16 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: <3nmdxhyFNIRLpS31OeKoSaFicF_j_4irbzcpYLZqWMs=.fb25fb9e-9581-4c60-9e62-9d55912115c7@github.com> References: <-wePcDs-C1SSfQT5MbbWzMjmluh0foXuWdyKzQWMiKA=.f2508b1a-92fe-469c-9749-58c2858d89b1@github.com> <3nmdxhyFNIRLpS31OeKoSaFicF_j_4irbzcpYLZqWMs=.fb25fb9e-9581-4c60-9e62-9d55912115c7@github.com> Message-ID: On Fri, 27 Jan 2023 04:16:05 GMT, Ioi Lam wrote: >>>I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement. >> >> Generally speaking yes - they are both loaded by bootstrap loader and so would both have verification disabled by default. Bt as you note the behaviour can change when CDS is involved and only one class gets dumped. >> >>> But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable. >> >> This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment on why we treat things differently during dumping. > >> > I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement. >> >> Generally speaking yes - they are both loaded by bootstrap loader and so would both have verification disabled by default. Bt as you note the behaviour can change when CDS is involved and only one class gets dumped. >> >> > But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable. >> >> This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment on why we treat things differently during dumping. > > We always enable verification for all classes during -Xshare:dump. That avoid problems where the classes were dumped without verification but at run time you enable verification. I'm not sure of all the implications of always having the stackmap. IIU what @iklam was saying then anyone running with cds enabled will not encounter the reported problem as the stackmap will be present. So these days only when you run without CDS can you encounter the issue. Is that right? ------------- PR: https://git.openjdk.org/jdk/pull/12155 From kevinw at openjdk.org Mon Jan 30 09:15:23 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 30 Jan 2023 09:15:23 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. The suggestions from Chris look good, i.e. the trailing \u0020 were unintentional. ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/11490 From jsjolen at openjdk.org Mon Jan 30 09:30:36 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 09:30:36 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v2] In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: FIx suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12188/files - new: https://git.openjdk.org/jdk/pull/12188/files/aac5b946..b1ff44d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=00-01 Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/12188.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12188/head:pull/12188 PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Mon Jan 30 09:30:38 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 30 Jan 2023 09:30:38 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <7iCZZEs6MIekJQzYFwKnT9eylLVxklFRXQNRa5ayRRQ=.b56fa4c0-9bcb-4e9b-92a7-09358db04790@github.com> On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! Thanks for these review comments, I've fixed your suggestions. I must've accidentally submitted a different branch for tier1 testing, as this doesn't compile. ------------- PR: https://git.openjdk.org/jdk/pull/12188 From rkennke at openjdk.org Mon Jan 30 09:31:24 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 09:31:24 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: <9Igt64_77kxr7GRMRYTJcLFKCsTSQ5zwRPqMhRoJGxo=.0fba3c59-18a7-4621-a4b5-253f499921de@github.com> On Wed, 25 Jan 2023 17:42:23 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert UseFastLocking to default to off > > src/hotspot/share/runtime/objectMonitor.cpp line 1141: > >> 1139: assert(_recursions == 0, "invariant"); >> 1140: set_owner_from_BasicLock(cur, current); // Convert from BasicLock* to Thread*. >> 1141: _recursions = 0; > > Hmmm... fast-locking also has two different ways that a thread can own an > ObjectMonitor: 1) owner == thread* and 2) owner == anonymous and lock on > the owning thread's lock stack. > > If `UseFastLocking` is enabled and `ObjectMonitor::exit()` is called by a thread that > owns the ObjectMonitor in the secondary way, then this code will fail the assert on > L1158 in non-product bits. There needs to be check to see if the current thread owns > the fast-lock and then update the owner in the ObjectMonitor after asserting about > recursions and resetting recursions to 0. With fast-locking, OM::exit() must not be called as long as the owner is ANONYMOUS. The protocol is the following: - T1 fast-locks object O - T2 attempts to lock object O, observes that it is already locked and inflates with ANONYMOUS owner, because it doesn't know who owns the monitor. It then gets in line to acquire the monitor. - When T1 exits, it observes the monitor being owned by ANONYMOUS, and sets the owner to itself, and calls OM::exit(), thereby performing the regular hand-over to T2. - That check for ANONYMOUS owner also needs to be done in the C2 fast-path, and when that happens, it calls into runtime to do the necessary hand-over. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Mon Jan 30 09:43:26 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 09:43:26 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v6] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: 8291555-dcubed-editorial-1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/784b361c..77c8a820 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=04-05 Stats: 116 lines in 4 files changed: 51 ins; 21 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From kevinw at openjdk.org Mon Jan 30 10:26:18 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 30 Jan 2023 10:26:18 GMT Subject: RFR: 8301279: update for deprecated sprintf for management components In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 20:32:35 GMT, Xue-Lei Andrew Fan wrote: > The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components. Looks good to me (sizeof a local char buffer is the number of chars...). ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/12266 From kevinw at openjdk.org Mon Jan 30 10:27:22 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 30 Jan 2023 10:27:22 GMT Subject: RFR: 8298907: nsk JDI tests pass if the debuggee failed to launch [v2] In-Reply-To: References: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> Message-ID: On Sat, 28 Jan 2023 00:47:47 GMT, Leonid Mesnik wrote: >> Updated run() to return exitCode and make testExitCode non-static to don't use it in run() > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > cp updated Looks good 8-) ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/12270 From rkennke at openjdk.org Mon Jan 30 11:10:27 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 11:10:27 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 19:33:16 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: >> >> - Merge branch 'master' into JDK-8291556-v2 >> - Revert UseFastLocking to default to off >> - Change log message inflate(locked) -> inflate(has_locker) >> - Properly set ZF on anon-check path; avoid some conditional branches >> - Use testb when testing for anon owner in fast-path >> - Merge branch 'master' into JDK-8291555-v2 >> - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread >> - x86 part of optimization to check for anon owner >> - Optimize the check-for-anon-owner fast-path >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c > > src/hotspot/share/runtime/synchronizer.cpp line 1301: > >> 1299: // We could always eliminate polling by parking the thread on some auxiliary list. >> 1300: // NOTE: We need to check UseFastLocking here, because with fast-locking, the header >> 1301: // may legitimately be zero: cleared lock-bits and all upper header bits zero. > > The `markWord::INFLATING()` value was picked to be zero because the header could never > be zero except for the inflating case. With fast-locking, in the locked case with no hashcode, > the header can be all zeros. Hmmm... gotta mull on that one... > > fast-locking does not use the `markWord::INFLATING()`, but that protocol exists with the > stack-locking implementation to prevent races. Here's the gory comment from the > "Case stack-locked" portion of `ObjectSynchronizer::inflate()`: > > > // We've successfully installed INFLATING (0) into the mark-word. > // This is the only case where 0 will appear in a mark-word. > // Only the singular thread that successfully swings the mark-word > // to 0 can perform (or more precisely, complete) inflation. > // > // Why do we CAS a 0 into the mark-word instead of just CASing the > // mark-word from the stack-locked value directly to the new inflated state? > // Consider what happens when a thread unlocks a stack-locked object. > // It attempts to use CAS to swing the displaced header value from the > // on-stack BasicLock back into the object header. Recall also that the > // header value (hash code, etc) can reside in (a) the object header, or > // (b) a displaced header associated with the stack-lock, or (c) a displaced > // header in an ObjectMonitor. The inflate() routine must copy the header > // value from the BasicLock on the owner's stack to the ObjectMonitor, all > // the while preserving the hashCode stability invariants. If the owner > // decides to release the lock while the value is 0, the unlock will fail > // and control will eventually pass from slow_exit() to inflate. The owner > // will then spin, waiting for the 0 value to disappear. Put another way, > // the 0 causes the owner to stall if the owner happens to try to > // drop the lock (restoring the header from the BasicLock to the object) > // while inflation is in-progress. This protocol avoids races that might > // would otherwise permit hashCode values to change or "flicker" for an object. > // Critically, while object->mark is 0 mark.displaced_mark_helper() is stable. > // 0 serves as a "BUSY" inflate-in-progress indicator. > > > So how does fast-locking avoid hashCode value flickering for an object > when there are races between exiting an monitor and inflation? With > fast-locking the owner of the monitor does not stall due to an INFLATING > value being present in the header so the owner thread will race with the > inflating thread. However, unlike with stack-locking, the owner thread in > fast-locking is not restoring a saved header value from the BasicLock to > the object's header; it is simply changing the `locked_value` to the > `unlocked_value` in the lower two bits. If there's a hashCode in the header, > then that hashCode remains untouched. > > The other callers of `read_stable_mark()`: > > `ObjectSynchronizer::FastHashCode()` - Does not need to stall in `read_stable_mark()` > due to a racing inflation because the hashCode value will either be found in the header > or in the ObjectMonitor and it will be the same value in both locations. > > `ObjectSynchronizer::current_thread_holds_lock()` - Does not need to stall in > `read_stable_mark()` due to a racing inflation because the current thread > either owns the lock or it does not and that state cannot change while the > current thread is executing this function. > > `ObjectSynchronizer::get_lock_owner()` - I think this function does need to stall > in `read_stable_mark()` due to a racing inflation. If the calling thread in this > case gets a header value where `mark.is_fast_locked() == true`, then it will > search the ThreadsList for the thread that has the object on its lock stack. > If thread that's inflating the lock is the owner of the lock, then it will remove > the object from its lock stack after it has changed the owner in the ObjectMonitor > to itself. If that happens before the `get_lock_owner()` calling thread reaches > the owning thread in its ThreadsList search, then the `get_lock_owner()` calling > thread won't find the owner of the lock. > > If the `get_lock_owner()` calling thread happens to "know" that the lock is > supposed to be owned by _someone_, then the inconsistency could be detected. > It might even be possible to write a test to detect this. I'll mull on that a bit... > > `ObjectSynchronizer::inflate()` - Only calls read_stable_mark() when stack-locking > is in use and the `INFLATING()` value is seen. > > Otherwise, `object->mark_acquire()` is used for the read of the header at the top > of the `inflate()` loop and all the code that updates the object's mark use > `cas_set_mark()` to only change the object's mark when the current value matches > the expected current value. Otherwise, we loop around and try again. I don't think hashCode could flicker: the hashcode is store either in the header OR in the OM, but never in both. Except during inflation, in which case the CAS will ensure that the hash-code is stable (if it changes from 0 to N, then the CAS will fail and inflation will try again. An aside: With fast-locking we will be able to install and access the i-hash without inflation. However, in this case we *do* need to ensure that the i-hash will not flicker: In the case of an inflated monitor, we would have to install the i-hash into the OM displaced header, but this creates a race: meanwhile the OM could be deflated, and another thread could observe a 0 hash, and install a new i-hash into the real header. An easy way out would be to generate the i-hash from the object address, which doesn't change between safepoints. Regarding `get_lock_owner()`, there is a deeper problem IMO: The only caller of this method that is not guaranteed to be at a safepoint is `jmm_GetThreadInfo()` in `management.cpp`. However, this is not really safe to begin with: threads would always race to enter and exit monitors (no matter if they are stack-locked, fast-locked or monitor-locked). Therefore the lock-owner reported there cannot be more than informational. If we want this to be reliable, we should query the lock ownerships at safepoint only, in which case the problem that you describes dispappears. For the time being, I think we may report null lock owner there, pretty much like we could currently do with stack-locked or monitor-locked objects. Please correct me if I am wrong. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From kevinw at openjdk.org Mon Jan 30 11:50:24 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 30 Jan 2023 11:50:24 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> References: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> Message-ID: On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls wrote: >> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. >> javax.management.Attribute and AttributeList classes are also needed, and Query related classes. >> >> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - filter properties update: more classes logged as ALLOWED during wider testing > - Add a Notification test Thanks Daniel. Yes, one problem is that tests were passing with the more restrictive filter. With the test update here, at least we have a failure with the too-restrictive filter and a pass with this change. JCK: api/javax_management/ also looks good. ------------- PR: https://git.openjdk.org/jdk20/pull/97 From coleenp at openjdk.org Mon Jan 30 13:58:16 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 30 Jan 2023 13:58:16 GMT Subject: RFR: 8267935: Replace BasicHashtable and Hashtable In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 18:32:31 GMT, Afshin Zafari wrote: > ### Description > Hashtable class to be replaced with ResourceHashtable class in all source code. > > ### Patch > The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. > The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. > > ### Test > mach5 tier1 all platforms. Great! thank you! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/12275 From rkennke at openjdk.org Mon Jan 30 14:33:28 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 14:33:28 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 20:02:35 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert UseFastLocking to default to off > > src/hotspot/share/oops/markWord.hpp line 183: > >> 181: } >> 182: markWord set_fast_locked() const { >> 183: return markWord(value() & ~lock_mask_in_place); > > Perhaps add a comment above L183: > > // Clear the lock_mask_in_place bits to set locked_value: Ok, I'm doing that. > src/hotspot/share/runtime/lockStack.cpp line 34: > >> 32: >> 33: LockStack::LockStack() : >> 34: _base(UseFastLocking && !UseHeavyMonitors ? NEW_C_HEAP_ARRAY(oop, INITIAL_CAPACITY, mtSynchronizer) : NULL), > > Okay so `UseFastLocking && UseHeavyMonitors`, then we don't need the lock stack. Yeah if we do UseHeavyMonitors, we only ever lock using monitors. It probably makes sense to reject the combination of flags? OTOH, -UseFastLocking (currently implicit, using stack-locking) && +UseHeavyMonitors would not complain? Seems odd, too. > src/hotspot/share/runtime/lockStack.inline.hpp line 81: > >> 79: } >> 80: } >> 81: validate("post-contains"); > > You only do the `validate("post-contains")` call when `false` is > returned. Why not also validate for the `true` branch? Good point. I am adding the validate call there, too. > src/hotspot/share/runtime/synchronizer.cpp line 568: > >> 566: monitor->set_owner_from_anonymous(current); >> 567: monitor->exit(current); >> 568: } > > Hmmm... We're in `ObjectSynchronizer::exit()` so we should be the owner of > the ObjectMonitor so I'm not yet sure what "Another thread beat us" means. > > XXX See above. 'another thread beat us' refers to the preceding CAS, which can fail if another thread inflated the monitor. I am rephrasing it to be more clear (hopefully). ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Mon Jan 30 14:33:35 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 14:33:35 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v5] In-Reply-To: References: Message-ID: <-ImSJ7DFBeTtKn-R9IJcFE8wreHtVHYxWBv743xPa8s=.6ced1034-d7e1-4e23-a53d-81cbda44361a@github.com> On Fri, 27 Jan 2023 20:50:32 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits: >> >> - Merge branch 'master' into JDK-8291556-v2 >> - Revert UseFastLocking to default to off >> - Change log message inflate(locked) -> inflate(has_locker) >> - Properly set ZF on anon-check path; avoid some conditional branches >> - Use testb when testing for anon owner in fast-path >> - Merge branch 'master' into JDK-8291555-v2 >> - In x86_32 C2 fast_lock(), CAS thread directly, instead of CASing stack-pointer and then storing thread >> - x86 part of optimization to check for anon owner >> - Optimize the check-for-anon-owner fast-path >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - ... and 76 more: https://git.openjdk.org/jdk/compare/da80e7a4...784b361c > > src/hotspot/share/runtime/synchronizer.cpp line 1336: > >> 1334: // Success! Return inflated monitor. >> 1335: if (own) { >> 1336: assert(current->is_Java_thread(), "must be: checked in is_lock_owned()"); > > `is_lock_owned()` currently does this: > > > static bool is_lock_owned(Thread* thread, oop obj) { > assert(UseFastLocking, "only call this with fast-locking enabled"); > return thread->is_Java_thread() ? reinterpret_cast(thread)->lock_stack().contains(obj) : false; > } > > > so I would not say "checked in is_locked_owned()" since `is_locked_owned()` does > not enforce that the caller is a JavaThread. If it's not a Java thread, `is_lock_owned()` returns `false`, and we wouldn't end up in the `if (own)` branch. ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Mon Jan 30 14:39:20 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 14:39:20 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v4] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 13:45:35 GMT, Robbin Ehn wrote: > > > I always change the flags in code for the reasons David state and I can't forget to add any flags. > > > (Test batch is stilling running, no failures except MonitorInflationTest.java) > > > > > > Ok, right. > > I just re-ran tier1-3 with the flag changed in code, on aarch64 and x86_64 without regressions. Will run tier4 overnight. > > I did a bigger batch of testing, there were some ThreadMXBean failures with wrong state. I'll investigate, otherwise passed. Thanks, Robbin, for running the tests. Can you let me know which tests failed, so that I can investigate myself? Thanks, Roman ------------- PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Mon Jan 30 14:45:55 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 30 Jan 2023 14:45:55 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v7] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is grown when needed. This means that we need to check for potential overflow before attempting locking. When that is the case, locking fast-paths would call into the runtime to grow the stack and handle the locking. Compiled fast-paths (C1 and C2 on x86_64 and aarch64) do this check on method entry to avoid (possibly lots) of such checks at locking sites. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Renaissance > > > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11444.511 | 11606.66 | -1.40% | ? | 11382.594 | 11638.036 | -2.19% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 9898.1 | 10097.867 | -1.98% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2527.228 | 2564.667 | -1.46% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Daniel's suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/77c8a820..bbe8c186 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=05-06 Stats: 4 lines in 3 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From xuelei at openjdk.org Mon Jan 30 15:12:17 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 30 Jan 2023 15:12:17 GMT Subject: RFR: 8301279: update for deprecated sprintf for management components In-Reply-To: References: Message-ID: On Mon, 30 Jan 2023 10:23:02 GMT, Kevin Walls wrote: >> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in management components. > > Looks good to me (sizeof a local char buffer is the number of chars...). @kevinjwalls Thank you for the code review. ------------- PR: https://git.openjdk.org/jdk/pull/12266 From rehn at openjdk.org Mon Jan 30 15:26:17 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 30 Jan 2023 15:26:17 GMT Subject: RFR: 8267935: Replace BasicHashtable and Hashtable In-Reply-To: References: Message-ID: <8XLr8Mx75HEpUQ54srTKJaA8gwyAIbNhG5qzDQxTvdQ=.edb92989-96a3-42ef-a383-131852f7be65@github.com> On Sat, 28 Jan 2023 18:32:31 GMT, Afshin Zafari wrote: > ### Description > Hashtable class to be replaced with ResourceHashtable class in all source code. > > ### Patch > The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. > The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. > > ### Test > mach5 tier1 all platforms. Thank you! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12275 From dfuchs at openjdk.org Mon Jan 30 15:33:19 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 30 Jan 2023 15:33:19 GMT Subject: RFR: 8299234: JMX Repository.query performance [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 20:25:17 GMT, Alexey Bakhtin wrote: >> Please find a patch to improve JMX Repository.query performance >> >> Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: >> Before: >> >> $ java test 1000000 1000000 >> Test PASSED in 8943169791 ns. >> GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 >> >> >> After: >> >> $ java test 1000000 1000000 >> Test PASSED in 4808213917 ns. >> GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 >> >> Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. >> >> All javax/management jtreg tests passed successfully. > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes in the ObjectName I don't see an obvious issue with the proposed changes. Do you have a JMH benchmark to prove the new code is faster? Also please obtain a review from a maintainer of the servicieability area before integrating. ------------- PR: https://git.openjdk.org/jdk/pull/11758 From tschatzl at openjdk.org Mon Jan 30 16:23:17 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 30 Jan 2023 16:23:17 GMT Subject: RFR: 8267935: Replace BasicHashtable and Hashtable In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 18:32:31 GMT, Afshin Zafari wrote: > ### Description > Hashtable class to be replaced with ResourceHashtable class in all source code. > > ### Patch > The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. > The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. > > ### Test > mach5 tier1 all platforms. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12275 From duke at openjdk.org Mon Jan 30 16:26:35 2023 From: duke at openjdk.org (Afshin Zafari) Date: Mon, 30 Jan 2023 16:26:35 GMT Subject: Integrated: 8267935: Replace BasicHashtable and Hashtable In-Reply-To: References: Message-ID: On Sat, 28 Jan 2023 18:32:31 GMT, Afshin Zafari wrote: > ### Description > Hashtable class to be replaced with ResourceHashtable class in all source code. > > ### Patch > The only instance was `#include "hashtable.hpp"` in `jvmtiTagMapTable.cpp` and removed. > The corresponding files (`hashtable.hpp`, `hashtable.inline.hpp` and `hashtable.cpp`) are removed too. > > ### Test > mach5 tier1 all platforms. This pull request has now been integrated. Changeset: f4592b14 Author: Afshin Zafari Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f4592b1471dff02f4e5e21da00c19b957b0a944b Stats: 596 lines in 4 files changed: 0 ins; 596 del; 0 mod 8267935: Replace BasicHashtable and Hashtable Reviewed-by: coleenp, rehn, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/12275 From kbarrett at openjdk.org Mon Jan 30 16:32:19 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 30 Jan 2023 16:32:19 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v2] In-Reply-To: References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: On Mon, 30 Jan 2023 09:30:36 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we >> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. >> >> Here are some typical things to look out for: >> >> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). >> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. >> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. >> >> An example of this: >> >> ```c++ >> // This function returns null >> void* ret_null(); >> // This function returns true if *x == nullptr >> bool is_nullptr(void** x); >> >> >> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > FIx suggested changes Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/12188 From lmesnik at openjdk.org Mon Jan 30 17:36:25 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 30 Jan 2023 17:36:25 GMT Subject: Integrated: 8298907: nsk JDI tests pass if the debuggee failed to launch In-Reply-To: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> References: <_Q8ul_95VzLEjOCNowX8P6wVc763MH5KdDkNWl37BhA=.b966ca67-5a60-4584-a887-d4a921dc8d19@github.com> Message-ID: <7zgTIi5CeNHO_qXSUVNK1wVmoEmLwKytxfDUTf7fpRs=.b7100143-6a15-4c5a-b43a-a95a92b41a0b@github.com> On Fri, 27 Jan 2023 23:24:43 GMT, Leonid Mesnik wrote: > Updated run() to return exitCode and make testExitCode non-static to don't use it in run() This pull request has now been integrated. Changeset: a91143cc Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/a91143cc93fe3810ecca4b04c9f81c1b967db0ed Stats: 372 lines in 186 files changed: 0 ins; 0 del; 372 mod 8298907: nsk JDI tests pass if the debuggee failed to launch Reviewed-by: cjplummer, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/12270 From cjplummer at openjdk.org Mon Jan 30 19:11:13 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 30 Jan 2023 19:11:13 GMT Subject: Integrated: 8300810: Get rid of unused JDI removeListener() methods In-Reply-To: References: Message-ID: <-tA8_agVxlaQc4Cj12MmLVF6gOIRNUvR1WV0yvW1C7M=.281fffb2-7049-4a4b-8790-cc0fcb784ea4@github.com> On Mon, 23 Jan 2023 20:58:20 GMT, Chris Plummer wrote: > Remove removeListener() methods. They are not called. This pull request has now been integrated. Changeset: a128a5d0 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/a128a5d07c3b5d710316aab0c02ccaec4872dc22 Stats: 26 lines in 2 files changed: 0 ins; 24 del; 2 mod 8300810: Get rid of unused JDI removeListener() methods Reviewed-by: kevinw, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/12151 From cjplummer at openjdk.org Mon Jan 30 19:11:56 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 30 Jan 2023 19:11:56 GMT Subject: RFR: 8300811: jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 21:02:51 GMT, Chris Plummer wrote: > jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all created threads. It creates them with the SUSPEND_ALL policy. This is unnecessary since jdb always immediately resumes all threads after doing the thread bookkeeping. There is no interaction with the jdb user like there would be with something like a Breakpoint event, and therefore no reason to suspend. > > I was debugging an app that does nothing except create threads and allow them to quickly exit. Changing the policy to SUSPEND_NONE sped up the execution of the app by about 100x (that's 100 times faster, not 100%) Ping! I could still use two reviews. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/12152 From alanb at openjdk.org Mon Jan 30 19:16:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 30 Jan 2023 19:16:54 GMT Subject: RFR: 8300811: jdb ThreadStartRequest and ThreadDeathRequest should use SUSPEND_NONE instead of SUSPEND_ALL In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 21:02:51 GMT, Chris Plummer wrote: > jdb creates a ThreadStartRequest and ThreadDeathRequest so it can track all created threads. It creates them with the SUSPEND_ALL policy. This is unnecessary since jdb always immediately resumes all threads after doing the thread bookkeeping. There is no interaction with the jdb user like there would be with something like a Breakpoint event, and therefore no reason to suspend. > > I was debugging an app that does nothing except create threads and allow them to quickly exit. Changing the policy to SUSPEND_NONE sped up the execution of the app by about 100x (that's 100 times faster, not 100%) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/12152 From cjplummer at openjdk.org Mon Jan 30 19:24:27 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 30 Jan 2023 19:24:27 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> References: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> Message-ID: On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls wrote: >> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. >> javax.management.Attribute and AttributeList classes are also needed, and Query related classes. >> >> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - filter properties update: more classes logged as ALLOWED during wider testing > - Add a Notification test src/jdk.management.agent/share/conf/management.properties line 323: > 321: java.rmi.dgc.*;\ > 322: java.rmi.server.*;\ > 323: javax.security.auth.Subject;!* What does the ! at the end indicate? ------------- PR: https://git.openjdk.org/jdk20/pull/97 From duke at openjdk.org Mon Jan 30 20:03:58 2023 From: duke at openjdk.org (Egor Ushakov) Date: Mon, 30 Jan 2023 20:03:58 GMT Subject: RFR: 8297638: Memory leak in case of many started-dead threads [v2] In-Reply-To: <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com> References: <0R9vbkkJyHw0-SJ1gXbFFxkkK33Tv7ZGg9rMFCyl5rY=.12890e1c-03e0-4aba-adbf-19ab174aa384@github.com> <6A-Igi24IpuNPsjq1vJMscoKvujmMvYqDuMq6BncUsI=.9102a5c7-2f90-444c-b79a-00cb82b809bb@github.com> Message-ID: On Thu, 19 Jan 2023 21:59:22 GMT, Chris Plummer wrote: >> Fix JDI leak when the debuggee creates a lot of threads, while at the same the debugger is not sending any commands. The lack of commands being sent results in code not being triggered that normally would clear out unreachable listeners and also clear out ObjectReferences queued for disposal. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Cleaned up removeUnreachableListeners(). looks good to me, thanks ------------- Marked as reviewed by gorrus at github.com (no known OpenJDK username). PR: https://git.openjdk.org/jdk/pull/12081 From kevinw at openjdk.org Mon Jan 30 20:14:10 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 30 Jan 2023 20:14:10 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: References: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> Message-ID: On Mon, 30 Jan 2023 19:21:37 GMT, Chris Plummer wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - filter properties update: more classes logged as ALLOWED during wider testing >> - Add a Notification test > > src/jdk.management.agent/share/conf/management.properties line 323: > >> 321: java.rmi.dgc.*;\ >> 322: java.rmi.server.*;\ >> 323: javax.security.auth.Subject;!* > > What does the ! at the end indicate? It's "not everything else". https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html "If a class name doesn?t match any filter, then it is allowed. If you want to allow only certain class names, then your filter must reject everything that doesn?t match. To reject all class names other than those specified, include !* as the last pattern in a class filter." ------------- PR: https://git.openjdk.org/jdk20/pull/97 From amenkov at openjdk.org Mon Jan 30 20:14:57 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 30 Jan 2023 20:14:57 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: <3nmdxhyFNIRLpS31OeKoSaFicF_j_4irbzcpYLZqWMs=.fb25fb9e-9581-4c60-9e62-9d55912115c7@github.com> References: <-wePcDs-C1SSfQT5MbbWzMjmluh0foXuWdyKzQWMiKA=.f2508b1a-92fe-469c-9749-58c2858d89b1@github.com> <3nmdxhyFNIRLpS31OeKoSaFicF_j_4irbzcpYLZqWMs=.fb25fb9e-9581-4c60-9e62-9d55912115c7@github.com> Message-ID: On Fri, 27 Jan 2023 04:16:05 GMT, Ioi Lam wrote: >>>I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement. >> >> Generally speaking yes - they are both loaded by bootstrap loader and so would both have verification disabled by default. Bt as you note the behaviour can change when CDS is involved and only one class gets dumped. >> >>> But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable. >> >> This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment on why we treat things differently during dumping. > >> > I'd expect that at least java.util.Date and java.lang.ProcessBuilder have the same verification requirement. >> >> Generally speaking yes - they are both loaded by bootstrap loader and so would both have verification disabled by default. Bt as you note the behaviour can change when CDS is involved and only one class gets dumped. >> >> > But in Date has StackMapTable (starting from JDK12-b15), and ProcessBuilder doesn't has StackMapTable. >> >> This seems odd, but not, IMO, in itself a bug. Perhaps @iklam can comment on why we treat things differently during dumping. > > We always enable verification for all classes during -Xshare:dump. That avoid problems where the classes were dumped without verification but at run time you enable verification. > I'm not sure of all the implications of always having the stackmap. IIU what @iklam was saying then anyone running with cds enabled will not encounter the reported problem as the stackmap will be present. So these days only when you run without CDS can you encounter the issue. Is that right? No. Not all JDK classes are dumped to CDS archive (for example java.lang.ProcessBuilder is not). And this is why I think it makes sense to simplify the things. - application classes have stackmaps (they require verification); - classes from CDS have stackmaps; - jdk classes not dumped to CDS _do not_ have stackmaps (elided by classParser) ------------- PR: https://git.openjdk.org/jdk/pull/12155 From sspitsyn at openjdk.org Mon Jan 30 20:29:06 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 30 Jan 2023 20:29:06 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> References: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> Message-ID: On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls wrote: >> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. >> javax.management.Attribute and AttributeList classes are also needed, and Query related classes. >> >> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - filter properties update: more classes logged as ALLOWED during wider testing > - Add a Notification test This fix looks okay to me. One nit was inlined. Thanks, Serguei test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java line 150: > 148: String description = "An attribute of this MBean has changed"; > 149: MBeanNotificationInfo info = new MBeanNotificationInfo(types, name, description); > 150: return new MBeanNotificationInfo[] {info}; Nit: It can be useful to print that this method was invoked the same as in other methods. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk20/pull/97 From cjplummer at openjdk.org Mon Jan 30 21:24:04 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 30 Jan 2023 21:24:04 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: References: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> Message-ID: On Mon, 30 Jan 2023 20:11:06 GMT, Kevin Walls wrote: >> src/jdk.management.agent/share/conf/management.properties line 323: >> >>> 321: java.rmi.dgc.*;\ >>> 322: java.rmi.server.*;\ >>> 323: javax.security.auth.Subject;!* >> >> What does the ! at the end indicate? > > It's "not everything else". > > https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html > > "If a class name doesn?t match any filter, then it is allowed. If you want to allow only certain class names, then your filter must reject everything that doesn?t match. To reject all class names other than those specified, include !* as the last pattern in a class filter." Ok. It would be good to clarify that in the comment above this filter. Also, maybe put it on a new line. Otherwise at first glance it appears to have a relationship to the class immediately before it. Does this mean that this filter list would serve no purpose if the !* was omitted? I'm just curious as to why the !* is needed rather than it just being default behavior that a class has to match a filter in the list. ------------- PR: https://git.openjdk.org/jdk20/pull/97 From dholmes at openjdk.org Tue Jan 31 02:26:02 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 02:26:02 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v2] In-Reply-To: References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: On Mon, 30 Jan 2023 09:30:36 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we >> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. >> >> Here are some typical things to look out for: >> >> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). >> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. >> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. >> >> An example of this: >> >> ```c++ >> // This function returns null >> void* ret_null(); >> // This function returns true if *x == nullptr >> bool is_nullptr(void** x); >> >> >> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > FIx suggested changes A few adjustments but overall looks good. Thanks. src/hotspot/share/prims/jni.cpp line 2166: > 2164: bool is_latin1 = java_lang_String::is_latin1(s); > 2165: buf = NEW_C_HEAP_ARRAY_RETURN_NULL(jchar, s_len + 1, mtInternal); // add one for zero termination > 2166: /* JNI Specification states return nullptr on OOM */ null src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp line 56: > 54: // collector.collect(); > 55: // JvmtiCodeBlobDesc* blob = collector.first(); > 56: // while (blob != null) { nullptr src/hotspot/share/prims/jvmtiEnv.cpp line 581: > 579: > 580: if (event_thread == nullptr) { > 581: // Can be called at Agent_OnLoad() time with event_thread == null nullptr src/hotspot/share/prims/jvmtiEnvBase.hpp line 170: > 168: }; > 169: > 170: // If (thread == null) then return current thread object. nullptr src/hotspot/share/prims/jvmtiEnvBase.hpp line 184: > 182: oop cur_obj = current->jvmti_vthread(); > 183: > 184: // cur_obj == null is true for normal platform threads only nullptr src/hotspot/share/prims/jvmtiEventController.hpp line 214: > 212: > 213: // Use (thread == null) to enable/disable an event globally. > 214: // Use (thread != null) to enable/disable an event for a particular thread. nullptr ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/12188 From dholmes at openjdk.org Tue Jan 31 04:53:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 31 Jan 2023 04:53:55 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > classFileParser drops stack map frames for JDK classes (when verification is not required). > As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. > Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. > This code is old (from "initial load") and I don't understand the reason it was implemented this way. > > Testing: tier1-tier6 I asked within runtime team if there were any concerns about keeping the stackmap table in all cases and there were not. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/libMissedStackMapFrames.cpp line 29: > 27: #include > 28: > 29: static void _log(const char* format, ...) { Why do you need this instead of just calling printf? ------------- PR: https://git.openjdk.org/jdk/pull/12155 From alanb at openjdk.org Tue Jan 31 07:41:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 31 Jan 2023 07:41:55 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 00:16:10 GMT, Alex Menkov wrote: > classFileParser drops stack map frames for JDK classes (when verification is not required). > As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. > Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. > This code is old (from "initial load") and I don't understand the reason it was implemented this way. > > Testing: tier1-tier6 @forax can you provide a brief summary on ASM behavior when modifying a class class that doesn't have the StackMapTable. I guess I would assume that an agent/tool modifying a class would require it to be regenerated. ------------- PR: https://git.openjdk.org/jdk/pull/12155 From jsjolen at openjdk.org Tue Jan 31 09:33:01 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 09:33:01 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v2] In-Reply-To: References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <3zRF1SdYdOEWTkSUPkdwvBNnfpY1KFMnaqDwsbcyTJQ=.ba66944a-bd5c-4afa-8ec9-7ee29d601cdd@github.com> On Mon, 30 Jan 2023 09:30:36 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we >> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. >> >> Here are some typical things to look out for: >> >> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). >> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. >> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. >> >> An example of this: >> >> ```c++ >> // This function returns null >> void* ret_null(); >> // This function returns true if *x == nullptr >> bool is_nullptr(void** x); >> >> >> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > FIx suggested changes All tests passing in GHA. @alexmenkov , would you mind approving :)? ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Tue Jan 31 10:11:34 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 10:11:34 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v3] In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: <6569WN92YSqavxcJePbGqc0fwjfJYKKTBByUnUy0Z7A=.8caf7b50-a106-44af-9739-317589d78350@github.com> > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix dholmes's suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12188/files - new: https://git.openjdk.org/jdk/pull/12188/files/b1ff44d7..c1254818 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12188&range=01-02 Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/12188.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12188/head:pull/12188 PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Tue Jan 31 14:26:29 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 14:26:29 GMT Subject: RFR: JDK-8301076: Replace NULL with nullptr in share/prims/ [v3] In-Reply-To: <6569WN92YSqavxcJePbGqc0fwjfJYKKTBByUnUy0Z7A=.8caf7b50-a106-44af-9739-317589d78350@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> <6569WN92YSqavxcJePbGqc0fwjfJYKKTBByUnUy0Z7A=.8caf7b50-a106-44af-9739-317589d78350@github.com> Message-ID: On Tue, 31 Jan 2023 10:11:34 GMT, Johan Sj?len wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we >> need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. >> >> Here are some typical things to look out for: >> >> 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). >> 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. >> 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. >> >> An example of this: >> >> ```c++ >> // This function returns null >> void* ret_null(); >> // This function returns true if *x == nullptr >> bool is_nullptr(void** x); >> >> >> Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. >> >> Thanks! > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix dholmes's suggested changes Tier1 is passing and this has 2 approvals, I'm integrating. Thank you for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/12188 From jsjolen at openjdk.org Tue Jan 31 14:26:30 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 31 Jan 2023 14:26:30 GMT Subject: Integrated: JDK-8301076: Replace NULL with nullptr in share/prims/ In-Reply-To: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> References: <32x4usaWeapqG5r-6IXEaGdoDoyz2MkmMPFlZ2aFd5k=.b0bf0cad-8cce-4ee0-8593-f5fbef496682@github.com> Message-ID: On Wed, 25 Jan 2023 11:47:05 GMT, Johan Sj?len wrote: > Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory share/prims/. Unfortunately the script that does the change isn't perfect, and so we > need to comb through these manually to make sure nothing has gone wrong. I also review these changes but things slip past my eyes sometimes. > > Here are some typical things to look out for: > > 1. No changes but copyright header changed (probably because I reverted some changes but forgot the copyright). > 2. Macros having their NULL changed to nullptr, these are added to the script when I find them. They should be NULL. > 3. nullptr in comments and logs. We try to use lower case "null" in these cases as it reads better. An exception is made when code expressions are in a comment. > > An example of this: > > ```c++ > // This function returns null > void* ret_null(); > // This function returns true if *x == nullptr > bool is_nullptr(void** x); > > > Note how `nullptr` participates in a code expression here, we really are talking about the specific value `nullptr`. > > Thanks! This pull request has now been integrated. Changeset: b76a52f2 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/b76a52f2104b63e84e5d09f47ce01dd0cb3935d7 Stats: 2037 lines in 47 files changed: 0 ins; 0 del; 2037 mod 8301076: Replace NULL with nullptr in share/prims/ Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/12188 From kevinw at openjdk.org Tue Jan 31 14:29:38 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 31 Jan 2023 14:29:38 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v3] In-Reply-To: References: Message-ID: > The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. > javax.management.Attribute and AttributeList classes are also needed, and Query related classes. > > There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. Kevin Walls has updated the pull request incrementally with three additional commits since the last revision: - Test additional print, and comment edit - properties comment and formatting - Print in getNotificationInfo ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/97/files - new: https://git.openjdk.org/jdk20/pull/97/files/ab81891d..2932611e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=97&range=01-02 Stats: 11 lines in 2 files changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk20/pull/97.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/97/head:pull/97 PR: https://git.openjdk.org/jdk20/pull/97 From kevinw at openjdk.org Tue Jan 31 14:29:38 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 31 Jan 2023 14:29:38 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: References: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> Message-ID: <6YsEK10XRSugXAykEEAOp5BXEGw0MU3qwAFRyHxX2cU=.4ced9485-9f1f-4894-99dc-ef60d1c2f4a2@github.com> On Mon, 30 Jan 2023 21:20:55 GMT, Chris Plummer wrote: >> It's "not everything else". >> >> https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html >> >> "If a class name doesn?t match any filter, then it is allowed. If you want to allow only certain class names, then your filter must reject everything that doesn?t match. To reject all class names other than those specified, include !* as the last pattern in a class filter." > > Ok. It would be good to clarify that in the comment above this filter. Also, maybe put it on a new line. Otherwise at first glance it appears to have a relationship to the class immediately before it. > > Does this mean that this filter list would serve no purpose if the !* was omitted? I'm just curious as to why the !* is needed rather than it just being default behavior that a class has to match a filter in the list. If a class is not matched, it is "undecided", mentioned at the end of the long comment. That is not a rejection, which that existing long comment does not state. For an actual rejection, we need the ! to match, so patterns generally end in !* It's the same or very similar comment as in conf/security/java.security I added a note about the !* at the end to clarify, as it is new to use the filter in this area, and yes put it on a new line. ------------- PR: https://git.openjdk.org/jdk20/pull/97 From kevinw at openjdk.org Tue Jan 31 14:29:43 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 31 Jan 2023 14:29:43 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v2] In-Reply-To: References: <0AwDoxPahaFHt1zFFq2QT0YBdBlvqTzAMf60G695Lec=.a3b8cb03-3781-49c3-8afb-3bb49e4c3e29@github.com> Message-ID: <9wK0cy50AFGG-GaePRXoriVqdcn27bfQTOO7k1WDow4=.eb063ea1-525c-4c12-923e-c078557b8960@github.com> On Mon, 30 Jan 2023 20:24:16 GMT, Serguei Spitsyn wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - filter properties update: more classes logged as ALLOWED during wider testing >> - Add a Notification test > > test/jdk/javax/management/remote/mandatory/connection/DefaultAgentFilterTest.java line 150: > >> 148: String description = "An attribute of this MBean has changed"; >> 149: MBeanNotificationInfo info = new MBeanNotificationInfo(types, name, description); >> 150: return new MBeanNotificationInfo[] {info}; > > Nit: It can be useful to print that this method was invoked the same as in other methods. got it ------------- PR: https://git.openjdk.org/jdk20/pull/97 From jcking at openjdk.org Tue Jan 31 14:40:14 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 14:40:14 GMT Subject: RFR: JDK-8301447: [REDO] CodeHeap has virtual methods that are not overridden Message-ID: Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also fixing the serviceability code. ------------- Commit messages: - Redo removal of virtual methods in CodeHeap Changes: https://git.openjdk.org/jdk/pull/12345/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12345&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301447 Stats: 10 lines in 2 files changed: 0 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/12345.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12345/head:pull/12345 PR: https://git.openjdk.org/jdk/pull/12345 From jcking at openjdk.org Tue Jan 31 14:40:14 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 14:40:14 GMT Subject: RFR: JDK-8301447: [REDO] CodeHeap has virtual methods that are not overridden In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 14:30:29 GMT, Justin King wrote: > Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also fixing the serviceability code. Waiting on GHA to confirm if I fixed the serviceability code correctly. ------------- PR: https://git.openjdk.org/jdk/pull/12345 From kevinw at openjdk.org Tue Jan 31 17:08:03 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 31 Jan 2023 17:08:03 GMT Subject: RFR: 8298966: Deprecate JMX Subject Delegation and the method JMXConnector.getMBeanServerConnection(Subject) for removal. Message-ID: Deprecate the Java Management Extension (JMX) Subject Delegation feature for removal in a future release. Given no known usage, there is no replacement feature for JMX Subject Delegation. CSR is https://bugs.openjdk.org/browse/JDK-8298967 ------------- Commit messages: - 8298966: Deprecate JMX Subject Delegation and the method JMXConnector.getMBeanServerConnection(Subject) for removal. Changes: https://git.openjdk.org/jdk/pull/11880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11880&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298966 Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11880.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11880/head:pull/11880 PR: https://git.openjdk.org/jdk/pull/11880 From jcking at openjdk.org Tue Jan 31 19:52:50 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 19:52:50 GMT Subject: RFR: JDK-8301447: [REDO] CodeHeap has virtual methods that are not overridden In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 14:30:29 GMT, Justin King wrote: > Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also fixing the serviceability code. Looks good this time. ------------- PR: https://git.openjdk.org/jdk/pull/12345 From cjplummer at openjdk.org Tue Jan 31 20:13:09 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 31 Jan 2023 20:13:09 GMT Subject: [jdk20] RFR: 8299891: JMX ObjectInputFilter additional classes needed [v3] In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 14:29:38 GMT, Kevin Walls wrote: >> The default setting for the ObjectInputFilter for JMX, introduced in jdk20, is too restrictive. >> javax.management.Attribute and AttributeList classes are also needed, and Query related classes. >> >> There are a number of Query-related classes, so adding javax.management.* is appropriate otherwise the list becomes hard to manage. This is a * and not a ** which would mean all subpackages, so the openmean subpackage stays in the list. > > Kevin Walls has updated the pull request incrementally with three additional commits since the last revision: > > - Test additional print, and comment edit > - properties comment and formatting > - Print in getNotificationInfo Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/97 From kvn at openjdk.org Tue Jan 31 20:33:50 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 31 Jan 2023 20:33:50 GMT Subject: RFR: JDK-8301447: [REDO] CodeHeap has virtual methods that are not overridden In-Reply-To: References: Message-ID: <2i5vTHxZpz-EUBEv2VMkP9AS4AVvYlTyZaQI7xeUTcw=.1a345994-c137-481b-a176-de6cb6305484@github.com> On Tue, 31 Jan 2023 14:30:29 GMT, Justin King wrote: > Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also fixing the serviceability code. Good. But someone in Oracle have to test it before you push. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12345 From jcking at openjdk.org Tue Jan 31 20:41:51 2023 From: jcking at openjdk.org (Justin King) Date: Tue, 31 Jan 2023 20:41:51 GMT Subject: RFR: JDK-8301447: [REDO] CodeHeap has virtual methods that are not overridden In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 14:30:29 GMT, Justin King wrote: > Redo [JDK-8301378](https://bugs.openjdk.org/browse/JDK-8301378), this time also fixing the serviceability code. Cannot directly commit, so I will request integration and let prospective sponsors do any additional testing before sponsoring. ------------- PR: https://git.openjdk.org/jdk/pull/12345 From amenkov at openjdk.org Tue Jan 31 23:08:50 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 31 Jan 2023 23:08:50 GMT Subject: RFR: 8228604: StackMapFrames are missing from redefined class bytes of retransformed classes In-Reply-To: References: Message-ID: On Tue, 31 Jan 2023 04:48:45 GMT, David Holmes wrote: >> classFileParser drops stack map frames for JDK classes (when verification is not required). >> As a result JvmtiClassFileReconstituter cannot restore the attribute for class redefinition. >> Note that if the class is in CDS archive, the frames are restored from CDS, so this issue affects only JDK classes which are not in CDS. >> This code is old (from "initial load") and I don't understand the reason it was implemented this way. >> >> Testing: tier1-tier6 > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/libMissedStackMapFrames.cpp line 29: > >> 27: #include >> 28: >> 29: static void _log(const char* format, ...) { > > Why do you need this instead of just calling printf? It also flushes the output stream to avoid possible mix with output of java part of the test ------------- PR: https://git.openjdk.org/jdk/pull/12155 From sspitsyn at openjdk.org Tue Jan 31 23:56:51 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 31 Jan 2023 23:56:51 GMT Subject: RFR: 8298979: Remove duplicated serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java [v2] In-Reply-To: References: <7N18GctUO6Kt5_VJe5lJBV-ga-jZv-z9vtnh99dKHZo=.390887cd-5af8-4a61-bd2c-b4b5f74353e8@github.com> Message-ID: On Fri, 27 Jan 2023 05:20:28 GMT, Leonid Mesnik wrote: >> PR adds fix "8284027: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/ is failing" to new test and remove duplication. >> >> Test allthr002 ported as >> serviceability/jvmti/negative/GetAllThreadsNullTest/GetAllThreadsNullTest.java > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - cleanup > - used get_thread_name The fix looks good to me. It is nice to remove the duplication. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/12240