From duke at openjdk.org Mon Aug 1 04:58:49 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Aug 2022 04:58:49 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: - Add assertions - Fix marked logic - Erik refactorings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/f77f44eb..5d26ab8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=00-01 Stats: 339 lines in 14 files changed: 85 ins; 144 del; 110 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From duke at openjdk.org Mon Aug 1 06:53:38 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Mon, 1 Aug 2022 06:53:38 GMT Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows platform [v2] In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 07:41:42 GMT, Serguei Spitsyn wrote: >> @sspitsyn >> Thank you for your review. Coud you integrate this fix, please? > > @tkiriyama Normally, two reviews are required in Serviceability area. @sspitsyn Can I ask you again to integrate this fix? ------------- PR: https://git.openjdk.org/jdk/pull/9549 From alanb at openjdk.org Mon Aug 1 07:22:35 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Aug 2022 07:22:35 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 16:11:12 GMT, Ao Qi wrote: > `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti". > > The issue could be reproduced by zero. For the XMLDecoder tests then I think the issue is that it's using the 1-arg Class.forName rather than the 3-arg Class.forName. Can you try this: diff --git a/test/jdk/java/beans/XMLDecoder/8028054/Task.java b/test/jdk/java/beans/XMLDecoder/8028054/Task.java index 1d55fa8e358..add48336d16 100644 --- a/test/jdk/java/beans/XMLDecoder/8028054/Task.java +++ b/test/jdk/java/beans/XMLDecoder/8028054/Task.java @@ -130,8 +130,9 @@ abstract class Task implements Runnable { .map(s -> s.substring(s.indexOf("java"))) .collect(Collectors.toList()); + ClassLoader scl = ClassLoader.getSystemClassLoader(); for (String name : fileNames) { - classes.add(Class.forName(name)); + classes.add(Class.forName(name, false, scl)); if (count == classes.size()) { break; } ------------- PR: https://git.openjdk.org/jdk/pull/9677 From sspitsyn at openjdk.org Mon Aug 1 08:16:33 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 1 Aug 2022 08:16:33 GMT Subject: RFR: 8290497: some tests in com/sun/jdi fail on localized Windows platform [v2] In-Reply-To: References: Message-ID: <242fMLhOfuOetmXzjh62jRknGs7rONTdXbybViyAizg=.0b8f1333-90a9-48f5-8cc6-6bce8d08067e@github.com> On Mon, 1 Aug 2022 06:51:28 GMT, KIRIYAMA Takuya wrote: >> @tkiriyama Normally, two reviews are required in Serviceability area. > > @sspitsyn > Can I ask you again to integrate this fix? @tkiriyama I've sponsored your fix. It will be integrated now, I hope. ------------- PR: https://git.openjdk.org/jdk/pull/9549 From duke at openjdk.org Mon Aug 1 08:16:35 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Mon, 1 Aug 2022 08:16:35 GMT Subject: Integrated: 8290497: some tests in com/sun/jdi fail on localized Windows platform In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 06:30:09 GMT, KIRIYAMA Takuya wrote: > Failed tests call java.lang.ProcessBuilder in direct, so not used command options specified when jtreg command run. > To run non-localized tests, the locale options should be added in ProcessBuilder. > > Could you review this fix, please? This pull request has now been integrated. Changeset: d61c0c79 Author: KIRIYAMA Takuya Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/d61c0c79cf9d7bc038efab0fdfe1a306f2b0e0b7 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod 8290497: some tests in com/sun/jdi fail on localized Windows platform Reviewed-by: sspitsyn, cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9549 From aoqi at openjdk.org Mon Aug 1 12:02:02 2022 From: aoqi at openjdk.org (Ao Qi) Date: Mon, 1 Aug 2022 12:02:02 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" [v2] In-Reply-To: References: Message-ID: > `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti". > > The issue could be reproduced by zero. Ao Qi has updated the pull request incrementally with one additional commit since the last revision: XMLDecoder update Co-authored-by: Alan Bateman ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9677/files - new: https://git.openjdk.org/jdk/pull/9677/files/c16a0b87..623e3723 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=00-01 Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9677.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9677/head:pull/9677 PR: https://git.openjdk.org/jdk/pull/9677 From aoqi at openjdk.org Mon Aug 1 12:04:41 2022 From: aoqi at openjdk.org (Ao Qi) Date: Mon, 1 Aug 2022 12:04:41 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 07:18:52 GMT, Alan Bateman wrote: >> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti". >> >> The issue could be reproduced by zero. > > For the XMLDecoder tests then I think the issue is that it's using the 1-arg Class.forName rather than the 3-arg Class.forName. Can you try this: > > > diff --git a/test/jdk/java/beans/XMLDecoder/8028054/Task.java b/test/jdk/java/beans/XMLDecoder/8028054/Task.java > index 1d55fa8e358..add48336d16 100644 > --- a/test/jdk/java/beans/XMLDecoder/8028054/Task.java > +++ b/test/jdk/java/beans/XMLDecoder/8028054/Task.java > @@ -130,8 +130,9 @@ abstract class Task implements Runnable { > .map(s -> s.substring(s.indexOf("java"))) > .collect(Collectors.toList()); > > + ClassLoader scl = ClassLoader.getSystemClassLoader(); > for (String name : fileNames) { > - classes.add(Class.forName(name)); > + classes.add(Class.forName(name, false, scl)); > if (count == classes.size()) { > break; > } Hi @AlanBateman , your method works. It is a much better way. Thank you very much! Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two? ------------- PR: https://git.openjdk.org/jdk/pull/9677 From alanb at openjdk.org Mon Aug 1 12:45:28 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Aug 2022 12:45:28 GMT Subject: [jdk19] RFR: 8290562: ThreadMXBean.getThread{Cpu, User}Time fails with -XX:-VMContinuations Message-ID: ThreadMXBean.getThread{Cpu,User}Time is specified to return -1L when invoked with the id of a virtual thread. This isn't so when running with -XX:-VMContinuations (or ports without support for continuations in the VM) as it returns the cpu/user time of the OS thread that that the virtual thread is bound. A small oversight with JDK-8287496, and missed because our unit test only exercises these methods with the id of the "current virtual thread". The code path when the called with the id that is not the current thread is a different code path. The change is limited to jmm_GetThreadCpuTimeWithKind. I didn't change jmm_GetThreadCpuTimesWithKind because it seems to be unused/dead code. I'll create a separate issue to look at that (it doesn't need to be removed/changed for JDK 19). The test case for this API is expanded to cover more cases where the current thread is special cased in the implementation. JDK 19 is in RDP2 so this change will require additional approval. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk19/pull/157/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=157&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290562 Stats: 99 lines in 2 files changed: 78 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk19/pull/157.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/157/head:pull/157 PR: https://git.openjdk.org/jdk19/pull/157 From sspitsyn at openjdk.org Mon Aug 1 12:55:58 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 1 Aug 2022 12:55:58 GMT Subject: RFR: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM Message-ID: This is a regression that has been introduced by the fix of: [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events This is the relevant comment from Zhengyu: It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. if (event_type == JVMTI_EVENT_OBJECT_FREE) { flush_object_free_events(env); } The fix is as was suggested by Zhengyu above. I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. ------------- Commit messages: - 8290908: misc tests fail: assert(->owns_locks()) failed: must release all locks when leaving VM Changes: https://git.openjdk.org/jdk/pull/9699/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9699&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290908 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9699.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9699/head:pull/9699 PR: https://git.openjdk.org/jdk/pull/9699 From alanb at openjdk.org Mon Aug 1 15:56:48 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Aug 2022 15:56:48 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 12:02:19 GMT, Ao Qi wrote: > Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two? I think it would be better to split them. ------------- PR: https://git.openjdk.org/jdk/pull/9677 From aoqi at openjdk.org Mon Aug 1 16:25:14 2022 From: aoqi at openjdk.org (Ao Qi) Date: Mon, 1 Aug 2022 16:25:14 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" [v3] In-Reply-To: References: Message-ID: > `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti". > > The issue could be reproduced by zero. Ao Qi has updated the pull request incrementally with one additional commit since the last revision: XMLDecoder tests are filed in JDK-8291640 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9677/files - new: https://git.openjdk.org/jdk/pull/9677/files/623e3723..97c38a36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9677.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9677/head:pull/9677 PR: https://git.openjdk.org/jdk/pull/9677 From aoqi at openjdk.org Mon Aug 1 16:34:55 2022 From: aoqi at openjdk.org (Ao Qi) Date: Mon, 1 Aug 2022 16:34:55 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" In-Reply-To: References: Message-ID: <51V8ClPS3vEJ9ZwkzJZwiBUTQsJx5XPRLPY_z8IfSxQ=.9d5d5def-5e1d-459a-b0d7-b3e412c546bb@github.com> On Mon, 1 Aug 2022 15:54:47 GMT, Alan Bateman wrote: > > Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two? > > I think it would be better to split them. XMLDecoder tests are filed: https://bugs.openjdk.org/browse/JDK-8291640. This issue was also updated. ------------- PR: https://git.openjdk.org/jdk/pull/9677 From naoto at openjdk.org Mon Aug 1 16:46:01 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 1 Aug 2022 16:46:01 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung wrote: >> open l10n msg drop >> All tests passed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation LGTM ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk19/pull/154 From cjplummer at openjdk.org Mon Aug 1 18:54:16 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Aug 2022 18:54:16 GMT Subject: RFR: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn wrote: > This is a regression that has been introduced by the fix of: > [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events > > This is the relevant comment from Zhengyu: > > It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. > > I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. > > if (event_type == JVMTI_EVENT_OBJECT_FREE) { > flush_object_free_events(env); > } > > The fix is as was suggested by Zhengyu above. > I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. > However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9699 From cjplummer at openjdk.org Mon Aug 1 20:35:52 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Aug 2022 20:35:52 GMT Subject: RFR: 8291578: Remove JMX related tests from ProblemList-svc-vthreads.txt Message-ID: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> These tests do not belong in ProblemList-svc-vthreads.txt. This problem list is meant for tests that fail when the debuggee is run with the virtual thread wrapper. These tests are not setup to run in that mode, and therefore never are. They fail when the test itself is run with the jtreg virtual thread wrapper. That support is only in the loom repo, and tests that fail due to the jtreg virtual thread wrapper belong in ProblemList-vthread.txt in the loom repo. ------------- Commit messages: - Remove some jmx tests from svc-vthread problem list. Changes: https://git.openjdk.org/jdk/pull/9707/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9707&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291578 Stats: 22 lines in 1 file changed: 0 ins; 22 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9707.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9707/head:pull/9707 PR: https://git.openjdk.org/jdk/pull/9707 From cjplummer at openjdk.org Mon Aug 1 21:12:39 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Aug 2022 21:12:39 GMT Subject: RFR: 8291650: Add delay to ClassUnloadEventTest before exiting to give time for JVM to send all events before VMDeath Message-ID: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> Near the end of the test, the debuggee forces a GC so ClassUnloadEvents will be generated, and then the debuggee immediately exits. However, the ClassUnloadEvents might not be sent out before the VMDeath is generated, and it prevents delivery of any more events. A short delay after the GC should give the JVM time to deliver the ClassUnloadEvents first. Note, I was not able to reproduce this issue, so I'm not 100% sure this will fix it. It does turn up in CI testing, so this seems worth trying to see if we still see it during CI. ------------- Commit messages: - Add short delay to give chance to deliver ClassUnloadEvents before VMDeathEvent is generated Changes: https://git.openjdk.org/jdk/pull/9708/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9708&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291650 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9708.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9708/head:pull/9708 PR: https://git.openjdk.org/jdk/pull/9708 From sspitsyn at openjdk.org Mon Aug 1 21:24:17 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 1 Aug 2022 21:24:17 GMT Subject: RFR: 8291578: Remove JMX related tests from ProblemList-svc-vthreads.txt In-Reply-To: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> References: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> Message-ID: On Mon, 1 Aug 2022 20:05:02 GMT, Chris Plummer wrote: > These tests do not belong in ProblemList-svc-vthreads.txt. This problem list is meant for tests that fail when the debuggee is run with the virtual thread wrapper. These tests are not setup to run in that mode, and therefore never are. They fail when the test itself is run with the jtreg virtual thread wrapper. That support is only in the loom repo, and tests that fail due to the jtreg virtual thread wrapper belong in ProblemList-vthread.txt in the loom repo. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9707 From sspitsyn at openjdk.org Mon Aug 1 21:28:51 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 1 Aug 2022 21:28:51 GMT Subject: RFR: 8291650: Add delay to ClassUnloadEventTest before exiting to give time for JVM to send all events before VMDeath In-Reply-To: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> References: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> Message-ID: On Mon, 1 Aug 2022 21:02:39 GMT, Chris Plummer wrote: > Near the end of the test, the debuggee forces a GC so ClassUnloadEvents will be generated, and then the debuggee immediately exits. However, the ClassUnloadEvents might not be sent out before the VMDeath is generated, and it prevents delivery of any more events. A short delay after the GC should give the JVM time to deliver the ClassUnloadEvents first. > > Note, I was not able to reproduce this issue, so I'm not 100% sure this will fix it. It does turn up in CI testing, so this seems worth trying to see if we still see it during CI. This looks okay to me. However, it can be still unreliable. Is there a way to check-wait for the expected class unload events? ------------- PR: https://git.openjdk.org/jdk/pull/9708 From weijun at openjdk.org Mon Aug 1 22:31:04 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 1 Aug 2022 22:31:04 GMT Subject: Integrated: 8282730: LdapLoginModule throw NPE from logout method after login failure In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote: > Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`. This pull request has now been integrated. Changeset: 554f44ec Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/554f44ecb1134acff3eaf02e2e1c0e01158ab7e5 Stats: 223 lines in 11 files changed: 151 ins; 2 del; 70 mod 8282730: LdapLoginModule throw NPE from logout method after login failure Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/9348 From cjplummer at openjdk.org Mon Aug 1 22:58:55 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 1 Aug 2022 22:58:55 GMT Subject: RFR: 8291650: Add delay to ClassUnloadEventTest before exiting to give time for JVM to send all events before VMDeath In-Reply-To: References: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> Message-ID: On Mon, 1 Aug 2022 21:25:09 GMT, Serguei Spitsyn wrote: > This looks okay to me. > However, it can be still unreliable. > Is there a way to check-wait for the expected class unload events? The debuggee would need to block until the debugger says it got all the events. Currently the debugger just runs until it gets a VMDeathEvent, then it checks if got the expected ClassUnloadEvents. So it would instead have to wait until it got all the expected ClassUnloadEvents (and time out eventually if not). It would also need to communicate with the debuggee. I don't think any of com/sun/jdi tests currently do this. Possibly we could setup a breakpoint in the debuggee after doing the GC, and have the debugger not resume it until after it gets all the expected events. I just felt doing a short sleep was so much easier, especially given that we aren't 100% sure the early VMDeathEvent is the cause of this issue. At the very least it would be nice to see if this simple solution is fixing the problem. ------------- PR: https://git.openjdk.org/jdk/pull/9708 From sspitsyn at openjdk.org Tue Aug 2 01:37:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Aug 2022 01:37:22 GMT Subject: RFR: 8291650: Add delay to ClassUnloadEventTest before exiting to give time for JVM to send all events before VMDeath In-Reply-To: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> References: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> Message-ID: On Mon, 1 Aug 2022 21:02:39 GMT, Chris Plummer wrote: > Near the end of the test, the debuggee forces a GC so ClassUnloadEvents will be generated, and then the debuggee immediately exits. However, the ClassUnloadEvents might not be sent out before the VMDeath is generated, and it prevents delivery of any more events. A short delay after the GC should give the JVM time to deliver the ClassUnloadEvents first. > > Note, I was not able to reproduce this issue, so I'm not 100% sure this will fix it. It does turn up in CI testing, so this seems worth trying to see if we still see it during CI. Okay. Approved. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9708 From aoqi at openjdk.org Tue Aug 2 06:32:09 2022 From: aoqi at openjdk.org (Ao Qi) Date: Tue, 2 Aug 2022 06:32:09 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" [v4] In-Reply-To: References: Message-ID: > `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported. > > The issue could be reproduced by zero. Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into 8291508 - XMLDecoder tests are filed in JDK-8291640 - XMLDecoder update Co-authored-by: Alan Bateman - 8291508: Fix some tests with "requires vm.continuations" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9677/files - new: https://git.openjdk.org/jdk/pull/9677/files/97c38a36..1e00cd83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=02-03 Stats: 2659 lines in 193 files changed: 1590 ins; 605 del; 464 mod Patch: https://git.openjdk.org/jdk/pull/9677.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9677/head:pull/9677 PR: https://git.openjdk.org/jdk/pull/9677 From sspitsyn at openjdk.org Tue Aug 2 06:59:24 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Aug 2022 06:59:24 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" [v4] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi wrote: >> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported. >> >> The issue could be reproduced by zero. > > Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8291508 > - XMLDecoder tests are filed in JDK-8291640 > - XMLDecoder update > > Co-authored-by: Alan Bateman > - 8291508: Fix some tests with "requires vm.continuations" I'm surprised these two tests have the `--enable-preview` flag. @lmesnik Could you, please, take a look at these two tests? Otherwise, the fix looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9677 From duke at openjdk.org Tue Aug 2 14:23:11 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Tue, 2 Aug 2022 14:23:11 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: <7ZWXnITgRa_WubtuwnM3VTs62HqwzbMOUt9Tdp9Fx-s=.d3e48748-36fc-4ce1-a096-5830afa1c29d@github.com> On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From alanb at openjdk.org Tue Aug 2 17:27:25 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Aug 2022 17:27:25 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" [v4] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi wrote: >> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported. >> >> The issue could be reproduced by zero. > > Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8291508 > - XMLDecoder tests are filed in JDK-8291640 > - XMLDecoder update > > Co-authored-by: Alan Bateman > - 8291508: Fix some tests with "requires vm.continuations" Just an FYI that the [ORDER OF TAGS](https://openjdk.org/jtreg/tag-spec.html#ORDER) section of the tag language spec recommends putting the `@requires` before the `@modules` and `@library` tags. ------------- PR: https://git.openjdk.org/jdk/pull/9677 From kevinw at openjdk.org Tue Aug 2 18:39:10 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 2 Aug 2022 18:39:10 GMT Subject: RFR: 8291578: Remove JMX related tests from ProblemList-svc-vthreads.txt In-Reply-To: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> References: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> Message-ID: On Mon, 1 Aug 2022 20:05:02 GMT, Chris Plummer wrote: > These tests do not belong in ProblemList-svc-vthreads.txt. This problem list is meant for tests that fail when the debuggee is run with the virtual thread wrapper. These tests are not setup to run in that mode, and therefore never are. They fail when the test itself is run with the jtreg virtual thread wrapper. That support is only in the loom repo, and tests that fail due to the jtreg virtual thread wrapper belong in ProblemList-vthread.txt in the loom repo. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9707 From lmesnik at openjdk.org Tue Aug 2 18:53:42 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 2 Aug 2022 18:53:42 GMT Subject: RFR: 8291578: Remove JMX related tests from ProblemList-svc-vthreads.txt In-Reply-To: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> References: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> Message-ID: On Mon, 1 Aug 2022 20:05:02 GMT, Chris Plummer wrote: > These tests do not belong in ProblemList-svc-vthreads.txt. This problem list is meant for tests that fail when the debuggee is run with the virtual thread wrapper. These tests are not setup to run in that mode, and therefore never are. They fail when the test itself is run with the jtreg virtual thread wrapper. That support is only in the loom repo, and tests that fail due to the jtreg virtual thread wrapper belong in ProblemList-vthread.txt in the loom repo. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9707 From lmesnik at openjdk.org Tue Aug 2 18:53:43 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 2 Aug 2022 18:53:43 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" [v4] In-Reply-To: References: Message-ID: <9udmozwzmOEm5-cfI85oeAVTafamwMrZj1-Y2q6mxLA=.1708e4bf-24ec-4d5b-9859-7129342628ab@github.com> On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi wrote: >> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported. >> >> The issue could be reproduced by zero. > > Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into 8291508 > - XMLDecoder tests are filed in JDK-8291640 > - XMLDecoder update > > Co-authored-by: Alan Bateman > - 8291508: Fix some tests with "requires vm.continuations" Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9677 From amenkov at openjdk.org Tue Aug 2 20:31:42 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 2 Aug 2022 20:31:42 GMT Subject: RFR: 8291650: Add delay to ClassUnloadEventTest before exiting to give time for JVM to send all events before VMDeath In-Reply-To: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> References: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> Message-ID: <5oy6lKRDV09cfS96nX-bJKWaBKLAOuZGsWhs_rRcR_g=.6e141663-262d-4534-92e9-f3f3039acfba@github.com> On Mon, 1 Aug 2022 21:02:39 GMT, Chris Plummer wrote: > Near the end of the test, the debuggee forces a GC so ClassUnloadEvents will be generated, and then the debuggee immediately exits. However, the ClassUnloadEvents might not be sent out before the VMDeath is generated, and it prevents delivery of any more events. A short delay after the GC should give the JVM time to deliver the ClassUnloadEvents first. > > Note, I was not able to reproduce this issue, so I'm not 100% sure this will fix it. It does turn up in CI testing, so this seems worth trying to see if we still see it during CI. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9708 From dlong at openjdk.org Tue Aug 2 21:02:52 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Aug 2022 21:02:52 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings Now that you are building a separate list of nmethods to deoptimize, what protects that list from nmethods being recycled by other threads? Don't you need to hold the CodeCache_lock? ------------- PR: https://git.openjdk.org/jdk/pull/9655 From cjplummer at openjdk.org Tue Aug 2 21:18:52 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 2 Aug 2022 21:18:52 GMT Subject: Integrated: 8291578: Remove JMX related tests from ProblemList-svc-vthreads.txt In-Reply-To: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> References: <40uami8bol9a99563gQq1W12AWLEK7BRhMyxF7lpgpo=.356596bb-3414-4631-8e93-8dc446179be9@github.com> Message-ID: On Mon, 1 Aug 2022 20:05:02 GMT, Chris Plummer wrote: > These tests do not belong in ProblemList-svc-vthreads.txt. This problem list is meant for tests that fail when the debuggee is run with the virtual thread wrapper. These tests are not setup to run in that mode, and therefore never are. They fail when the test itself is run with the jtreg virtual thread wrapper. That support is only in the loom repo, and tests that fail due to the jtreg virtual thread wrapper belong in ProblemList-vthread.txt in the loom repo. This pull request has now been integrated. Changeset: 5acf2d7c Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/5acf2d7cb42d004e1d35834ae321f531c46594db Stats: 22 lines in 1 file changed: 0 ins; 22 del; 0 mod 8291578: Remove JMX related tests from ProblemList-svc-vthreads.txt Reviewed-by: sspitsyn, kevinw, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/9707 From cjplummer at openjdk.org Tue Aug 2 21:15:37 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 2 Aug 2022 21:15:37 GMT Subject: Integrated: 8291650: Add delay to ClassUnloadEventTest before exiting to give time for JVM to send all events before VMDeath In-Reply-To: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> References: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com> Message-ID: On Mon, 1 Aug 2022 21:02:39 GMT, Chris Plummer wrote: > Near the end of the test, the debuggee forces a GC so ClassUnloadEvents will be generated, and then the debuggee immediately exits. However, the ClassUnloadEvents might not be sent out before the VMDeath is generated, and it prevents delivery of any more events. A short delay after the GC should give the JVM time to deliver the ClassUnloadEvents first. > > Note, I was not able to reproduce this issue, so I'm not 100% sure this will fix it. It does turn up in CI testing, so this seems worth trying to see if we still see it during CI. This pull request has now been integrated. Changeset: a6564d49 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/a6564d495b6c2354b82cd49243d3c8793d95f2cb Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod 8291650: Add delay to ClassUnloadEventTest before exiting to give time for JVM to send all events before VMDeath Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9708 From amenkov at openjdk.org Tue Aug 2 22:03:06 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 2 Aug 2022 22:03:06 GMT Subject: RFR: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: Message-ID: <33PUVzpnb1IiVPy7U7CTIGr_cjAFn_Elj4uvoa3hw3Q=.40ee2a10-8dda-42ce-8054-1277b06588dc@github.com> On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn wrote: > This is a regression that has been introduced by the fix of: > [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events > > This is the relevant comment from Zhengyu: > > It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. > > I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. > > if (event_type == JVMTI_EVENT_OBJECT_FREE) { > flush_object_free_events(env); > } > > The fix is as was suggested by Zhengyu above. > I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. > However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9699 From sspitsyn at openjdk.org Tue Aug 2 22:43:06 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Aug 2022 22:43:06 GMT Subject: RFR: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn wrote: > This is a regression that has been introduced by the fix of: > [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events > > This is the relevant comment from Zhengyu: > > It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. > > I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. > > if (event_type == JVMTI_EVENT_OBJECT_FREE) { > flush_object_free_events(env); > } > > The fix is as was suggested by Zhengyu above. > I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. > However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. Chris and Alex, thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/9699 From sspitsyn at openjdk.org Tue Aug 2 22:44:31 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Aug 2022 22:44:31 GMT Subject: Integrated: 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn wrote: > This is a regression that has been introduced by the fix of: > [8256811](https://bugs.openjdk.org/browse/JDK-8256811): Delayed/missed jdwp class unloading events > > This is the relevant comment from Zhengyu: > > It is caused by https://bugs.openjdk.org/browse/JDK-8256811 as JvmtiExport::post_object_free() call does not expect under any lock. > > I think we can move following code outside of lock, as flush_obect_free_events() races ServiceThread's JvmtiTagMap::flush_all_object_free_events() call anyway. > > if (event_type == JVMTI_EVENT_OBJECT_FREE) { > flush_object_free_events(env); > } > > The fix is as was suggested by Zhengyu above. > I was not able to reproduce JCK and nsk.jvmti test failures mentioned in the bug report. > However, this fix should address the problem as it moves the call to `flush_object_free_events(env)` out of a critical section with a lock. This pull request has now been integrated. Changeset: 0ae83410 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/0ae834105740f7cf73fe96be22e0f564ad29b18d Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod 8290908: misc tests fail: assert(!thread->owns_locks()) failed: must release all locks when leaving VM Reviewed-by: cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9699 From aoqi at openjdk.org Wed Aug 3 02:34:48 2022 From: aoqi at openjdk.org (Ao Qi) Date: Wed, 3 Aug 2022 02:34:48 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" [v5] In-Reply-To: References: Message-ID: > `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported. > > The issue could be reproduced by zero. Ao Qi has updated the pull request incrementally with one additional commit since the last revision: update tags order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9677/files - new: https://git.openjdk.org/jdk/pull/9677/files/1e00cd83..2ea9e1a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9677&range=03-04 Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9677.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9677/head:pull/9677 PR: https://git.openjdk.org/jdk/pull/9677 From aoqi at openjdk.org Wed Aug 3 02:36:03 2022 From: aoqi at openjdk.org (Ao Qi) Date: Wed, 3 Aug 2022 02:36:03 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" [v4] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 17:25:19 GMT, Alan Bateman wrote: > Just an FYI that the [ORDER OF TAGS](https://openjdk.org/jtreg/tag-spec.html#ORDER) section of the tag language spec recommends putting the `@requires` before the `@modules` and `@library` tags. Done. Didn't know that. Thank you for the reminder. ------------- PR: https://git.openjdk.org/jdk/pull/9677 From duke at openjdk.org Wed Aug 3 09:06:39 2022 From: duke at openjdk.org (xpbob) Date: Wed, 3 Aug 2022 09:06:39 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v7] In-Reply-To: References: Message-ID: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with two additional commits since the last revision: - remove line - add export ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/4d5faab3..6a524606 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=05-06 Stats: 46 lines in 5 files changed: 23 ins; 21 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From alanb at openjdk.org Wed Aug 3 09:14:44 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Aug 2022 09:14:44 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v7] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 09:06:39 GMT, xpbob wrote: >> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. >> Results the following >> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) > > xpbob has updated the pull request incrementally with two additional commits since the last revision: > > - remove line > - add export src/java.management/share/classes/module-info.java line 52: > 50: exports javax.management.remote; > 51: exports javax.management.timer; > 52: exports java.lang.management.internal.mBeans; This package should not be exported (at least not to all modules). ------------- PR: https://git.openjdk.org/jdk/pull/9372 From sspitsyn at openjdk.org Wed Aug 3 09:18:41 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Aug 2022 09:18:41 GMT Subject: [jdk19] RFR: 8290562: ThreadMXBean.getThread{Cpu, User}Time fails with -XX:-VMContinuations In-Reply-To: References: Message-ID: <5YumC2qJXy3bLaZ0CFKYSe1MSIzfUkquNlP4kLDl1j0=.e31cfa03-845a-4d3f-ad61-df24fa8953e1@github.com> On Mon, 1 Aug 2022 09:16:41 GMT, Alan Bateman wrote: > ThreadMXBean.getThread{Cpu,User}Time is specified to return -1L when invoked with the id of a virtual thread. This isn't so when running with -XX:-VMContinuations (or ports without support for continuations in the VM) as it returns the cpu/user time of the OS thread that that the virtual thread is bound. A small oversight with JDK-8287496, and missed because our unit test only exercises these methods with the id of the "current virtual thread". The code path when the called with the id that is not the current thread is a different code path. > > The change is limited to jmm_GetThreadCpuTimeWithKind. I didn't change jmm_GetThreadCpuTimesWithKind because it seems to be unused/dead code. I'll create a separate issue to look at that (it doesn't need to be removed/changed for JDK 19). > > The test case for this API is expanded to cover more cases where the current thread is special cased in the implementation. > > JDK 19 is in RDP2 so this change will require additional approval. The fix looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk19/pull/157 From alanb at openjdk.org Wed Aug 3 09:20:29 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Aug 2022 09:20:29 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v7] In-Reply-To: References: Message-ID: <1GxIcg5723Xpmw0AwwNNx_aD-joLaJbyZF2xkrKmBbA=.06dde6e6-64fb-4145-b20e-847598843f87@github.com> On Wed, 3 Aug 2022 09:06:39 GMT, xpbob wrote: >> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. >> Results the following >> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) > > xpbob has updated the pull request incrementally with two additional commits since the last revision: > > - remove line > - add export What happened with the experiment to move ContainerInfoMXBean to jdk.management? ------------- PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Wed Aug 3 09:51:06 2022 From: duke at openjdk.org (xpbob) Date: Wed, 3 Aug 2022 09:51:06 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v8] In-Reply-To: References: Message-ID: <2gpdjorgQDqw_DpKn29bvsgYzm-p6tgJMyRCMjYQ4c4=.ba44c96a-e35c-4dd2-bdab-2c9d267c524e@github.com> > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with one additional commit since the last revision: move ContainerInfoMXBean to jdk.management ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/6a524606..0aa0ffb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=06-07 Stats: 49 lines in 5 files changed: 25 ins; 20 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From kevinw at openjdk.org Wed Aug 3 10:29:00 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 3 Aug 2022 10:29:00 GMT Subject: [jdk19] RFR: 8290562: ThreadMXBean.getThread{Cpu, User}Time fails with -XX:-VMContinuations In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 09:16:41 GMT, Alan Bateman wrote: > ThreadMXBean.getThread{Cpu,User}Time is specified to return -1L when invoked with the id of a virtual thread. This isn't so when running with -XX:-VMContinuations (or ports without support for continuations in the VM) as it returns the cpu/user time of the OS thread that that the virtual thread is bound. A small oversight with JDK-8287496, and missed because our unit test only exercises these methods with the id of the "current virtual thread". The code path when the called with the id that is not the current thread is a different code path. > > The change is limited to jmm_GetThreadCpuTimeWithKind. I didn't change jmm_GetThreadCpuTimesWithKind because it seems to be unused/dead code. I'll create a separate issue to look at that (it doesn't need to be removed/changed for JDK 19). > > The test case for this API is expanded to cover more cases where the current thread is special cased in the implementation. > > JDK 19 is in RDP2 so this change will require additional approval. Marked as reviewed by kevinw (Committer). test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 111: > 109: > 110: /** > 111: * Test that ThreadMXBean.getThreadInfo(long) with the thread id of a carrier thread. Pre-existing typo: this comment sentence looks truncated? Or maybe just remove "that" and it's fine: "Test ThreadMXBean.getThreadInfo(long) with.." ------------- PR: https://git.openjdk.org/jdk19/pull/157 From duke at openjdk.org Wed Aug 3 10:36:06 2022 From: duke at openjdk.org (xpbob) Date: Wed, 3 Aug 2022 10:36:06 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v9] In-Reply-To: References: Message-ID: <-I4q3Qy5ZVaGShBrUsPK2W9x_6cfUYRgBe42-GJtmi4=.59df8931-e165-4527-9d76-4f95e605abc8@github.com> > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with one additional commit since the last revision: Revert file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/0aa0ffb4..2c149c10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=07-08 Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Wed Aug 3 10:38:51 2022 From: duke at openjdk.org (xpbob) Date: Wed, 3 Aug 2022 10:38:51 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v8] In-Reply-To: <2gpdjorgQDqw_DpKn29bvsgYzm-p6tgJMyRCMjYQ4c4=.ba44c96a-e35c-4dd2-bdab-2c9d267c524e@github.com> References: <2gpdjorgQDqw_DpKn29bvsgYzm-p6tgJMyRCMjYQ4c4=.ba44c96a-e35c-4dd2-bdab-2c9d267c524e@github.com> Message-ID: <0MRzjXC_Nf03b9VlFbeMo4UMOTW4zf4CQqQkWtpZbfg=.ae7f34fa-f44c-42b2-bf92-6f4fb26828f0@github.com> On Wed, 3 Aug 2022 09:51:06 GMT, xpbob wrote: >> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. >> Results the following >> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > move ContainerInfoMXBean to jdk.management Thanks for review. @AlanBateman I found my code bug and it has been fixed. Moving ContainerInfo is feasible ------------- PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Wed Aug 3 10:40:41 2022 From: duke at openjdk.org (xpbob) Date: Wed, 3 Aug 2022 10:40:41 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v9] In-Reply-To: <-I4q3Qy5ZVaGShBrUsPK2W9x_6cfUYRgBe42-GJtmi4=.59df8931-e165-4527-9d76-4f95e605abc8@github.com> References: <-I4q3Qy5ZVaGShBrUsPK2W9x_6cfUYRgBe42-GJtmi4=.59df8931-e165-4527-9d76-4f95e605abc8@github.com> Message-ID: On Wed, 3 Aug 2022 10:36:06 GMT, xpbob wrote: >> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. >> Results the following >> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > Revert file ![??](https://user-images.githubusercontent.com/7837910/182588282-4958e976-e322-48b2-865f-5111b04960eb.png) ------------- PR: https://git.openjdk.org/jdk/pull/9372 From alanb at openjdk.org Wed Aug 3 10:52:43 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Aug 2022 10:52:43 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" [v5] In-Reply-To: References: Message-ID: <6hRAKer8eW6kUHAIv-xHtLffshGe2OMmXiJe-wbmdHM=.ab4418e2-f40c-44c0-b546-686f0d09ef74@github.com> On Wed, 3 Aug 2022 02:34:48 GMT, Ao Qi wrote: >> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported. >> >> The issue could be reproduced by zero. > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > update tags order Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9677 From duke at openjdk.org Wed Aug 3 13:39:43 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 3 Aug 2022 13:39:43 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings As my previous comment will probably back out the linked list of this PR and create a separate issue that depends on this encapsulation that only deal with swapping to a linked list instead of walking the whole code cache. But as it will be based on this code your question is still relevant. I am pretty new to the codebase so please correct me if I am wrong, especially with regards to different locks, their scope and usage. Here is my understanding of why the linked list is valid as is. While working with the list we have a few things which are true: * `assert_locked_or_safepoint(Compile_lock);` anywhere were we modify the list, * once something is linked it cannot be linked again, as it is only linked if it is `not_marked` and the status can only go `not_marked -> deoptimize | deoptimize_noupdate -> deoptimize_done`. * `assert(extract_compiled_method(_mark_link) == nullptr, ...)` for some extra sanity around this * While the `MarkForDeoptimizationStatus` value makes linking something already linked impossible the assert above is not enough to catch if a tail of the list is linked in creating a cycle. Can either add an assert that walks the list and checks that the `tail != this`, or the `next_marked()` code can be changed to `take_next_marked()` which sets the field to `nullptr` and thus breaks any cycles when iterating (avoids infinite loops). The second would be alright as creating a loop from the tail to the root will never drop parts of the list, even if more elements are added after the cycle is created, as the `assert(extract_compiled_method(_mark_link) == nullptr, ...)` assert that the list will not break. * From the creation of a `DeoptimizationContext` to until the linked list has been processed (`make_not_entrant` and `make_deoptimized`) we have `NoSafepointVerifier` (which is the time to safe point issue this change is trying to address) * And this active part of the DeoptimizationContext cannot overlap with another active part of another DeoptimizationContext, checked via a bool flag. Maybe it is not correct to have a non volatile static bool here, but I though `assert_locked_or_safepoint(Compile_lock);` would be enough to guarantee synchronisation. But should probably change to load acquire atomics. I think most of the terminology will change to make it more deoptimization specific. Having it called `not_marked`, `_root_mark_link`, `_mark_link`, `next_mark()` and `take_root()` is to general and can lead to confusion. Another reason to split this out to a separate issue. Also using some other terminology than `mark` could be used. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From alanb at openjdk.org Wed Aug 3 14:37:52 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Aug 2022 14:37:52 GMT Subject: [jdk19] RFR: 8290562: ThreadMXBean.getThread{Cpu, User}Time fails with -XX:-VMContinuations [v2] In-Reply-To: References: Message-ID: <6CQjn1v6rwjxnE5BWB8OQdVHSr0xKW4TGc6dPwEiPYE=.f5054692-bc94-4667-b687-859e6eb25ce7@github.com> > ThreadMXBean.getThread{Cpu,User}Time is specified to return -1L when invoked with the id of a virtual thread. This isn't so when running with -XX:-VMContinuations (or ports without support for continuations in the VM) as it returns the cpu/user time of the OS thread that that the virtual thread is bound. A small oversight with JDK-8287496, and missed because our unit test only exercises these methods with the id of the "current virtual thread". The code path when the called with the id that is not the current thread is a different code path. > > The change is limited to jmm_GetThreadCpuTimeWithKind. I didn't change jmm_GetThreadCpuTimesWithKind because it seems to be unused/dead code. I'll create a separate issue to look at that (it doesn't need to be removed/changed for JDK 19). > > The test case for this API is expanded to cover more cases where the current thread is special cased in the implementation. > > JDK 19 is in RDP2 so this change will require additional approval. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Fix typo in comment ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/157/files - new: https://git.openjdk.org/jdk19/pull/157/files/4c834d39..bc7dd91b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=157&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=157&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/157.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/157/head:pull/157 PR: https://git.openjdk.org/jdk19/pull/157 From sspitsyn at openjdk.org Wed Aug 3 17:34:03 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Aug 2022 17:34:03 GMT Subject: [jdk19] RFR: 8290562: ThreadMXBean.getThread{Cpu, User}Time fails with -XX:-VMContinuations [v2] In-Reply-To: <6CQjn1v6rwjxnE5BWB8OQdVHSr0xKW4TGc6dPwEiPYE=.f5054692-bc94-4667-b687-859e6eb25ce7@github.com> References: <6CQjn1v6rwjxnE5BWB8OQdVHSr0xKW4TGc6dPwEiPYE=.f5054692-bc94-4667-b687-859e6eb25ce7@github.com> Message-ID: On Wed, 3 Aug 2022 14:37:52 GMT, Alan Bateman wrote: >> ThreadMXBean.getThread{Cpu,User}Time is specified to return -1L when invoked with the id of a virtual thread. This isn't so when running with -XX:-VMContinuations (or ports without support for continuations in the VM) as it returns the cpu/user time of the OS thread that that the virtual thread is bound. A small oversight with JDK-8287496, and missed because our unit test only exercises these methods with the id of the "current virtual thread". The code path when the called with the id that is not the current thread is a different code path. >> >> The change is limited to jmm_GetThreadCpuTimeWithKind. I didn't change jmm_GetThreadCpuTimesWithKind because it seems to be unused/dead code. I'll create a separate issue to look at that (it doesn't need to be removed/changed for JDK 19). >> >> The test case for this API is expanded to cover more cases where the current thread is special cased in the implementation. >> >> JDK 19 is in RDP2 so this change will require additional approval. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in comment Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/157 From sspitsyn at openjdk.org Wed Aug 3 17:34:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 3 Aug 2022 17:34:22 GMT Subject: RFR: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" [v5] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 02:34:48 GMT, Ao Qi wrote: >> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported. >> >> The issue could be reproduced by zero. > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > update tags order Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9677 From aoqi at openjdk.org Wed Aug 3 17:36:14 2022 From: aoqi at openjdk.org (Ao Qi) Date: Wed, 3 Aug 2022 17:36:14 GMT Subject: Integrated: 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 16:11:12 GMT, Ao Qi wrote: > `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported. > > The issue could be reproduced by zero. This pull request has now been integrated. Changeset: 0cc49fd9 Author: Ao Qi Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/0cc49fd9eac5259543a3c41b7a32b6e01a1b0ad5 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod 8291508: Fix some tests with "requires vm.jvmti & vm.continuations" Reviewed-by: sspitsyn, lmesnik, alanb ------------- PR: https://git.openjdk.org/jdk/pull/9677 From dlong at openjdk.org Wed Aug 3 19:37:40 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 3 Aug 2022 19:37:40 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings It's nmethod::flush() I'm worried about. It uses CodeCache_lock, not Compile_lock. It calls CodeCache::free() to destroy the nmethod. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From eosterlund at openjdk.org Wed Aug 3 20:39:34 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 3 Aug 2022 20:39:34 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings The nmethods we link together are is_alive. There is also no safepoint. It would be impossible for such nmethods to be flushed without a safepoint. It could racingly flip to zombie, but it would need yet another thread-local handshake from the sweeper for it to flush the nmethods. That can not happen without safepoints in this code path. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From eosterlund at openjdk.org Wed Aug 3 20:45:22 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 3 Aug 2022 20:45:22 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings Also, in DeoptimizationContext::deopt_compiled_methods, the SweeperBlocker completely blocks out the sweeper from running. But as I mentioned, even without that, without safepoint checks, we can never flush these things. It's worth mentioning that there used to be a special case for OSR nmethods that they could be flushed immediately and skip the zombie step. But I removed that a few tears ago so we wouldn't have to think about that pathological case separately. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From mchung at openjdk.org Thu Aug 4 01:10:06 2022 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 4 Aug 2022 01:10:06 GMT Subject: [jdk19] RFR: 8290562: ThreadMXBean.getThread{Cpu, User}Time fails with -XX:-VMContinuations [v2] In-Reply-To: <6CQjn1v6rwjxnE5BWB8OQdVHSr0xKW4TGc6dPwEiPYE=.f5054692-bc94-4667-b687-859e6eb25ce7@github.com> References: <6CQjn1v6rwjxnE5BWB8OQdVHSr0xKW4TGc6dPwEiPYE=.f5054692-bc94-4667-b687-859e6eb25ce7@github.com> Message-ID: On Wed, 3 Aug 2022 14:37:52 GMT, Alan Bateman wrote: >> ThreadMXBean.getThread{Cpu,User}Time is specified to return -1L when invoked with the id of a virtual thread. This isn't so when running with -XX:-VMContinuations (or ports without support for continuations in the VM) as it returns the cpu/user time of the OS thread that that the virtual thread is bound. A small oversight with JDK-8287496, and missed because our unit test only exercises these methods with the id of the "current virtual thread". The code path when the called with the id that is not the current thread is a different code path. >> >> The change is limited to jmm_GetThreadCpuTimeWithKind. I didn't change jmm_GetThreadCpuTimesWithKind because it seems to be unused/dead code. I'll create a separate issue to look at that (it doesn't need to be removed/changed for JDK 19). >> >> The test case for this API is expanded to cover more cases where the current thread is special cased in the implementation. >> >> JDK 19 is in RDP2 so this change will require additional approval. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in comment Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk19/pull/157 From duke at openjdk.org Thu Aug 4 06:07:05 2022 From: duke at openjdk.org (duke) Date: Thu, 4 Aug 2022 06:07:05 GMT Subject: Withdrawn: 8285149: Using HashMap.newHashMap to replace new HashMap(int) In-Reply-To: References: Message-ID: <6zyYs300tD4dVrr_FT6ILURyaxkXaKtDe3rbLm1rMD8=.64484460-e180-4b3b-97f9-8573daa11da0@github.com> On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess wrote: > These are the changes that too many to be reviewed in 8186958, thus split some of them out. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8301 From dlong at openjdk.org Fri Aug 5 02:45:50 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 5 Aug 2022 02:45:50 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 20:42:59 GMT, Erik ?sterlund wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: >> >> - Add assertions >> - Fix marked logic >> - Erik refactorings > > Also, in DeoptimizationContext::deopt_compiled_methods, the SweeperBlocker completely blocks out the sweeper from running. But as I mentioned, even without that, without safepoint checks, we can never flush these things. > It's worth mentioning that there used to be a special case for OSR nmethods that they could be flushed immediately and skip the zombie step. But I removed that a few tears ago so we wouldn't have to think about that pathological case separately. @fisk, is there any chance that in the future we might figure out how to allow nmethods to be flushed without a safepoint? Maybe with handshakes or some other clever improvement? If no, then maybe a comment saying so would help. If yes, then are there some asserts we could add that would catch such a change? ------------- PR: https://git.openjdk.org/jdk/pull/9655 From eosterlund at openjdk.org Fri Aug 5 05:56:45 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 5 Aug 2022 05:56:45 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 20:42:59 GMT, Erik ?sterlund wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: >> >> - Add assertions >> - Fix marked logic >> - Erik refactorings > > Also, in DeoptimizationContext::deopt_compiled_methods, the SweeperBlocker completely blocks out the sweeper from running. But as I mentioned, even without that, without safepoint checks, we can never flush these things. > It's worth mentioning that there used to be a special case for OSR nmethods that they could be flushed immediately and skip the zombie step. But I removed that a few tears ago so we wouldn't have to think about that pathological case separately. > @fisk, is there any chance that in the future we might figure out how to allow nmethods to be flushed without a safepoint? Maybe with handshakes or some other clever improvement? If no, then maybe a comment saying so would help. If yes, then are there some asserts we could add that would catch such a change? Yes. With concurrent class unloading, nmethods are unloaded during concurrent execution. After the sweeper removal, this is done in 2 phases: 1. We unlink() the nmethod 2. A thread-local handshake with all JavaThreads (who might have gotten a reference to it before unlinking) 3. We flush() the nmethod ------------- PR: https://git.openjdk.org/jdk/pull/9655 From alanb at openjdk.org Fri Aug 5 07:42:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Aug 2022 07:42:11 GMT Subject: [jdk19] Integrated: 8290562: ThreadMXBean.getThread{Cpu,User}Time fails with -XX:-VMContinuations In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 09:16:41 GMT, Alan Bateman wrote: > ThreadMXBean.getThread{Cpu,User}Time is specified to return -1L when invoked with the id of a virtual thread. This isn't so when running with -XX:-VMContinuations (or ports without support for continuations in the VM) as it returns the cpu/user time of the OS thread that that the virtual thread is bound. A small oversight with JDK-8287496, and missed because our unit test only exercises these methods with the id of the "current virtual thread". The code path when the called with the id that is not the current thread is a different code path. > > The change is limited to jmm_GetThreadCpuTimeWithKind. I didn't change jmm_GetThreadCpuTimesWithKind because it seems to be unused/dead code. I'll create a separate issue to look at that (it doesn't need to be removed/changed for JDK 19). > > The test case for this API is expanded to cover more cases where the current thread is special cased in the implementation. > > JDK 19 is in RDP2 so this change will require additional approval. This pull request has now been integrated. Changeset: 5963300c Author: Alan Bateman URL: https://git.openjdk.org/jdk19/commit/5963300c0c9dfd34c6338fa8195ae18d7b41840c Stats: 99 lines in 2 files changed: 78 ins; 0 del; 21 mod 8290562: ThreadMXBean.getThread{Cpu,User}Time fails with -XX:-VMContinuations Reviewed-by: sspitsyn, kevinw, mchung ------------- PR: https://git.openjdk.org/jdk19/pull/157 From egor.ushakov at jetbrains.com Fri Aug 5 16:59:17 2022 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Fri, 5 Aug 2022 18:59:17 +0200 Subject: Grouped method entry events Message-ID: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> Hi, we're experiencing strange grouping of method entry/exit events, is this a bug or a feature? We have one method entry request active with suspend policy 1 (suspend thread). important: we also have one active step request (step over) In jdk 11 we have one composite event for each event, which is what's expected: event set, policy:1, count:1 = {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:375 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.Object:50 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.String:1502 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.String:3266 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} ... In jdk 18 they are grouped now! event set, policy:1, count:17 = {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 in thread main, MethodEntryEvent at java.lang.System:490 in thread main, MethodEntryEvent at java.lang.System:198 in thread main, MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in thread main, MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in thread main, MethodEntryEvent at java.lang.ClassLoader:664 in thread main, MethodEntryEvent at java.lang.Object:44 in thread main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in thread main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in thread main, MethodEntryEvent at java.lang.String:2336 in thread main, MethodEntryEvent at java.lang.String:4546 in thread main, MethodEntryEvent at java.lang.StringLatin1:192 in thread main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in thread main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in thread main, MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, long)+-1 in thread main} event set, policy:1, count:4 = {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 in thread main, MethodEntryEvent at java.lang.Object:44 in thread main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 in thread main, MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, long, java.lang.Object, java.lang.Object)+-1 in thread main} event set, policy:1, count:2 = {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in thread main, MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, long, long, long)+-1 in thread main} Which is really strange and breaks some login in IDEA debugger. Without the active step request it works in jdk 18 as in jdk 11: event set, policy:1, count:1 = {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:490 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:198 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.Object:44 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.String:2336 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.String:4546 in thread main} event set, policy:1, count:1 = {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} Could anyone have a look please. Thanks, Egor From chris.plummer at oracle.com Fri Aug 5 20:02:38 2022 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 5 Aug 2022 13:02:38 -0700 Subject: Grouped method entry events In-Reply-To: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> Message-ID: Hi Egor, That is odd, and clearly wrong. It means that MethodEntryEvents are being delivered when no longer even executing in the method. And you are using the EVENT_THREAD suspend policy, so there should be a suspend for each event. Offhand I can't think of any changes that would have caused this. I also don't see how our testing would passed with this behavior. I'm suspecting a faulty interaction with the debug agent and IDEA (possibly the IDEA version of JDI). Can you see where the thread is actually suspended at when you get the event set? Does this happen with 17 also? It would be nice to know what version introduced this problem. Can you create a JDI test case for this? > Without the active step request it works in jdk 18 as in jdk 11: I'm not sure what you mean by "active step". Do you mean single stepping is enabled? The JDWP spec does allow BreakPoint, SingleStep, MethodEntry, and MethodExit events to be combined into the same composite event (which should translate to the same JDI event set) if they occur at the same location and in the same thread. So I can see enabling single stepping having an impact on the behavior you are seeing. Chris On 8/5/22 9:59 AM, Egor Ushakov wrote: > Hi, > > we're experiencing strange grouping of method entry/exit events, is > this a bug or a feature? > We have one method entry request active with suspend policy 1 (suspend > thread). > important: we also have one active step request (step over) > > In jdk 11 we have one composite event for each event, which is what's > expected: > event set, policy:1, count:1 = > {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 > in thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:375 > in thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in thread > main} > event set, policy:1, count:1 = > {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in thread > main} > event set, policy:1, count:1 = > {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.Object:50 > in thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in > thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in > thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.String:1502 > in thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.String:3266 > in thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} > ... > > In jdk 18 they are grouped now! > event set, policy:1, count:17 = > {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, > MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 > in thread main, MethodEntryEvent at java.lang.System:490 in thread main, > MethodEntryEvent at java.lang.System:198 in thread main, > MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in thread > main, MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in > thread main, MethodEntryEvent at java.lang.ClassLoader:664 in thread > main, MethodEntryEvent at java.lang.Object:44 in thread main, > MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in thread > main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in > thread main, MethodEntryEvent at java.lang.String:2336 in thread main, > MethodEntryEvent at java.lang.String:4546 in thread main, > MethodEntryEvent at java.lang.StringLatin1:192 in thread main, > MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in thread > main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in > thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in thread > main, > MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, > long)+-1 in thread main} > event set, policy:1, count:4 = > {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 in > thread main, MethodEntryEvent at java.lang.Object:44 in thread main, > MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 in thread > main, > MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, > long, java.lang.Object, java.lang.Object)+-1 in thread main} > event set, policy:1, count:2 = > {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in > thread main, > MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, > long, long, long)+-1 in thread main} > > Which is really strange and breaks some login in IDEA debugger. > > Without the active step request it works in jdk 18 as in jdk 11: > event set, policy:1, count:1 = > {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 > in thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:490 > in thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:198 > in thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in thread > main} > event set, policy:1, count:1 = > {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in thread > main} > event set, policy:1, count:1 = > {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.Object:44 > in thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in > thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in > thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.String:2336 > in thread main} > event set, policy:1, count:1 = {MethodEntryEvent at java.lang.String:4546 > in thread main} > event set, policy:1, count:1 = > {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} > > Could anyone have a look please. > Thanks, > Egor -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Fri Aug 5 22:42:21 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 Aug 2022 22:42:21 GMT Subject: Integrated: Merge jdk19 Message-ID: <4IiR0ks-fOPHmeHjgJbic_T8eJL9y8dlY9XG7buCgHQ=.03a74bca-e8f3-462f-b64c-3282e02eae04@github.com> Forward port JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8290562: ThreadMXBean.getThread{Cpu,User}Time fails with -XX:-VMContinuations The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9787&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9787&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9787/files Stats: 99 lines in 2 files changed: 78 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9787.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9787/head:pull/9787 PR: https://git.openjdk.org/jdk/pull/9787 From dholmes at openjdk.org Fri Aug 5 22:42:22 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 Aug 2022 22:42:22 GMT Subject: Integrated: Merge jdk19 In-Reply-To: <4IiR0ks-fOPHmeHjgJbic_T8eJL9y8dlY9XG7buCgHQ=.03a74bca-e8f3-462f-b64c-3282e02eae04@github.com> References: <4IiR0ks-fOPHmeHjgJbic_T8eJL9y8dlY9XG7buCgHQ=.03a74bca-e8f3-462f-b64c-3282e02eae04@github.com> Message-ID: On Fri, 5 Aug 2022 22:29:00 GMT, David Holmes wrote: > Forward port JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 87cda21c Author: David Holmes URL: https://git.openjdk.org/jdk/commit/87cda21c5d85f6e6f628849b8670e2ecb4e105dd Stats: 99 lines in 2 files changed: 78 ins; 0 del; 21 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9787 From iklam at openjdk.org Sat Aug 6 00:44:04 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 6 Aug 2022 00:44:04 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp Message-ID: To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: + java_lang_Thread_FieldHolder + java_lang_Thread_Constants + java_lang_ThreadGroup + java_lang_VirtualThread Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. ------------- Commit messages: - 8292006: Move thread accessor classes to threadJavaClasses.hpp Changes: https://git.openjdk.org/jdk/pull/9788/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9788&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292006 Stats: 1912 lines in 33 files changed: 1016 ins; 891 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9788.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9788/head:pull/9788 PR: https://git.openjdk.org/jdk/pull/9788 From duke at openjdk.org Sat Aug 6 09:05:12 2022 From: duke at openjdk.org (Patrick Pfeifer) Date: Sat, 6 Aug 2022 09:05:12 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons wrote: >> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. >> >> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: >> >> The Java manpage was missing updates from: >> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. >> >> The Java manpage has slight formatting differences from: >> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux >> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS >> >> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) >> >> >> The keytool manpage was missing updates from: >> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The jar manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jarsigner manpage was missing updates from: >> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The javadoc manpage was missing updates from: >> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option >> >> The jmod manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jpackage manpage was missing updates from: >> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature >> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 >> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code >> >> The jshell manpage was missing updates from: >> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. > > src/java.base/share/man/keytool.1 line 456: > >> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >> 455: keystore. >> 456: This option is used to sign the certificate with the signer?s private > > Not a problem with this PR as such, but we still have a `?` character in the output. Hello @jonathan-gibbons Excuse my hijacking / piggy-backing on this conversation! When you say > Not a problem with this PR as such, but we still have a `?` character in the output. This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? ------------- PR: https://git.openjdk.org/jdk19/pull/145 From egor.ushakov at jetbrains.com Sat Aug 6 09:18:12 2022 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Sat, 6 Aug 2022 11:18:12 +0200 Subject: Grouped method entry events In-Reply-To: References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> Message-ID: Hi Chris, I was able to somewhat reproduce it with jdb: compile any simple samle app like public class A { public static void main(String[] args) { System.out.println("A"); // line 3 } } now debug with jdb: ?% jdb A Initializing jdb ... > stop at A:3 Deferring breakpoint A:3. It will be set after the class is loaded. > run run A Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint A:3 Breakpoint hit: "thread=main", A.main(), line=3 bci=0 main[1] exclude none main[1] trace methods main[1] next > *Method entered: ** **Method entered: ** **Method entered: ** **Method entered: * Method exited: return value = false, "thread=main", java.lang.System.allowSecurityManager(), line=198 bci=12 main[1] next > Method exited: return value = null, "thread=main", java.lang.System.getSecurityManager(), line=493 bci=11 main[1] next > *Method entered: ** **Method entered: ** **Method entered: ** **Method entered:* Method exited: return value = , "thread=main", java.lang.Object.(), line=44 bci=0 main[1] next > *Method entered: ** **Method entered: ** **Method entered: ** **Method entered: * Method exited: return value = true, "thread=main", java.lang.String.isLatin1(), line=4,546 bci=18 Unfortunately jdb does not show method description for the events with suspend policy thread (except for the last one), but you can see that there are 5 events in one set here. Hope it helps, Egor On 05.08.2022 22:02, Chris Plummer wrote: > > Hi Egor, > > That is odd, and clearly wrong. It means that MethodEntryEvents are > being delivered when no longer even executing in the method. And you > are using the EVENT_THREAD suspend policy, so there should be a > suspend for each event. Offhand I can't think of any changes that > would have caused this. I also don't see how our testing would passed > with this behavior. I'm suspecting a faulty interaction with the debug > agent and IDEA (possibly the IDEA version of JDI). > > Can you see where the thread is actually suspended at when you get the > event set? > > Does this happen with 17 also? It would be nice to know what version > introduced this problem. > > Can you create a JDI test case for this? > > > Without the active step request it works in jdk 18 as in jdk 11: > > I'm not sure what you mean by "active step". Do you mean single > stepping is enabled? The JDWP spec does allow BreakPoint, SingleStep, > MethodEntry, and MethodExit events to be combined into the same > composite event (which should translate to the same JDI event set) if > they occur at the same location and in the same thread. So I can see > enabling single stepping having an impact on the behavior you are seeing. > > Chris > > On 8/5/22 9:59 AM, Egor Ushakov wrote: >> Hi, >> >> we're experiencing strange grouping of method entry/exit events, is >> this a bug or a feature? >> We have one method entry request active with suspend policy 1 >> (suspend thread). >> important: we also have one active step request (step over) >> >> In jdk 11 we have one composite event for each event, which is what's >> expected: >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 >> in thread main} >> event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:375 >> in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in >> thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in >> thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} >> event set, policy:1, count:1 = {MethodEntryEvent at java.lang.Object:50 >> in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >> thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >> thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.String:1502 in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.String:3266 in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} >> ... >> >> In jdk 18 they are grouped now! >> event set, policy:1, count:17 = >> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >> in thread main, MethodEntryEvent at java.lang.System:490 in thread main, >> MethodEntryEvent at java.lang.System:198 in thread main, >> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in thread >> main, MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >> thread main, MethodEntryEvent at java.lang.ClassLoader:664 in thread >> main, MethodEntryEvent at java.lang.Object:44 in thread main, >> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >> thread main, >> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >> thread main, MethodEntryEvent at java.lang.String:2336 in thread main, >> MethodEntryEvent at java.lang.String:4546 in thread main, >> MethodEntryEvent at java.lang.StringLatin1:192 in thread main, >> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in thread >> main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in >> thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in thread >> main, >> MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, >> long)+-1 in thread main} >> event set, policy:1, count:4 = >> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 in >> thread main, MethodEntryEvent at java.lang.Object:44 in thread main, >> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 in thread >> main, >> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, >> long, java.lang.Object, java.lang.Object)+-1 in thread main} >> event set, policy:1, count:2 = >> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in >> thread main, >> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, >> long, long, long)+-1 in thread main} >> >> Which is really strange and breaks some login in IDEA debugger. >> >> Without the active step request it works in jdk 18 as in jdk 11: >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >> in thread main} >> event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:490 >> in thread main} >> event set, policy:1, count:1 = {MethodEntryEvent at java.lang.System:198 >> in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >> thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >> thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} >> event set, policy:1, count:1 = {MethodEntryEvent at java.lang.Object:44 >> in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >> thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >> thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.String:2336 in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.String:4546 in thread main} >> event set, policy:1, count:1 = >> {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} >> >> Could anyone have a look please. >> Thanks, >> Egor -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.org Sat Aug 6 13:21:57 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 6 Aug 2022 13:21:57 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote: > To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: > > + java_lang_Thread_FieldHolder > + java_lang_Thread_Constants > + java_lang_ThreadGroup > + java_lang_VirtualThread > > Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. Hi Ioi, looks good. Small nits inline. I did not check that the moved code is identical, because I assume you just moved it around unchanged. Cheers, Thomas src/hotspot/share/runtime/threadJavaClasses.cpp line 36: > 34: #include "runtime/threadJavaClasses.hpp" > 35: #include "runtime/threadSMR.hpp" > 36: #include "runtime/vframe.inline.hpp" needs debug.hpp and macros.hpp, at least, to be self-contained. Probably globalDefinitions.hpp too. src/hotspot/share/runtime/threadJavaClasses.hpp line 31: > 29: #include "memory/allStatic.hpp" > 30: #include "oops/oopsHierarchy.hpp" > 31: #include "runtime/os.hpp" Where do you need os.hpp? src/hotspot/share/runtime/threadJavaClasses.inline.hpp line 32: > 30: #include "oops/instanceKlass.inline.hpp" > 31: #include "oops/oop.inline.hpp" > 32: #include "oops/oopsHierarchy.hpp" I believe that for INCLUDE_JFR you need macros.hpp, or? Highly likely it's already there, or you'd get linker errors. But it should be explicit. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9788 From duke at openjdk.org Sat Aug 6 13:54:20 2022 From: duke at openjdk.org (Patrick Pfeifer) Date: Sat, 6 Aug 2022 13:54:20 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: <_53Ro95x3TDbVcRUoOr4L0HiWCyepU8CgcyPCwLwKLA=.6ce49e6c-9b4b-4c8e-b0b8-7ec76b0f3d85@github.com> On Sat, 6 Aug 2022 09:01:39 GMT, Patrick Pfeifer wrote: >> src/java.base/share/man/keytool.1 line 456: >> >>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >>> 455: keystore. >>> 456: This option is used to sign the certificate with the signer?s private >> >> Not a problem with this PR as such, but we still have a `?` character in the output. > > Hello @jonathan-gibbons > > Excuse my hijacking / piggy-backing on this conversation! > > When you say > >> Not a problem with this PR as such, but we still have a `?` character in the output. > > This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? > > Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. > > I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? It did not take much effort to answer the last of the above question myself. > Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? Obviously "yes". HTML renderings can be found by following the, e.g. "[Java Development Kit Version 18 Tool Specifications](https://docs.oracle.com/en/java/javase/18/docs/specs/man/index.html)" Link on the "Specifications Overview" page at, e.g. "https://docs.oracle.com/en/java/javase/18/docs/specs/". Still hunting for the sources. ------------- PR: https://git.openjdk.org/jdk19/pull/145 From Alan.Bateman at oracle.com Sun Aug 7 15:52:30 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 7 Aug 2022 16:52:30 +0100 Subject: Grouped method entry events In-Reply-To: References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> Message-ID: <8f940ecc-10c5-ff97-685a-0cf91b741d72@oracle.com> On 06/08/2022 10:18, Egor Ushakov wrote: > Hi Chris, > > I was able to somewhat reproduce it with jdb: > compile any simple samle app like > public class A { > public static void main(String[] args) { > System.out.println("A"); // line 3 > } > } > I tried this with JDK 11, 17 and 19 and don't see any significant difference in the co-location. When you do "next" then? JDI will get events related to VM callout to checkPackageAccess. With JDK 11 I see 3 co-located events (2 entry, 1 exit) for the main thread. The libs code has changed a bit since then and for JDK 17 and 19 there are 5 co-located events (4 entry, 1 exit). I don't recall seeing anything go by that changed the code that decides if events are deferred. I think Chris is right that if there was something was broken then there would be test failures and bug reports. So I guess the question is whether the co-location with this example does reflect what you are seeing or if there is something else going on. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Sun Aug 7 22:13:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 7 Aug 2022 22:13:03 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote: > To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: > > + java_lang_Thread_FieldHolder > + java_lang_Thread_Constants > + java_lang_ThreadGroup > + java_lang_VirtualThread > > Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. javaClasses is not meant to be modular, and moving just a handful of items does not make it modular. I really like having all these Java accessors in one place. ------------- PR: https://git.openjdk.org/jdk/pull/9788 From dholmes at openjdk.org Sun Aug 7 22:16:43 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 7 Aug 2022 22:16:43 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 13:09:01 GMT, Thomas Stuefe wrote: >> To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: >> >> + java_lang_Thread_FieldHolder >> + java_lang_Thread_Constants >> + java_lang_ThreadGroup >> + java_lang_VirtualThread >> >> Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. > > src/hotspot/share/runtime/threadJavaClasses.inline.hpp line 32: > >> 30: #include "oops/instanceKlass.inline.hpp" >> 31: #include "oops/oop.inline.hpp" >> 32: #include "oops/oopsHierarchy.hpp" > > I believe that for INCLUDE_JFR you need macros.hpp, or? Highly likely it's already there, or you'd get linker errors. But it should be explicit. It is included in the .hpp file as it should be. ------------- PR: https://git.openjdk.org/jdk/pull/9788 From david.holmes at oracle.com Sun Aug 7 23:59:08 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Aug 2022 09:59:08 +1000 Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: <161d24ca-ff52-b2fe-0874-461e98900e28@oracle.com> Hi Patrick, On 6/08/2022 7:05 pm, Patrick Pfeifer wrote: > On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons wrote: > >>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. >> >> Not a problem with this PR as such, but we still have a `?` character in the output. > > Hello @jonathan-gibbons > > Excuse my hijacking / piggy-backing on this conversation! > > When you say > >> Not a problem with this PR as such, but we still have a `?` character in the output. > > This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? The sources to the manpages are not currently open sourced and so are held in Oracle's internal repository. Making them open-sourced has been a goal for some time now but has to overcome legal obstacles, but we are hopeful it will be "soon". > Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. > > I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? As you found, Oracle does provide these in html format. Cheers, David > ------------- > > PR: https://git.openjdk.org/jdk19/pull/145 From dholmes at openjdk.org Mon Aug 8 01:30:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Aug 2022 01:30:03 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote: > To improve modularity and build time, move the declaration of the following accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp: > > + java_lang_Thread_FieldHolder > + java_lang_Thread_Constants > + java_lang_ThreadGroup > + java_lang_VirtualThread > > Also move javaThreadStatus.hpp from share/classfile to share/runtime, where it belongs. My issue with these kinds of changes in general is that they: - undermine institutional memory - make it harder to do backports due to the shuffling - make it harder to track changes due to the shuffling So the benefit to me has to be more than just a small decrease in some build times which most people are never going to notice anyway. Sorry. Just my 2c. ------------- PR: https://git.openjdk.org/jdk/pull/9788 From iklam at openjdk.org Mon Aug 8 02:17:41 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 8 Aug 2022 02:17:41 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: References: Message-ID: <8uh4O1V5TnmKsKxB0blcohCIcM26deY35AKvEG11l_I=.1213fbe8-9793-46ee-9f6e-c2c82b55cfaf@github.com> On Mon, 8 Aug 2022 01:26:11 GMT, David Holmes wrote: > My issue with these kinds of changes in general is that they: > > * undermine institutional memory > * make it harder to do backports due to the shuffling > * make it harder to track changes due to the shuffling > > So the benefit to me has to be more than just a small decrease in some build times which most people are never going to notice anyway. Sorry. Just my 2c. While I understand the concerns, the above reason can be used against any sort of refactoring of the source code. We have a few decades of development, resulting slow but steady source code rot. We need to refactor the code when it makes sense to keep the repo healthy. Yes, the above are valid concerns, but we have been successful in dealing with them in past refactoring exercises. Build time is important for HotSpot developers. I figure that the header file refactoring that happened in the last year or so (by myself and others) have resulted in 20% or so reduction in build time. So of that was taken back, though, due to new features such as Loom. I tried to limit the amount of code to be moved. However, when a file like javaClasses.hpp grows to over 2000 lines or mostly unrelated declarations, it's a sign that it needs to be broken up (which I started doing since JDK-8288623). ------------- PR: https://git.openjdk.org/jdk/pull/9788 From dholmes at openjdk.org Mon Aug 8 02:58:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Aug 2022 02:58:58 GMT Subject: RFR: 8292006: Move thread accessor classes to threadJavaClasses.hpp In-Reply-To: <8uh4O1V5TnmKsKxB0blcohCIcM26deY35AKvEG11l_I=.1213fbe8-9793-46ee-9f6e-c2c82b55cfaf@github.com> References: <8uh4O1V5TnmKsKxB0blcohCIcM26deY35AKvEG11l_I=.1213fbe8-9793-46ee-9f6e-c2c82b55cfaf@github.com> Message-ID: On Mon, 8 Aug 2022 02:14:45 GMT, Ioi Lam wrote: > the above reason can be used against any sort of refactoring of the source code Indeed - they are always the "cons" of such a refactoring, and it is up to the "pros" to outweigh them. ------------- PR: https://git.openjdk.org/jdk/pull/9788 From chris.plummer at oracle.com Mon Aug 8 06:50:12 2022 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 7 Aug 2022 23:50:12 -0700 Subject: [External] : Re: Grouped method entry events In-Reply-To: References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> Message-ID: <8cdcf5f4-85ab-5b13-cb6f-249f61b62ba8@oracle.com> Hi Egor, The reason only the last event prints location information is because there is special logic in jdb that assumes if the suspend type is not SUSPEND_NONE, then we will be stopping, and that will result in the location info being printed. ??????? if (me.request().suspendPolicy() != EventRequest.SUSPEND_NONE) { ??????????? // We are stopping; the name will be shown by the normal mechanism ??????????? MessageOutput.lnprint("Method entered:"); ??????? } else { ??????????? // We aren't stopping, show the name ??????????? MessageOutput.print("Method entered:"); ??????????? printLocationOfEvent(me); ??????? } The assumption here is wrong with co-located events, since there could be more than one. However, normally it shouldn't matter since all colocated events are suppose to be at the same location, and if one is stopping then they all are. Yet clearly we are seeing that they are not all at the same location. When I enable location tracing for the first part of the "if" block, I get: > Method entered: "thread=main", java.lang.ClassLoader.loadClass(), line=521 bci=0 Method entered: "thread=main", jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(), line=180 bci=0 Method entered: "thread=main", java.lang.System.getSecurityManager(), line=497 bci=0 Method entered: "thread=main", java.lang.System.allowSecurityManager(), line=205 bci=0 Method exited: return value = false, "thread=main", java.lang.System.allowSecurityManager(), line=205 bci=12 I also printed out the EventSet, which confirms the same: event set, policy:2, count:5 = {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 in thread main, MethodEntryEvent at java.lang.System:497 in thread main, MethodEntryEvent at java.lang.System:205 in thread main, MethodExitEvent at java.lang.System:205 in thread main} The JDWP spec says: Several events may occur at a given time in the target VM. For example, there may be more than one breakpoint request for a given location or you might single step to the same location as a breakpoint request. These events are delivered together as a composite event. ... The events that are grouped in a composite event are restricted in the following ways: ... ? ? Only with other members of this group, at the same location and in the same thread: ??????? Breakpoint Event ??????? Step Event ??????? Method Entry Event ??????? Method Exit Event So there seems to be a debug agent bug that is grouping all the MethodEntry events until a MethodExit is hit. But I don't think this is new. I see the same thing in JDK11, but as Alan pointed out, there are fewer method calls. Chris On 8/6/22 2:18 AM, Egor Ushakov wrote: > Hi Chris, > > I was able to somewhat reproduce it with jdb: > compile any simple samle app like > > public class A { public static void main(String[] args) { > System.out.println("A"); // line 3 } } > now debug with jdb: > > ?% jdb A > Initializing jdb ... > > stop at A:3 > Deferring breakpoint A:3. > It will be set after the class is loaded. > > run > run A > Set uncaught java.lang.Throwable > Set deferred uncaught java.lang.Throwable > > > VM Started: Set deferred breakpoint A:3 > > Breakpoint hit: "thread=main", A.main(), line=3 bci=0 > > main[1] exclude none > main[1] trace methods > main[1] next > > > *Method entered: ** > **Method entered: ** > **Method entered: ** > **Method entered: * > Method exited: return value = false, "thread=main", > java.lang.System.allowSecurityManager(), line=198 bci=12 > > main[1] next > > > Method exited: return value = null, "thread=main", > java.lang.System.getSecurityManager(), line=493 bci=11 > > main[1] next > > > *Method entered: ** > **Method entered: ** > **Method entered: ** > **Method entered:* > Method exited: return value = , "thread=main", > java.lang.Object.(), line=44 bci=0 > > main[1] next > > > *Method entered: ** > **Method entered: ** > **Method entered: ** > **Method entered: * > Method exited: return value = true, "thread=main", > java.lang.String.isLatin1(), line=4,546 bci=18 > > Unfortunately jdb does not show method description for the events with > suspend policy thread (except for the last one), but you can see that > there are 5 events in one set here. > > Hope it helps, > Egor > > On 05.08.2022 22:02, Chris Plummer wrote: >> >> Hi Egor, >> >> >> That is odd, and clearly wrong. It means that MethodEntryEvents are >> being delivered when no longer even executing in the method. And you >> are using the EVENT_THREAD suspend policy, so there should be a >> suspend for each event. Offhand I can't think of any changes that >> would have caused this. I also don't see how our testing would passed >> with this behavior. I'm suspecting a faulty interaction with the >> debug agent and IDEA (possibly the IDEA version of JDI). >> >> Can you see where the thread is actually suspended at when you get >> the event set? >> >> Does this happen with 17 also? It would be nice to know what version >> introduced this problem. >> >> Can you create a JDI test case for this? >> >> >> > Without the active step request it works in jdk 18 as in jdk 11: >> >> >> I'm not sure what you mean by "active step". Do you mean single >> stepping is enabled? The JDWP spec does allow BreakPoint, SingleStep, >> MethodEntry, and MethodExit events to be combined into the same >> composite event (which should translate to the same JDI event set) if >> they occur at the same location and in the same thread. So I can see >> enabling single stepping having an impact on the behavior you are seeing. >> >> >> Chris >> >> On 8/5/22 9:59 AM, Egor Ushakov wrote: >>> Hi, >>> >>> we're experiencing strange grouping of method entry/exit events, is >>> this a bug or a feature? >>> We have one method entry request active with suspend policy 1 >>> (suspend thread). >>> important: we also have one active step request (step over) >>> >>> In jdk 11 we have one composite event for each event, which is >>> what's expected: >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 >>> in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.System:375 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in >>> thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in >>> thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} >>> event set, policy:1, count:1 = {MethodEntryEvent at java.lang.Object:50 >>> in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>> thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>> thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.String:1502 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.String:3266 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} >>> ... >>> >>> In jdk 18 they are grouped now! >>> event set, policy:1, count:17 = >>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >>> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>> in thread main, MethodEntryEvent at java.lang.System:490 in thread >>> main, MethodEntryEvent at java.lang.System:198 in thread main, >>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>> thread main, >>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>> thread main, MethodEntryEvent at java.lang.ClassLoader:664 in thread >>> main, MethodEntryEvent at java.lang.Object:44 in thread main, >>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>> thread main, >>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>> thread main, MethodEntryEvent at java.lang.String:2336 in thread main, >>> MethodEntryEvent at java.lang.String:4546 in thread main, >>> MethodEntryEvent at java.lang.StringLatin1:192 in thread main, >>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in >>> thread main, >>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in >>> thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in >>> thread main, >>> MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, >>> long)+-1 in thread main} >>> event set, policy:1, count:4 = >>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 in >>> thread main, MethodEntryEvent at java.lang.Object:44 in thread main, >>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 in >>> thread main, >>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, >>> long, java.lang.Object, java.lang.Object)+-1 in thread main} >>> event set, policy:1, count:2 = >>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in >>> thread main, >>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, >>> long, long, long)+-1 in thread main} >>> >>> Which is really strange and breaks some login in IDEA debugger. >>> >>> Without the active step request it works in jdk 18 as in jdk 11: >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>> in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.System:490 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.System:198 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>> thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>> thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} >>> event set, policy:1, count:1 = {MethodEntryEvent at java.lang.Object:44 >>> in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>> thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>> thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.String:2336 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.String:4546 in thread main} >>> event set, policy:1, count:1 = >>> {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} >>> >>> Could anyone have a look please. >>> Thanks, >>> Egor > From chris.plummer at oracle.com Mon Aug 8 07:50:49 2022 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 8 Aug 2022 00:50:49 -0700 Subject: [External] : Re: Grouped method entry events In-Reply-To: <8cdcf5f4-85ab-5b13-cb6f-249f61b62ba8@oracle.com> References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> <8cdcf5f4-85ab-5b13-cb6f-249f61b62ba8@oracle.com> Message-ID: <7ffbc220-94ee-e8ab-3e81-8aa573c8f18f@oracle.com> I think the issue is that when you issue a "next", jvmti single stepping is enabled. That means when the first MethodEntry event is triggered, it is automatically deferred. See the following in deferEventReport: ??????? case EI_METHOD_ENTRY: ??????????????? error = methodLocation(method, &start, &end); ??????????????? if (error == JVMTI_ERROR_NONE) { ??????????????????? deferring = isBreakpointSet(clazz, method, start) || threadControl_getInstructionStepMode(thread) ??????????????????????????????????? == JVMTI_ENABLE; When using (JDWP) STEP_OVER, JVMTI single stepping is only enabled during the call to the method, which allows the debug agent to stop on the first instruction of the called method. After that it disables JVMTI single stepping (until there is a FramePop). When the above code is executed for METHOD_ENTRY, JVMTI single stepping is enabled. When JVMTI is returned to, it then sends a SINGLE_STEP event, but this is a special one just used by the debug agent, and not sent on the the debugger. So we never hit the code right below the above code that handles colocating the SINGLE_STEP event. ??????? case EI_SINGLE_STEP: ??????????? deferring = isBreakpointSet(clazz, method, location); ??????????? if (deferring) { ??????????????? threadControl_saveCLEInfo(env, thread, ei, ????????????????????????????????????????? clazz, method, location); ??????????? } Meanwhile the generated MethodEntry event sits in the thread's event bag, and I guess gets added to when the next MethodEntry happens. This goes on on a MethodExit event is generated, witch seems to push out all pending events (there is actually no logic in the debug agent to colocate MethodExit events, which seems odd). So bottom line is that the CLE code is wrong when JVMTI single stepping is enabled for the sake of supporting a JDWP STEP_OVER. I think instead of checking if JVMTI single stepping is enabled, it should be checking if the current StepDepth is INTO, although I suspect there might be other factors to consider that will make the check more complicated. I'll look at this some more tomorrow. Chris On 8/7/22 11:50 PM, Chris Plummer wrote: > Hi Egor, > > The reason only the last event prints location information is because > there is special logic in jdb that assumes if the suspend type is not > SUSPEND_NONE, then we will be stopping, and that will result in the > location info being printed. > > ??????? if (me.request().suspendPolicy() != EventRequest.SUSPEND_NONE) { > ??????????? // We are stopping; the name will be shown by the normal > mechanism > ??????????? MessageOutput.lnprint("Method entered:"); > ??????? } else { > ??????????? // We aren't stopping, show the name > ??????????? MessageOutput.print("Method entered:"); > ??????????? printLocationOfEvent(me); > ??????? } > > The assumption here is wrong with co-located events, since there could > be more than one. However, normally it shouldn't matter since all > colocated events are suppose to be at the same location, and if one is > stopping then they all are. Yet clearly we are seeing that they are > not all at the same location. When I enable location tracing for the > first part of the "if" block, I get: > > > Method entered: "thread=main", java.lang.ClassLoader.loadClass(), > line=521 bci=0 > Method entered: "thread=main", > jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(), line=180 > bci=0 > Method entered: "thread=main", java.lang.System.getSecurityManager(), > line=497 bci=0 > Method entered: "thread=main", > java.lang.System.allowSecurityManager(), line=205 bci=0 > Method exited: return value = false, "thread=main", > java.lang.System.allowSecurityManager(), line=205 bci=12 > > I also printed out the EventSet, which confirms the same: > > event set, policy:2, count:5 = > {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, > MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 > in thread main, MethodEntryEvent at java.lang.System:497 in thread main, > MethodEntryEvent at java.lang.System:205 in thread main, > MethodExitEvent at java.lang.System:205 in thread main} > > The JDWP spec says: > > Several events may occur at a given time in the target VM. For > example, there may be more than one breakpoint request for a given > location or you might single step to the same location as a breakpoint > request. These events are delivered together as a composite event. > ... > The events that are grouped in a composite event are restricted in the > following ways: > ... > ? ? Only with other members of this group, at the same location and in > the same thread: > ??????? Breakpoint Event > ??????? Step Event > ??????? Method Entry Event > ??????? Method Exit Event > > So there seems to be a debug agent bug that is grouping all the > MethodEntry events until a MethodExit is hit. But I don't think this > is new. I see the same thing in JDK11, but as Alan pointed out, there > are fewer method calls. > > Chris > > On 8/6/22 2:18 AM, Egor Ushakov wrote: >> Hi Chris, >> >> I was able to somewhat reproduce it with jdb: >> compile any simple samle app like >> >> public class A { public static void main(String[] args) { >> System.out.println("A"); // line 3 } } >> now debug with jdb: >> >> ?% jdb A >> Initializing jdb ... >> > stop at A:3 >> Deferring breakpoint A:3. >> It will be set after the class is loaded. >> > run >> run A >> Set uncaught java.lang.Throwable >> Set deferred uncaught java.lang.Throwable >> > >> VM Started: Set deferred breakpoint A:3 >> >> Breakpoint hit: "thread=main", A.main(), line=3 bci=0 >> >> main[1] exclude none >> main[1] trace methods >> main[1] next >> > >> *Method entered: ** >> **Method entered: ** >> **Method entered: ** >> **Method entered: * >> Method exited: return value = false, "thread=main", >> java.lang.System.allowSecurityManager(), line=198 bci=12 >> >> main[1] next >> > >> Method exited: return value = null, "thread=main", >> java.lang.System.getSecurityManager(), line=493 bci=11 >> >> main[1] next >> > >> *Method entered: ** >> **Method entered: ** >> **Method entered: ** >> **Method entered:* >> Method exited: return value = , "thread=main", >> java.lang.Object.(), line=44 bci=0 >> >> main[1] next >> > >> *Method entered: ** >> **Method entered: ** >> **Method entered: ** >> **Method entered: * >> Method exited: return value = true, "thread=main", >> java.lang.String.isLatin1(), line=4,546 bci=18 >> >> Unfortunately jdb does not show method description for the events >> with suspend policy thread (except for the last one), but you can see >> that there are 5 events in one set here. >> >> Hope it helps, >> Egor >> >> On 05.08.2022 22:02, Chris Plummer wrote: >>> >>> Hi Egor, >>> >>> >>> That is odd, and clearly wrong. It means that MethodEntryEvents are >>> being delivered when no longer even executing in the method. And you >>> are using the EVENT_THREAD suspend policy, so there should be a >>> suspend for each event. Offhand I can't think of any changes that >>> would have caused this. I also don't see how our testing would >>> passed with this behavior. I'm suspecting a faulty interaction with >>> the debug agent and IDEA (possibly the IDEA version of JDI). >>> >>> Can you see where the thread is actually suspended at when you get >>> the event set? >>> >>> Does this happen with 17 also? It would be nice to know what version >>> introduced this problem. >>> >>> Can you create a JDI test case for this? >>> >>> >>> > Without the active step request it works in jdk 18 as in jdk 11: >>> >>> >>> I'm not sure what you mean by "active step". Do you mean single >>> stepping is enabled? The JDWP spec does allow BreakPoint, >>> SingleStep, MethodEntry, and MethodExit events to be combined into >>> the same composite event (which should translate to the same JDI >>> event set) if they occur at the same location and in the same >>> thread. So I can see enabling single stepping having an impact on >>> the behavior you are seeing. >>> >>> >>> Chris >>> >>> On 8/5/22 9:59 AM, Egor Ushakov wrote: >>>> Hi, >>>> >>>> we're experiencing strange grouping of method entry/exit events, is >>>> this a bug or a feature? >>>> We have one method entry request active with suspend policy 1 >>>> (suspend thread). >>>> important: we also have one active step request (step over) >>>> >>>> In jdk 11 we have one composite event for each event, which is >>>> what's expected: >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 >>>> in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.System:375 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in >>>> thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in >>>> thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.Object:50 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>> thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>> thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.String:1502 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.String:3266 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} >>>> ... >>>> >>>> In jdk 18 they are grouped now! >>>> event set, policy:1, count:17 = >>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >>>> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>> in thread main, MethodEntryEvent at java.lang.System:490 in thread >>>> main, MethodEntryEvent at java.lang.System:198 in thread main, >>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>> thread main, >>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>> thread main, MethodEntryEvent at java.lang.ClassLoader:664 in thread >>>> main, MethodEntryEvent at java.lang.Object:44 in thread main, >>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>> thread main, >>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>> thread main, MethodEntryEvent at java.lang.String:2336 in thread main, >>>> MethodEntryEvent at java.lang.String:4546 in thread main, >>>> MethodEntryEvent at java.lang.StringLatin1:192 in thread main, >>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in >>>> thread main, >>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in >>>> thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in >>>> thread main, >>>> MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, >>>> long)+-1 in thread main} >>>> event set, policy:1, count:4 = >>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 >>>> in thread main, MethodEntryEvent at java.lang.Object:44 in thread >>>> main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 >>>> in thread main, >>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, >>>> long, java.lang.Object, java.lang.Object)+-1 in thread main} >>>> event set, policy:1, count:2 = >>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in >>>> thread main, >>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, >>>> long, long, long)+-1 in thread main} >>>> >>>> Which is really strange and breaks some login in IDEA debugger. >>>> >>>> Without the active step request it works in jdk 18 as in jdk 11: >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>> in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.System:490 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.System:198 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>> thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>> thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.Object:44 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>> thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>> thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.String:2336 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.String:4546 in thread main} >>>> event set, policy:1, count:1 = >>>> {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} >>>> >>>> Could anyone have a look please. >>>> Thanks, >>>> Egor >> From egor.ushakov at jetbrains.com Mon Aug 8 11:13:43 2022 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Mon, 8 Aug 2022 13:13:43 +0200 Subject: [External] : Re: Grouped method entry events In-Reply-To: <7ffbc220-94ee-e8ab-3e81-8aa573c8f18f@oracle.com> References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> <8cdcf5f4-85ab-5b13-cb6f-249f61b62ba8@oracle.com> <7ffbc220-94ee-e8ab-3e81-8aa573c8f18f@oracle.com> Message-ID: <1af58363-fa21-d899-f6d1-9cb3ad2278af@jetbrains.com> Thanks, Chris! We'll try to implement a workaround in IDEA to ignore such merged events somehow. Egor On 08.08.2022 09:50, Chris Plummer wrote: > I think the issue is that when you issue a "next", jvmti single > stepping is enabled. That means when the first MethodEntry event is > triggered, it is automatically deferred. See the following in > deferEventReport: > > ??????? case EI_METHOD_ENTRY: > ??????????????? error = methodLocation(method, &start, &end); > ??????????????? if (error == JVMTI_ERROR_NONE) { > ??????????????????? deferring = isBreakpointSet(clazz, method, start) || > threadControl_getInstructionStepMode(thread) > ??????????????????????????????????? == JVMTI_ENABLE; > > > When using (JDWP) STEP_OVER, JVMTI single stepping is only enabled > during the call to the method, which allows the debug agent to stop on > the first instruction of the called method. After that it disables > JVMTI single stepping (until there is a FramePop). When the above code > is executed for METHOD_ENTRY, JVMTI single stepping is enabled. When > JVMTI is returned to, it then sends a SINGLE_STEP event, but this is a > special one just used by the debug agent, and not sent on the the > debugger. So we never hit the code right below the above code that > handles colocating the SINGLE_STEP event. > > ??????? case EI_SINGLE_STEP: > ??????????? deferring = isBreakpointSet(clazz, method, location); > ??????????? if (deferring) { > ??????????????? threadControl_saveCLEInfo(env, thread, ei, > ????????????????????????????????????????? clazz, method, location); > ??????????? } > > Meanwhile the generated MethodEntry event sits in the thread's event > bag, and I guess gets added to when the next MethodEntry happens. This > goes on on a MethodExit event is generated, witch seems to push out > all pending events (there is actually no logic in the debug agent to > colocate MethodExit events, which seems odd). > > So bottom line is that the CLE code is wrong when JVMTI single > stepping is enabled for the sake of supporting a JDWP STEP_OVER. I > think instead of checking if JVMTI single stepping is enabled, it > should be checking if the current StepDepth is INTO, although I > suspect there might be other factors to consider that will make the > check more complicated. > > I'll look at this some more tomorrow. > > Chris > > On 8/7/22 11:50 PM, Chris Plummer wrote: >> Hi Egor, >> >> The reason only the last event prints location information is because >> there is special logic in jdb that assumes if the suspend type is not >> SUSPEND_NONE, then we will be stopping, and that will result in the >> location info being printed. >> >> ??????? if (me.request().suspendPolicy() != EventRequest.SUSPEND_NONE) { >> ??????????? // We are stopping; the name will be shown by the normal >> mechanism >> ??????????? MessageOutput.lnprint("Method entered:"); >> ??????? } else { >> ??????????? // We aren't stopping, show the name >> ??????????? MessageOutput.print("Method entered:"); >> ??????????? printLocationOfEvent(me); >> ??????? } >> >> The assumption here is wrong with co-located events, since there >> could be more than one. However, normally it shouldn't matter since >> all colocated events are suppose to be at the same location, and if >> one is stopping then they all are. Yet clearly we are seeing that >> they are not all at the same location. When I enable location tracing >> for the first part of the "if" block, I get: >> >> > Method entered: "thread=main", java.lang.ClassLoader.loadClass(), >> line=521 bci=0 >> Method entered: "thread=main", >> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(), line=180 >> bci=0 >> Method entered: "thread=main", java.lang.System.getSecurityManager(), >> line=497 bci=0 >> Method entered: "thread=main", >> java.lang.System.allowSecurityManager(), line=205 bci=0 >> Method exited: return value = false, "thread=main", >> java.lang.System.allowSecurityManager(), line=205 bci=12 >> >> I also printed out the EventSet, which confirms the same: >> >> event set, policy:2, count:5 = >> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >> in thread main, MethodEntryEvent at java.lang.System:497 in thread main, >> MethodEntryEvent at java.lang.System:205 in thread main, >> MethodExitEvent at java.lang.System:205 in thread main} >> >> The JDWP spec says: >> >> Several events may occur at a given time in the target VM. For >> example, there may be more than one breakpoint request for a given >> location or you might single step to the same location as a >> breakpoint request. These events are delivered together as a >> composite event. >> ... >> The events that are grouped in a composite event are restricted in >> the following ways: >> ... >> ? ? Only with other members of this group, at the same location and >> in the same thread: >> ??????? Breakpoint Event >> ??????? Step Event >> ??????? Method Entry Event >> ??????? Method Exit Event >> >> So there seems to be a debug agent bug that is grouping all the >> MethodEntry events until a MethodExit is hit. But I don't think this >> is new. I see the same thing in JDK11, but as Alan pointed out, there >> are fewer method calls. >> >> Chris >> >> On 8/6/22 2:18 AM, Egor Ushakov wrote: >>> Hi Chris, >>> >>> I was able to somewhat reproduce it with jdb: >>> compile any simple samle app like >>> >>> public class A { public static void main(String[] args) { >>> System.out.println("A"); // line 3 } } >>> now debug with jdb: >>> >>> ?% jdb A >>> Initializing jdb ... >>> > stop at A:3 >>> Deferring breakpoint A:3. >>> It will be set after the class is loaded. >>> > run >>> run A >>> Set uncaught java.lang.Throwable >>> Set deferred uncaught java.lang.Throwable >>> > >>> VM Started: Set deferred breakpoint A:3 >>> >>> Breakpoint hit: "thread=main", A.main(), line=3 bci=0 >>> >>> main[1] exclude none >>> main[1] trace methods >>> main[1] next >>> > >>> *Method entered: ** >>> **Method entered: ** >>> **Method entered: ** >>> **Method entered: * >>> Method exited: return value = false, "thread=main", >>> java.lang.System.allowSecurityManager(), line=198 bci=12 >>> >>> main[1] next >>> > >>> Method exited: return value = null, "thread=main", >>> java.lang.System.getSecurityManager(), line=493 bci=11 >>> >>> main[1] next >>> > >>> *Method entered: ** >>> **Method entered: ** >>> **Method entered: ** >>> **Method entered:* >>> Method exited: return value = , "thread=main", >>> java.lang.Object.(), line=44 bci=0 >>> >>> main[1] next >>> > >>> *Method entered: ** >>> **Method entered: ** >>> **Method entered: ** >>> **Method entered: * >>> Method exited: return value = true, "thread=main", >>> java.lang.String.isLatin1(), line=4,546 bci=18 >>> >>> Unfortunately jdb does not show method description for the events >>> with suspend policy thread (except for the last one), but you can >>> see that there are 5 events in one set here. >>> >>> Hope it helps, >>> Egor >>> >>> On 05.08.2022 22:02, Chris Plummer wrote: >>>> >>>> Hi Egor, >>>> >>>> >>>> That is odd, and clearly wrong. It means that MethodEntryEvents are >>>> being delivered when no longer even executing in the method. And >>>> you are using the EVENT_THREAD suspend policy, so there should be a >>>> suspend for each event. Offhand I can't think of any changes that >>>> would have caused this. I also don't see how our testing would >>>> passed with this behavior. I'm suspecting a faulty interaction with >>>> the debug agent and IDEA (possibly the IDEA version of JDI). >>>> >>>> Can you see where the thread is actually suspended at when you get >>>> the event set? >>>> >>>> Does this happen with 17 also? It would be nice to know what >>>> version introduced this problem. >>>> >>>> Can you create a JDI test case for this? >>>> >>>> >>>> > Without the active step request it works in jdk 18 as in jdk 11: >>>> >>>> >>>> I'm not sure what you mean by "active step". Do you mean single >>>> stepping is enabled? The JDWP spec does allow BreakPoint, >>>> SingleStep, MethodEntry, and MethodExit events to be combined into >>>> the same composite event (which should translate to the same JDI >>>> event set) if they occur at the same location and in the same >>>> thread. So I can see enabling single stepping having an impact on >>>> the behavior you are seeing. >>>> >>>> >>>> Chris >>>> >>>> On 8/5/22 9:59 AM, Egor Ushakov wrote: >>>>> Hi, >>>>> >>>>> we're experiencing strange grouping of method entry/exit events, >>>>> is this a bug or a feature? >>>>> We have one method entry request active with suspend policy 1 >>>>> (suspend thread). >>>>> important: we also have one active step request (step over) >>>>> >>>>> In jdk 11 we have one composite event for each event, which is >>>>> what's expected: >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 >>>>> in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.System:375 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.Object:50 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.String:1502 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.String:3266 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} >>>>> ... >>>>> >>>>> In jdk 18 they are grouped now! >>>>> event set, policy:1, count:17 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >>>>> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>>> in thread main, MethodEntryEvent at java.lang.System:490 in thread >>>>> main, MethodEntryEvent at java.lang.System:198 in thread main, >>>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>>> thread main, >>>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>>> thread main, MethodEntryEvent at java.lang.ClassLoader:664 in thread >>>>> main, MethodEntryEvent at java.lang.Object:44 in thread main, >>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>> thread main, >>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>> thread main, MethodEntryEvent at java.lang.String:2336 in thread >>>>> main, MethodEntryEvent at java.lang.String:4546 in thread main, >>>>> MethodEntryEvent at java.lang.StringLatin1:192 in thread main, >>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in >>>>> thread main, >>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in >>>>> thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in >>>>> thread main, >>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, >>>>> long)+-1 in thread main} >>>>> event set, policy:1, count:4 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 >>>>> in thread main, MethodEntryEvent at java.lang.Object:44 in thread >>>>> main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 >>>>> in thread main, >>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, >>>>> long, java.lang.Object, java.lang.Object)+-1 in thread main} >>>>> event set, policy:1, count:2 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in >>>>> thread main, >>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, >>>>> long, long, long)+-1 in thread main} >>>>> >>>>> Which is really strange and breaks some login in IDEA debugger. >>>>> >>>>> Without the active step request it works in jdk 18 as in jdk 11: >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>>> in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.System:490 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.System:198 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.Object:44 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.String:2336 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.String:4546 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} >>>>> >>>>> Could anyone have a look please. >>>>> Thanks, >>>>> Egor >>> From duke at openjdk.org Mon Aug 8 15:11:19 2022 From: duke at openjdk.org (Bill Huang) Date: Mon, 8 Aug 2022 15:11:19 GMT Subject: Integrated: 8290180: Convert com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to jtreg java version In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 21:56:57 GMT, Bill Huang wrote: > This is a task to convert shell tests to Java tests. The shell scripts to be removed are responsible for compiling Java files and running the tests on Linux systems. This functionality can be achieved with JTReg tag @requires (os.family=="linux"). This pull request has now been integrated. Changeset: 124fc4a8 Author: Bill Huang Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/124fc4a83dc7e55c3b12e4b6c379391ab11592d5 Stats: 173 lines in 4 files changed: 1 ins; 147 del; 25 mod 8290180: Convert com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh to jtreg java version 8290181: convert com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh to java version Reviewed-by: lmesnik, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9503 From lmesnik at openjdk.org Mon Aug 8 20:02:24 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Aug 2022 20:02:24 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" Message-ID: The test should use the same locales in all processes, the default language should work fine. ------------- Commit messages: - 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" Changes: https://git.openjdk.org/jdk/pull/9798/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9798&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291081 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9798/head:pull/9798 PR: https://git.openjdk.org/jdk/pull/9798 From dlong at openjdk.org Mon Aug 8 20:51:08 2022 From: dlong at openjdk.org (Dean Long) Date: Mon, 8 Aug 2022 20:51:08 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2] In-Reply-To: References: Message-ID: On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add assertions > - Fix marked logic > - Erik refactorings If the nmethod shouldn't be on the marked list at certain state transitions, how about adding asserts that check this? Using the same "self looped" trick that the Sweeper removal PR uses might help with that. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From cjplummer at openjdk.org Mon Aug 8 21:34:53 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 8 Aug 2022 21:34:53 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 19:52:47 GMT, Leonid Mesnik wrote: > The test should use the same locales in all processes, the default language should work fine. Can you explain why setting the locale on the test but not the subprocess is causing the failure? ------------- PR: https://git.openjdk.org/jdk/pull/9798 From lmesnik at openjdk.org Mon Aug 8 21:43:54 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Aug 2022 21:43:54 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 21:31:27 GMT, Chris Plummer wrote: > Can you explain why setting the locale on the test but not the subprocess is causing the failure? The jstatd process prints some numbers always using "en" locale and "." as decimal separators. While reading process might have different locale ("vi" for example) and use "," as a decimal separator. So test fails to parse such numbers. ------------- PR: https://git.openjdk.org/jdk/pull/9798 From kevinw at openjdk.org Mon Aug 8 21:52:24 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 8 Aug 2022 21:52:24 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 19:52:47 GMT, Leonid Mesnik wrote: > The test should use the same locales in all processes, the default language should work fine. I tried a few locales and could not reproduce the problem, I was expecting some kind of mismatch would trigger it, but not sure what to set where to cause this... Something else I noticed while looking however: I looked at JstatGCUtilParser.java / verify(String... valueArray) I see it checks values are of the right type: but after almost all checks, it does a "break", so stops iterating values. Only percentage checks permit checking to continue. 8-) There are three "break" statements in verify(String... valueArray) which should be "continue". We can handle that in a separate issue. ------------- PR: https://git.openjdk.org/jdk/pull/9798 From lmesnik at openjdk.org Tue Aug 9 02:35:14 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Aug 2022 02:35:14 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v2] In-Reply-To: References: Message-ID: <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com> > The test should use the same locales in all processes, the default language should work fine. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9798/files - new: https://git.openjdk.org/jdk/pull/9798/files/b7491b7d..50c562dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9798&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9798&range=00-01 Stats: 20 lines in 1 file changed: 6 ins; 4 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/9798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9798/head:pull/9798 PR: https://git.openjdk.org/jdk/pull/9798 From lmesnik at openjdk.org Tue Aug 9 02:38:28 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Aug 2022 02:38:28 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v2] In-Reply-To: <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com> References: <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com> Message-ID: On Tue, 9 Aug 2022 02:35:14 GMT, Leonid Mesnik wrote: >> The test should use the same locales in all processes, the default language should work fine. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix > I tried a few locales and could not reproduce the problem, I was expecting some kind of mismatch would trigger it, but not sure what to set and where to cause this... It is needed to verify that the locale in java has been changed and that not G1 is used. The G1 'S0' is 0.00 which is zero for all locales and test passe because of your issue. I used additional logs to check that locale was actually updated. Also, it is needed to see language with "," as a decimal delimiter. > > Something else I noticed while looking, however: I looked at JstatGCUtilParser.java / verify(String... valueArray) I see it checks values are of the right type: but after almost all checks, it does a "break", so stops iterating values. Only percentage checks permit checking to continue. 8-) There are three "break" statements in verify(String... valueArray) which should be "continue". We can handle that in a separate issue. Thank you! that explains a lot! I've updated the fix. ------------- PR: https://git.openjdk.org/jdk/pull/9798 From kevinw at openjdk.org Tue Aug 9 14:22:36 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Aug 2022 14:22:36 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v2] In-Reply-To: <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com> References: <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com> Message-ID: On Tue, 9 Aug 2022 02:35:14 GMT, Leonid Mesnik wrote: >> The test should use the same locales in all processes, the default language should work fine. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix Thanks, great to fix the verifier now if we can. I do think that never setting user.language is good. Forcing jstat to run with user.language=en could be wrong, as there is a risk of mismatching the printing and the verification. BUT I don't see why I can't reproduce the problem.. The report is on Windows, and I can sign in using a non-English language but can't make the test fail!... But then it's not the parsing in NumberFormat that fails, it's the assert afterwards. ----------System.err:(19/1147)---------- java.lang.RuntimeException: Not a percentage: 68.31: expected true, was false Annoyingly we print the literal String value "68.31" but not the double percentage that it parsed.... ------------- PR: https://git.openjdk.org/jdk/pull/9798 From asemenyuk at openjdk.org Tue Aug 9 17:53:36 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 9 Aug 2022 17:53:36 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung wrote: >> open l10n msg drop >> All tests passed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation Marked as reviewed by asemenyuk (Reviewer). jpackage changes look good. Approved that part. ------------- PR: https://git.openjdk.org/jdk19/pull/154 From lmesnik at openjdk.org Tue Aug 9 20:29:42 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Aug 2022 20:29:42 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v3] In-Reply-To: References: Message-ID: > The test should use the same locales in all processes, the default language should work fine. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed print ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9798/files - new: https://git.openjdk.org/jdk/pull/9798/files/50c562dc..2702a24a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9798&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9798&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9798/head:pull/9798 PR: https://git.openjdk.org/jdk/pull/9798 From lmesnik at openjdk.org Tue Aug 9 20:37:45 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Aug 2022 20:37:45 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v2] In-Reply-To: References: <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com> Message-ID: On Tue, 9 Aug 2022 14:20:13 GMT, Kevin Walls wrote: > Thanks, great to fix the verifier now if we can. > > I do think that never setting user.language is good. Forcing jstat to run with user.language=en could be wrong, as there is a risk of mismatching the printing and the verification. > > BUT I don't see why I can't reproduce the problem.. The report is on Windows, and I can sign in using a non-English language but can't make the test fail!... I didn't try to change system locale. I used TEST_OPTS_JAVA_OPTIONS="-Duser.language=vi" to verify that it fails wit this message and set '-Duser.language=vi' for jstat to see that test pass if all locales are same. You could try just to print numbers in java to check if "," actually used as decimal separator. Also the "S0" should not be zero to fail. > > But then it's not the parsing in NumberFormat that fails, it's the assert afterwards. > Yep, the number is parsed without exception because the "." is a thousand separator. So it is just ignored. > > Annoyingly we print the literal String value "68.31" but not the double percentage that it parsed.... Fixed to print value. Now: java.lang.RuntimeException: Not a percentage. value: 91.10 percentage: 9110.0: expected true, was false ------------- PR: https://git.openjdk.org/jdk/pull/9798 From duke at openjdk.org Tue Aug 9 21:23:04 2022 From: duke at openjdk.org (Bill Huang) Date: Tue, 9 Aug 2022 21:23:04 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version Message-ID: This task converts 5 shell tests below to java version. test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh test/java/lang/management/MemoryMXBean/PendingAllGC.sh ------------- Commit messages: - Removed othervm option in Pending.java. - Converted MemoryMXBean shell tests to java version. Changes: https://git.openjdk.org/jdk/pull/9813/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292064 Stats: 356 lines in 9 files changed: 48 ins; 303 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9813/head:pull/9813 PR: https://git.openjdk.org/jdk/pull/9813 From lmesnik at openjdk.org Tue Aug 9 22:30:32 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Aug 2022 22:30:32 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang wrote: > This task converts 5 shell tests below to java version. > test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh > test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh > test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh > test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > test/java/lang/management/MemoryMXBean/PendingAllGC.sh Isn't it a good time to remove all GC settings and allow user to set GC? Also, remove or update 'requires' if any of GC are not supported, ------------- PR: https://git.openjdk.org/jdk/pull/9813 From achung at openjdk.org Tue Aug 9 22:30:54 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 Aug 2022 22:30:54 GMT Subject: [jdk19] Integrated: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung wrote: > open l10n msg drop > All tests passed. This pull request has now been integrated. Changeset: 0def5316 Author: Alisen Chung Committer: Alexey Semenyuk URL: https://git.openjdk.org/jdk19/commit/0def5316cd2ec7699c649bf67bf58e6315c3010b Stats: 684 lines in 42 files changed: 87 ins; 540 del; 57 mod 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 Reviewed-by: naoto, asemenyuk ------------- PR: https://git.openjdk.org/jdk19/pull/154 From kevinw at openjdk.org Tue Aug 9 22:36:35 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Aug 2022 22:36:35 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v3] In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 20:29:42 GMT, Leonid Mesnik wrote: >> The test should use the same locales in all processes, the default language should work fine. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed print Marked as reviewed by kevinw (Committer). OK, I did not know that user.language=vi was the trick to make it fail. With that I see the failure (at last! 8-) ). (I had tried other European languages that use , as a decimal separator, and don't fail. Different thousands separator behaviour or just values that weren't out of range?...) You get 91.10 parsed as 9110.0 which seems odd, it's not 91 thousand... But I find comments that grouping (thousands) chars might be ignored when parsing. So mystery is I think solved, and the test is improved! 8-) ------------- PR: https://git.openjdk.org/jdk/pull/9798 From duke at openjdk.org Wed Aug 10 02:10:25 2022 From: duke at openjdk.org (xpbob) Date: Wed, 10 Aug 2022 02:10:25 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v10] In-Reply-To: References: Message-ID: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with one additional commit since the last revision: add bean to list ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/2c149c10..fa6fed19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=08-09 Stats: 210 lines in 4 files changed: 120 ins; 86 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From chris.plummer at oracle.com Wed Aug 10 03:25:50 2022 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 9 Aug 2022 20:25:50 -0700 Subject: [External] : Re: Grouped method entry events In-Reply-To: <7ffbc220-94ee-e8ab-3e81-8aa573c8f18f@oracle.com> References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> <8cdcf5f4-85ab-5b13-cb6f-249f61b62ba8@oracle.com> <7ffbc220-94ee-e8ab-3e81-8aa573c8f18f@oracle.com> Message-ID: <1c537153-69fd-6ef4-bbac-ffbb5c0f6649@oracle.com> Hi Egor, While trying to write a JDI test to reproduce this issue (and having trouble getting it to fail), I learned a bit more about why your test case is failing. It's not the call to System.out.println() that is triggering the problem, it is the constant pool resolution for java.lang.System. JVMTI has some special logic to disable single stepping during class loading triggered by constant pool resolution, but the debug agent still considers single stepping to be enabled, so "threadControl_getInstructionStepMode(thread) == JVMTI_ENABLE". If you do a System.out.println() right before the one you are stepping over, then the problem goes away (for the 2nd println() that you are stepping over). Given that in order to reproduce the problem you both have to have MethodEntry events enabled and step over a line of code that results in constant pool resolution, I can see now why this problem has not been reported in a the past. It's probably very rare. There could be an argument that not only should JVMTI be disabling single stepping during class loading, but also MethodEntry/Exit events. Doing so would prevent the problem you are seeing. The following seems to fix the issue. Let me know if it works for you: diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c b/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c index 26c11ea6501..19eb801362d 100644 --- a/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c +++ b/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c @@ -334,9 +334,14 @@ deferEventReport(JNIEnv *env, jthread thread, ???????????????? jlocation end; ???????????????? error = methodLocation(method, &start, &end); ???????????????? if (error == JVMTI_ERROR_NONE) { -??????????????????? deferring = isBreakpointSet(clazz, method, start) || - threadControl_getInstructionStepMode(thread) -??????????????????????????????????? == JVMTI_ENABLE; +??????????????????? if (isBreakpointSet(clazz, method, start)) { +??????????????????????? deferring = JNI_TRUE; +??????????????????? } else { +??????????????????????? StepRequest* step = threadControl_getStepRequest(thread); +??????????????????????? if (step->pending && step->depth == JDWP_STEP_DEPTH(INTO)) { +??????????????????????????? deferring = JNI_TRUE; +??????????????????????? } +??????????????????? } ???????????????????? if (!deferring) { ???????????????????????? threadControl_saveCLEInfo(env, thread, ei, ?????????????????????????????????????????????????? clazz, method, start); Chris On 8/8/22 12:50 AM, Chris Plummer wrote: > I think the issue is that when you issue a "next", jvmti single > stepping is enabled. That means when the first MethodEntry event is > triggered, it is automatically deferred. See the following in > deferEventReport: > > ??????? case EI_METHOD_ENTRY: > ??????????????? error = methodLocation(method, &start, &end); > ??????????????? if (error == JVMTI_ERROR_NONE) { > ??????????????????? deferring = isBreakpointSet(clazz, method, start) || > threadControl_getInstructionStepMode(thread) > ??????????????????????????????????? == JVMTI_ENABLE; > > > When using (JDWP) STEP_OVER, JVMTI single stepping is only enabled > during the call to the method, which allows the debug agent to stop on > the first instruction of the called method. After that it disables > JVMTI single stepping (until there is a FramePop). When the above code > is executed for METHOD_ENTRY, JVMTI single stepping is enabled. When > JVMTI is returned to, it then sends a SINGLE_STEP event, but this is a > special one just used by the debug agent, and not sent on the the > debugger. So we never hit the code right below the above code that > handles colocating the SINGLE_STEP event. > > ??????? case EI_SINGLE_STEP: > ??????????? deferring = isBreakpointSet(clazz, method, location); > ??????????? if (deferring) { > ??????????????? threadControl_saveCLEInfo(env, thread, ei, > ????????????????????????????????????????? clazz, method, location); > ??????????? } > > Meanwhile the generated MethodEntry event sits in the thread's event > bag, and I guess gets added to when the next MethodEntry happens. This > goes on on a MethodExit event is generated, witch seems to push out > all pending events (there is actually no logic in the debug agent to > colocate MethodExit events, which seems odd). > > So bottom line is that the CLE code is wrong when JVMTI single > stepping is enabled for the sake of supporting a JDWP STEP_OVER. I > think instead of checking if JVMTI single stepping is enabled, it > should be checking if the current StepDepth is INTO, although I > suspect there might be other factors to consider that will make the > check more complicated. > > I'll look at this some more tomorrow. > > Chris > > On 8/7/22 11:50 PM, Chris Plummer wrote: >> Hi Egor, >> >> The reason only the last event prints location information is because >> there is special logic in jdb that assumes if the suspend type is not >> SUSPEND_NONE, then we will be stopping, and that will result in the >> location info being printed. >> >> ??????? if (me.request().suspendPolicy() != EventRequest.SUSPEND_NONE) { >> ??????????? // We are stopping; the name will be shown by the normal >> mechanism >> ??????????? MessageOutput.lnprint("Method entered:"); >> ??????? } else { >> ??????????? // We aren't stopping, show the name >> ??????????? MessageOutput.print("Method entered:"); >> ??????????? printLocationOfEvent(me); >> ??????? } >> >> The assumption here is wrong with co-located events, since there >> could be more than one. However, normally it shouldn't matter since >> all colocated events are suppose to be at the same location, and if >> one is stopping then they all are. Yet clearly we are seeing that >> they are not all at the same location. When I enable location tracing >> for the first part of the "if" block, I get: >> >> > Method entered: "thread=main", java.lang.ClassLoader.loadClass(), >> line=521 bci=0 >> Method entered: "thread=main", >> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(), line=180 >> bci=0 >> Method entered: "thread=main", java.lang.System.getSecurityManager(), >> line=497 bci=0 >> Method entered: "thread=main", >> java.lang.System.allowSecurityManager(), line=205 bci=0 >> Method exited: return value = false, "thread=main", >> java.lang.System.allowSecurityManager(), line=205 bci=12 >> >> I also printed out the EventSet, which confirms the same: >> >> event set, policy:2, count:5 = >> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >> in thread main, MethodEntryEvent at java.lang.System:497 in thread main, >> MethodEntryEvent at java.lang.System:205 in thread main, >> MethodExitEvent at java.lang.System:205 in thread main} >> >> The JDWP spec says: >> >> Several events may occur at a given time in the target VM. For >> example, there may be more than one breakpoint request for a given >> location or you might single step to the same location as a >> breakpoint request. These events are delivered together as a >> composite event. >> ... >> The events that are grouped in a composite event are restricted in >> the following ways: >> ... >> ? ? Only with other members of this group, at the same location and >> in the same thread: >> ??????? Breakpoint Event >> ??????? Step Event >> ??????? Method Entry Event >> ??????? Method Exit Event >> >> So there seems to be a debug agent bug that is grouping all the >> MethodEntry events until a MethodExit is hit. But I don't think this >> is new. I see the same thing in JDK11, but as Alan pointed out, there >> are fewer method calls. >> >> Chris >> >> On 8/6/22 2:18 AM, Egor Ushakov wrote: >>> Hi Chris, >>> >>> I was able to somewhat reproduce it with jdb: >>> compile any simple samle app like >>> >>> public class A { public static void main(String[] args) { >>> System.out.println("A"); // line 3 } } >>> now debug with jdb: >>> >>> ?% jdb A >>> Initializing jdb ... >>> > stop at A:3 >>> Deferring breakpoint A:3. >>> It will be set after the class is loaded. >>> > run >>> run A >>> Set uncaught java.lang.Throwable >>> Set deferred uncaught java.lang.Throwable >>> > >>> VM Started: Set deferred breakpoint A:3 >>> >>> Breakpoint hit: "thread=main", A.main(), line=3 bci=0 >>> >>> main[1] exclude none >>> main[1] trace methods >>> main[1] next >>> > >>> *Method entered: ** >>> **Method entered: ** >>> **Method entered: ** >>> **Method entered: * >>> Method exited: return value = false, "thread=main", >>> java.lang.System.allowSecurityManager(), line=198 bci=12 >>> >>> main[1] next >>> > >>> Method exited: return value = null, "thread=main", >>> java.lang.System.getSecurityManager(), line=493 bci=11 >>> >>> main[1] next >>> > >>> *Method entered: ** >>> **Method entered: ** >>> **Method entered: ** >>> **Method entered:* >>> Method exited: return value = , "thread=main", >>> java.lang.Object.(), line=44 bci=0 >>> >>> main[1] next >>> > >>> *Method entered: ** >>> **Method entered: ** >>> **Method entered: ** >>> **Method entered: * >>> Method exited: return value = true, "thread=main", >>> java.lang.String.isLatin1(), line=4,546 bci=18 >>> >>> Unfortunately jdb does not show method description for the events >>> with suspend policy thread (except for the last one), but you can >>> see that there are 5 events in one set here. >>> >>> Hope it helps, >>> Egor >>> >>> On 05.08.2022 22:02, Chris Plummer wrote: >>>> >>>> Hi Egor, >>>> >>>> >>>> That is odd, and clearly wrong. It means that MethodEntryEvents are >>>> being delivered when no longer even executing in the method. And >>>> you are using the EVENT_THREAD suspend policy, so there should be a >>>> suspend for each event. Offhand I can't think of any changes that >>>> would have caused this. I also don't see how our testing would >>>> passed with this behavior. I'm suspecting a faulty interaction with >>>> the debug agent and IDEA (possibly the IDEA version of JDI). >>>> >>>> Can you see where the thread is actually suspended at when you get >>>> the event set? >>>> >>>> Does this happen with 17 also? It would be nice to know what >>>> version introduced this problem. >>>> >>>> Can you create a JDI test case for this? >>>> >>>> >>>> > Without the active step request it works in jdk 18 as in jdk 11: >>>> >>>> >>>> I'm not sure what you mean by "active step". Do you mean single >>>> stepping is enabled? The JDWP spec does allow BreakPoint, >>>> SingleStep, MethodEntry, and MethodExit events to be combined into >>>> the same composite event (which should translate to the same JDI >>>> event set) if they occur at the same location and in the same >>>> thread. So I can see enabling single stepping having an impact on >>>> the behavior you are seeing. >>>> >>>> >>>> Chris >>>> >>>> On 8/5/22 9:59 AM, Egor Ushakov wrote: >>>>> Hi, >>>>> >>>>> we're experiencing strange grouping of method entry/exit events, >>>>> is this a bug or a feature? >>>>> We have one method entry request active with suspend policy 1 >>>>> (suspend thread). >>>>> important: we also have one active step request (step over) >>>>> >>>>> In jdk 11 we have one composite event for each event, which is >>>>> what's expected: >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 >>>>> in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.System:375 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.Object:50 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.String:1502 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.String:3266 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} >>>>> ... >>>>> >>>>> In jdk 18 they are grouped now! >>>>> event set, policy:1, count:17 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >>>>> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>>> in thread main, MethodEntryEvent at java.lang.System:490 in thread >>>>> main, MethodEntryEvent at java.lang.System:198 in thread main, >>>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>>> thread main, >>>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>>> thread main, MethodEntryEvent at java.lang.ClassLoader:664 in thread >>>>> main, MethodEntryEvent at java.lang.Object:44 in thread main, >>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>> thread main, >>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>> thread main, MethodEntryEvent at java.lang.String:2336 in thread >>>>> main, MethodEntryEvent at java.lang.String:4546 in thread main, >>>>> MethodEntryEvent at java.lang.StringLatin1:192 in thread main, >>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in >>>>> thread main, >>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in >>>>> thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in >>>>> thread main, >>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, >>>>> long)+-1 in thread main} >>>>> event set, policy:1, count:4 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 >>>>> in thread main, MethodEntryEvent at java.lang.Object:44 in thread >>>>> main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 >>>>> in thread main, >>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, >>>>> long, java.lang.Object, java.lang.Object)+-1 in thread main} >>>>> event set, policy:1, count:2 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in >>>>> thread main, >>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, >>>>> long, long, long)+-1 in thread main} >>>>> >>>>> Which is really strange and breaks some login in IDEA debugger. >>>>> >>>>> Without the active step request it works in jdk 18 as in jdk 11: >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>>> in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.System:490 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.System:198 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.Object:44 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>> thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.String:2336 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.String:4546 in thread main} >>>>> event set, policy:1, count:1 = >>>>> {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} >>>>> >>>>> Could anyone have a look please. >>>>> Thanks, >>>>> Egor >>> From chris.plummer at oracle.com Wed Aug 10 04:25:18 2022 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 9 Aug 2022 21:25:18 -0700 Subject: [External] : Re: Grouped method entry events In-Reply-To: <1c537153-69fd-6ef4-bbac-ffbb5c0f6649@oracle.com> References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> <8cdcf5f4-85ab-5b13-cb6f-249f61b62ba8@oracle.com> <7ffbc220-94ee-e8ab-3e81-8aa573c8f18f@oracle.com> <1c537153-69fd-6ef4-bbac-ffbb5c0f6649@oracle.com> Message-ID: <148f93bf-6054-c7d8-b08e-1c4519a6eef5@oracle.com> Hi Egor, Although the patch below does seem to fix? your specific issue, and I haven't seen it cause any new test failures, I don't think it's really the right fix. Rather than fixing the underlying issue, I'd say it just avoids it in your specific case, but likely the issue is still there when, for example, a STEP_INTO is done instead of a STEP_OVER. STEP_OUT might also be problematic. I'll need to think about this some more. Chris On 8/9/22 8:25 PM, Chris Plummer wrote: > Hi Egor, > > While trying to write a JDI test to reproduce this issue (and having > trouble getting it to fail), I learned a bit more about why your test > case is failing. It's not the call to System.out.println() that is > triggering the problem, it is the constant pool resolution for > java.lang.System. JVMTI has some special logic to disable single > stepping during class loading triggered by constant pool resolution, > but the debug agent still considers single stepping to be enabled, so > "threadControl_getInstructionStepMode(thread) == JVMTI_ENABLE". If you > do a System.out.println() right before the one you are stepping over, > then the problem goes away (for the 2nd println() that you are > stepping over). Given that in order to reproduce the problem you both > have to have MethodEntry events enabled and step over a line of code > that results in constant pool resolution, I can see now why this > problem has not been reported in a the past. It's probably very rare. > > There could be an argument that not only should JVMTI be disabling > single stepping during class loading, but also MethodEntry/Exit > events. Doing so would prevent the problem you are seeing. > > The following seems to fix the issue. Let me know if it works for you: > > diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c > b/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c > index 26c11ea6501..19eb801362d 100644 > --- a/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c > +++ b/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c > @@ -334,9 +334,14 @@ deferEventReport(JNIEnv *env, jthread thread, > ???????????????? jlocation end; > ???????????????? error = methodLocation(method, &start, &end); > ???????????????? if (error == JVMTI_ERROR_NONE) { > -??????????????????? deferring = isBreakpointSet(clazz, method, start) || > - threadControl_getInstructionStepMode(thread) > -??????????????????????????????????? == JVMTI_ENABLE; > +??????????????????? if (isBreakpointSet(clazz, method, start)) { > +??????????????????????? deferring = JNI_TRUE; > +??????????????????? } else { > +??????????????????????? StepRequest* step = > threadControl_getStepRequest(thread); > +??????????????????????? if (step->pending && step->depth == > JDWP_STEP_DEPTH(INTO)) { > +??????????????????????????? deferring = JNI_TRUE; > +??????????????????????? } > +??????????????????? } > ???????????????????? if (!deferring) { > ???????????????????????? threadControl_saveCLEInfo(env, thread, ei, > ?????????????????????????????????????????????????? clazz, method, start); > > Chris > > On 8/8/22 12:50 AM, Chris Plummer wrote: >> I think the issue is that when you issue a "next", jvmti single >> stepping is enabled. That means when the first MethodEntry event is >> triggered, it is automatically deferred. See the following in >> deferEventReport: >> >> ??????? case EI_METHOD_ENTRY: >> ??????????????? error = methodLocation(method, &start, &end); >> ??????????????? if (error == JVMTI_ERROR_NONE) { >> ??????????????????? deferring = isBreakpointSet(clazz, method, start) || >> threadControl_getInstructionStepMode(thread) >> ??????????????????????????????????? == JVMTI_ENABLE; >> >> >> When using (JDWP) STEP_OVER, JVMTI single stepping is only enabled >> during the call to the method, which allows the debug agent to stop >> on the first instruction of the called method. After that it disables >> JVMTI single stepping (until there is a FramePop). When the above >> code is executed for METHOD_ENTRY, JVMTI single stepping is enabled. >> When JVMTI is returned to, it then sends a SINGLE_STEP event, but >> this is a special one just used by the debug agent, and not sent on >> the the debugger. So we never hit the code right below the above code >> that handles colocating the SINGLE_STEP event. >> >> ??????? case EI_SINGLE_STEP: >> ??????????? deferring = isBreakpointSet(clazz, method, location); >> ??????????? if (deferring) { >> ??????????????? threadControl_saveCLEInfo(env, thread, ei, >> ????????????????????????????????????????? clazz, method, location); >> ??????????? } >> >> Meanwhile the generated MethodEntry event sits in the thread's event >> bag, and I guess gets added to when the next MethodEntry happens. >> This goes on on a MethodExit event is generated, witch seems to push >> out all pending events (there is actually no logic in the debug agent >> to colocate MethodExit events, which seems odd). >> >> So bottom line is that the CLE code is wrong when JVMTI single >> stepping is enabled for the sake of supporting a JDWP STEP_OVER. I >> think instead of checking if JVMTI single stepping is enabled, it >> should be checking if the current StepDepth is INTO, although I >> suspect there might be other factors to consider that will make the >> check more complicated. >> >> I'll look at this some more tomorrow. >> >> Chris >> >> On 8/7/22 11:50 PM, Chris Plummer wrote: >>> Hi Egor, >>> >>> The reason only the last event prints location information is >>> because there is special logic in jdb that assumes if the suspend >>> type is not SUSPEND_NONE, then we will be stopping, and that will >>> result in the location info being printed. >>> >>> ??????? if (me.request().suspendPolicy() != >>> EventRequest.SUSPEND_NONE) { >>> ??????????? // We are stopping; the name will be shown by the normal >>> mechanism >>> ??????????? MessageOutput.lnprint("Method entered:"); >>> ??????? } else { >>> ??????????? // We aren't stopping, show the name >>> ??????????? MessageOutput.print("Method entered:"); >>> ??????????? printLocationOfEvent(me); >>> ??????? } >>> >>> The assumption here is wrong with co-located events, since there >>> could be more than one. However, normally it shouldn't matter since >>> all colocated events are suppose to be at the same location, and if >>> one is stopping then they all are. Yet clearly we are seeing that >>> they are not all at the same location. When I enable location >>> tracing for the first part of the "if" block, I get: >>> >>> > Method entered: "thread=main", java.lang.ClassLoader.loadClass(), >>> line=521 bci=0 >>> Method entered: "thread=main", >>> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(), >>> line=180 bci=0 >>> Method entered: "thread=main", >>> java.lang.System.getSecurityManager(), line=497 bci=0 >>> Method entered: "thread=main", >>> java.lang.System.allowSecurityManager(), line=205 bci=0 >>> Method exited: return value = false, "thread=main", >>> java.lang.System.allowSecurityManager(), line=205 bci=12 >>> >>> I also printed out the EventSet, which confirms the same: >>> >>> event set, policy:2, count:5 = >>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >>> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>> in thread main, MethodEntryEvent at java.lang.System:497 in thread >>> main, MethodEntryEvent at java.lang.System:205 in thread main, >>> MethodExitEvent at java.lang.System:205 in thread main} >>> >>> The JDWP spec says: >>> >>> Several events may occur at a given time in the target VM. For >>> example, there may be more than one breakpoint request for a given >>> location or you might single step to the same location as a >>> breakpoint request. These events are delivered together as a >>> composite event. >>> ... >>> The events that are grouped in a composite event are restricted in >>> the following ways: >>> ... >>> ? ? Only with other members of this group, at the same location and >>> in the same thread: >>> ??????? Breakpoint Event >>> ??????? Step Event >>> ??????? Method Entry Event >>> ??????? Method Exit Event >>> >>> So there seems to be a debug agent bug that is grouping all the >>> MethodEntry events until a MethodExit is hit. But I don't think this >>> is new. I see the same thing in JDK11, but as Alan pointed out, >>> there are fewer method calls. >>> >>> Chris >>> >>> On 8/6/22 2:18 AM, Egor Ushakov wrote: >>>> Hi Chris, >>>> >>>> I was able to somewhat reproduce it with jdb: >>>> compile any simple samle app like >>>> >>>> public class A { public static void main(String[] args) { >>>> System.out.println("A"); // line 3 } } >>>> now debug with jdb: >>>> >>>> ?% jdb A >>>> Initializing jdb ... >>>> > stop at A:3 >>>> Deferring breakpoint A:3. >>>> It will be set after the class is loaded. >>>> > run >>>> run A >>>> Set uncaught java.lang.Throwable >>>> Set deferred uncaught java.lang.Throwable >>>> > >>>> VM Started: Set deferred breakpoint A:3 >>>> >>>> Breakpoint hit: "thread=main", A.main(), line=3 bci=0 >>>> >>>> main[1] exclude none >>>> main[1] trace methods >>>> main[1] next >>>> > >>>> *Method entered: ** >>>> **Method entered: ** >>>> **Method entered: ** >>>> **Method entered: * >>>> Method exited: return value = false, "thread=main", >>>> java.lang.System.allowSecurityManager(), line=198 bci=12 >>>> >>>> main[1] next >>>> > >>>> Method exited: return value = null, "thread=main", >>>> java.lang.System.getSecurityManager(), line=493 bci=11 >>>> >>>> main[1] next >>>> > >>>> *Method entered: ** >>>> **Method entered: ** >>>> **Method entered: ** >>>> **Method entered:* >>>> Method exited: return value = , "thread=main", >>>> java.lang.Object.(), line=44 bci=0 >>>> >>>> main[1] next >>>> > >>>> *Method entered: ** >>>> **Method entered: ** >>>> **Method entered: ** >>>> **Method entered: * >>>> Method exited: return value = true, "thread=main", >>>> java.lang.String.isLatin1(), line=4,546 bci=18 >>>> >>>> Unfortunately jdb does not show method description for the events >>>> with suspend policy thread (except for the last one), but you can >>>> see that there are 5 events in one set here. >>>> >>>> Hope it helps, >>>> Egor >>>> >>>> On 05.08.2022 22:02, Chris Plummer wrote: >>>>> >>>>> Hi Egor, >>>>> >>>>> >>>>> That is odd, and clearly wrong. It means that MethodEntryEvents >>>>> are being delivered when no longer even executing in the method. >>>>> And you are using the EVENT_THREAD suspend policy, so there should >>>>> be a suspend for each event. Offhand I can't think of any changes >>>>> that would have caused this. I also don't see how our testing >>>>> would passed with this behavior. I'm suspecting a faulty >>>>> interaction with the debug agent and IDEA (possibly the IDEA >>>>> version of JDI). >>>>> >>>>> Can you see where the thread is actually suspended at when you get >>>>> the event set? >>>>> >>>>> Does this happen with 17 also? It would be nice to know what >>>>> version introduced this problem. >>>>> >>>>> Can you create a JDI test case for this? >>>>> >>>>> >>>>> > Without the active step request it works in jdk 18 as in jdk 11: >>>>> >>>>> >>>>> I'm not sure what you mean by "active step". Do you mean single >>>>> stepping is enabled? The JDWP spec does allow BreakPoint, >>>>> SingleStep, MethodEntry, and MethodExit events to be combined into >>>>> the same composite event (which should translate to the same JDI >>>>> event set) if they occur at the same location and in the same >>>>> thread. So I can see enabling single stepping having an impact on >>>>> the behavior you are seeing. >>>>> >>>>> >>>>> Chris >>>>> >>>>> On 8/5/22 9:59 AM, Egor Ushakov wrote: >>>>>> Hi, >>>>>> >>>>>> we're experiencing strange grouping of method entry/exit events, >>>>>> is this a bug or a feature? >>>>>> We have one method entry request active with suspend policy 1 >>>>>> (suspend thread). >>>>>> important: we also have one active step request (step over) >>>>>> >>>>>> In jdk 11 we have one composite event for each event, which is >>>>>> what's expected: >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 >>>>>> in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.System:375 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in >>>>>> thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in >>>>>> thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.Object:50 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>>> thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>>> thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.String:1502 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.String:3266 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} >>>>>> ... >>>>>> >>>>>> In jdk 18 they are grouped now! >>>>>> event set, policy:1, count:17 = >>>>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >>>>>> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>>>> in thread main, MethodEntryEvent at java.lang.System:490 in thread >>>>>> main, MethodEntryEvent at java.lang.System:198 in thread main, >>>>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>>>> thread main, >>>>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>>>> thread main, MethodEntryEvent at java.lang.ClassLoader:664 in thread >>>>>> main, MethodEntryEvent at java.lang.Object:44 in thread main, >>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>>> thread main, >>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>>> thread main, MethodEntryEvent at java.lang.String:2336 in thread >>>>>> main, MethodEntryEvent at java.lang.String:4546 in thread main, >>>>>> MethodEntryEvent at java.lang.StringLatin1:192 in thread main, >>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in >>>>>> thread main, >>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in >>>>>> thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in >>>>>> thread main, >>>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, >>>>>> long)+-1 in thread main} >>>>>> event set, policy:1, count:4 = >>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 >>>>>> in thread main, MethodEntryEvent at java.lang.Object:44 in thread >>>>>> main, MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 >>>>>> in thread main, >>>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, >>>>>> long, java.lang.Object, java.lang.Object)+-1 in thread main} >>>>>> event set, policy:1, count:2 = >>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in >>>>>> thread main, >>>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, >>>>>> long, long, long)+-1 in thread main} >>>>>> >>>>>> Which is really strange and breaks some login in IDEA debugger. >>>>>> >>>>>> Without the active step request it works in jdk 18 as in jdk 11: >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>>>> in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.System:490 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.System:198 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>>>> thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>>>> thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.Object:44 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>>> thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>>> thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.String:2336 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.String:4546 in thread main} >>>>>> event set, policy:1, count:1 = >>>>>> {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} >>>>>> >>>>>> Could anyone have a look please. >>>>>> Thanks, >>>>>> Egor >>>> From duke at openjdk.org Wed Aug 10 15:23:46 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Aug 2022 15:23:46 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v3] In-Reply-To: References: Message-ID: <1duR3VoLYDa4MDvYCuEOmKf1IgrI_XAWIFeAoaxfYKE=.7aff1a6d-60c5-4777-8ddb-e21368a31cf8@github.com> > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: - Initial draft new terminology - Make _context_active atomic - Missed merge changes - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Merge branch 'JDK-8291718' into JDK-8291237 - Remove indentation - Fix for shenandoah - Merge remote-tracking branch 'upstream/master' into JDK-8291718 - Extend CodeCache::UnloadingScope to include klass unloading - Remove double counting _perf_total_buckets_deallocated_count - ... and 10 more: https://git.openjdk.org/jdk/compare/f4067fb3...9f6f981d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/5d26ab8d..9f6f981d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=01-02 Stats: 15374 lines in 744 files changed: 8974 ins; 4345 del; 2055 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From egor.ushakov at jetbrains.com Wed Aug 10 15:45:07 2022 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Wed, 10 Aug 2022 17:45:07 +0200 Subject: [External] : Re: Grouped method entry events In-Reply-To: <148f93bf-6054-c7d8-b08e-1c4519a6eef5@oracle.com> References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com> <8cdcf5f4-85ab-5b13-cb6f-249f61b62ba8@oracle.com> <7ffbc220-94ee-e8ab-3e81-8aa573c8f18f@oracle.com> <1c537153-69fd-6ef4-bbac-ffbb5c0f6649@oracle.com> <148f93bf-6054-c7d8-b08e-1c4519a6eef5@oracle.com> Message-ID: <4ee1da6e-983c-9954-b7da-74fb67126962@jetbrains.com> Hi Chris! some context from our side: this combination is used for "watch return value" feature which shows the last returned value after the step (over). At first this was implemented with one method exit request, but then it appeared that a combination of method entry+exit works much faster - we track method entry and then filter method exits by entered class+method only, then watch all again. A lot less events - this works much faster. For now we have implemented a workaround on our side, but it still worth fixing this I guess. Thanks for looking into this. Egor On 10.08.2022 6:25, Chris Plummer wrote: > Hi Egor, > > Although the patch below does seem to fix? your specific issue, and I > haven't seen it cause any new test failures, I don't think it's really > the right fix. Rather than fixing the underlying issue, I'd say it > just avoids it in your specific case, but likely the issue is still > there when, for example, a STEP_INTO is done instead of a STEP_OVER. > STEP_OUT might also be problematic. I'll need to think about this some > more. > > Chris > > On 8/9/22 8:25 PM, Chris Plummer wrote: >> Hi Egor, >> >> While trying to write a JDI test to reproduce this issue (and having >> trouble getting it to fail), I learned a bit more about why your test >> case is failing. It's not the call to System.out.println() that is >> triggering the problem, it is the constant pool resolution for >> java.lang.System. JVMTI has some special logic to disable single >> stepping during class loading triggered by constant pool resolution, >> but the debug agent still considers single stepping to be enabled, so >> "threadControl_getInstructionStepMode(thread) == JVMTI_ENABLE". If >> you do a System.out.println() right before the one you are stepping >> over, then the problem goes away (for the 2nd println() that you are >> stepping over). Given that in order to reproduce the problem you both >> have to have MethodEntry events enabled and step over a line of code >> that results in constant pool resolution, I can see now why this >> problem has not been reported in a the past. It's probably very rare. >> >> There could be an argument that not only should JVMTI be disabling >> single stepping during class loading, but also MethodEntry/Exit >> events. Doing so would prevent the problem you are seeing. >> >> The following seems to fix the issue. Let me know if it works for you: >> >> diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >> b/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >> index 26c11ea6501..19eb801362d 100644 >> --- a/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >> @@ -334,9 +334,14 @@ deferEventReport(JNIEnv *env, jthread thread, >> ???????????????? jlocation end; >> ???????????????? error = methodLocation(method, &start, &end); >> ???????????????? if (error == JVMTI_ERROR_NONE) { >> -??????????????????? deferring = isBreakpointSet(clazz, method, >> start) || >> - threadControl_getInstructionStepMode(thread) >> -??????????????????????????????????? == JVMTI_ENABLE; >> +??????????????????? if (isBreakpointSet(clazz, method, start)) { >> +??????????????????????? deferring = JNI_TRUE; >> +??????????????????? } else { >> +??????????????????????? StepRequest* step = >> threadControl_getStepRequest(thread); >> +??????????????????????? if (step->pending && step->depth == >> JDWP_STEP_DEPTH(INTO)) { >> +??????????????????????????? deferring = JNI_TRUE; >> +??????????????????????? } >> +??????????????????? } >> ???????????????????? if (!deferring) { >> ???????????????????????? threadControl_saveCLEInfo(env, thread, ei, >> ?????????????????????????????????????????????????? clazz, method, >> start); >> >> Chris >> >> On 8/8/22 12:50 AM, Chris Plummer wrote: >>> I think the issue is that when you issue a "next", jvmti single >>> stepping is enabled. That means when the first MethodEntry event is >>> triggered, it is automatically deferred. See the following in >>> deferEventReport: >>> >>> ??????? case EI_METHOD_ENTRY: >>> ??????????????? error = methodLocation(method, &start, &end); >>> ??????????????? if (error == JVMTI_ERROR_NONE) { >>> ??????????????????? deferring = isBreakpointSet(clazz, method, >>> start) || >>> threadControl_getInstructionStepMode(thread) >>> ??????????????????????????????????? == JVMTI_ENABLE; >>> >>> >>> When using (JDWP) STEP_OVER, JVMTI single stepping is only enabled >>> during the call to the method, which allows the debug agent to stop >>> on the first instruction of the called method. After that it >>> disables JVMTI single stepping (until there is a FramePop). When the >>> above code is executed for METHOD_ENTRY, JVMTI single stepping is >>> enabled. When JVMTI is returned to, it then sends a SINGLE_STEP >>> event, but this is a special one just used by the debug agent, and >>> not sent on the the debugger. So we never hit the code right below >>> the above code that handles colocating the SINGLE_STEP event. >>> >>> ??????? case EI_SINGLE_STEP: >>> ??????????? deferring = isBreakpointSet(clazz, method, location); >>> ??????????? if (deferring) { >>> ??????????????? threadControl_saveCLEInfo(env, thread, ei, >>> ????????????????????????????????????????? clazz, method, location); >>> ??????????? } >>> >>> Meanwhile the generated MethodEntry event sits in the thread's event >>> bag, and I guess gets added to when the next MethodEntry happens. >>> This goes on on a MethodExit event is generated, witch seems to push >>> out all pending events (there is actually no logic in the debug >>> agent to colocate MethodExit events, which seems odd). >>> >>> So bottom line is that the CLE code is wrong when JVMTI single >>> stepping is enabled for the sake of supporting a JDWP STEP_OVER. I >>> think instead of checking if JVMTI single stepping is enabled, it >>> should be checking if the current StepDepth is INTO, although I >>> suspect there might be other factors to consider that will make the >>> check more complicated. >>> >>> I'll look at this some more tomorrow. >>> >>> Chris >>> >>> On 8/7/22 11:50 PM, Chris Plummer wrote: >>>> Hi Egor, >>>> >>>> The reason only the last event prints location information is >>>> because there is special logic in jdb that assumes if the suspend >>>> type is not SUSPEND_NONE, then we will be stopping, and that will >>>> result in the location info being printed. >>>> >>>> ??????? if (me.request().suspendPolicy() != >>>> EventRequest.SUSPEND_NONE) { >>>> ??????????? // We are stopping; the name will be shown by the >>>> normal mechanism >>>> ??????????? MessageOutput.lnprint("Method entered:"); >>>> ??????? } else { >>>> ??????????? // We aren't stopping, show the name >>>> ??????????? MessageOutput.print("Method entered:"); >>>> ??????????? printLocationOfEvent(me); >>>> ??????? } >>>> >>>> The assumption here is wrong with co-located events, since there >>>> could be more than one. However, normally it shouldn't matter since >>>> all colocated events are suppose to be at the same location, and if >>>> one is stopping then they all are. Yet clearly we are seeing that >>>> they are not all at the same location. When I enable location >>>> tracing for the first part of the "if" block, I get: >>>> >>>> > Method entered: "thread=main", java.lang.ClassLoader.loadClass(), >>>> line=521 bci=0 >>>> Method entered: "thread=main", >>>> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(), >>>> line=180 bci=0 >>>> Method entered: "thread=main", >>>> java.lang.System.getSecurityManager(), line=497 bci=0 >>>> Method entered: "thread=main", >>>> java.lang.System.allowSecurityManager(), line=205 bci=0 >>>> Method exited: return value = false, "thread=main", >>>> java.lang.System.allowSecurityManager(), line=205 bci=12 >>>> >>>> I also printed out the EventSet, which confirms the same: >>>> >>>> event set, policy:2, count:5 = >>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >>>> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>> in thread main, MethodEntryEvent at java.lang.System:497 in thread >>>> main, MethodEntryEvent at java.lang.System:205 in thread main, >>>> MethodExitEvent at java.lang.System:205 in thread main} >>>> >>>> The JDWP spec says: >>>> >>>> Several events may occur at a given time in the target VM. For >>>> example, there may be more than one breakpoint request for a given >>>> location or you might single step to the same location as a >>>> breakpoint request. These events are delivered together as a >>>> composite event. >>>> ... >>>> The events that are grouped in a composite event are restricted in >>>> the following ways: >>>> ... >>>> ? ? Only with other members of this group, at the same location and >>>> in the same thread: >>>> ??????? Breakpoint Event >>>> ??????? Step Event >>>> ??????? Method Entry Event >>>> ??????? Method Exit Event >>>> >>>> So there seems to be a debug agent bug that is grouping all the >>>> MethodEntry events until a MethodExit is hit. But I don't think >>>> this is new. I see the same thing in JDK11, but as Alan pointed >>>> out, there are fewer method calls. >>>> >>>> Chris >>>> >>>> On 8/6/22 2:18 AM, Egor Ushakov wrote: >>>>> Hi Chris, >>>>> >>>>> I was able to somewhat reproduce it with jdb: >>>>> compile any simple samle app like >>>>> >>>>> public class A { public static void main(String[] args) { >>>>> System.out.println("A"); // line 3 } } >>>>> now debug with jdb: >>>>> >>>>> ?% jdb A >>>>> Initializing jdb ... >>>>> > stop at A:3 >>>>> Deferring breakpoint A:3. >>>>> It will be set after the class is loaded. >>>>> > run >>>>> run A >>>>> Set uncaught java.lang.Throwable >>>>> Set deferred uncaught java.lang.Throwable >>>>> > >>>>> VM Started: Set deferred breakpoint A:3 >>>>> >>>>> Breakpoint hit: "thread=main", A.main(), line=3 bci=0 >>>>> >>>>> main[1] exclude none >>>>> main[1] trace methods >>>>> main[1] next >>>>> > >>>>> *Method entered: ** >>>>> **Method entered: ** >>>>> **Method entered: ** >>>>> **Method entered: * >>>>> Method exited: return value = false, "thread=main", >>>>> java.lang.System.allowSecurityManager(), line=198 bci=12 >>>>> >>>>> main[1] next >>>>> > >>>>> Method exited: return value = null, "thread=main", >>>>> java.lang.System.getSecurityManager(), line=493 bci=11 >>>>> >>>>> main[1] next >>>>> > >>>>> *Method entered: ** >>>>> **Method entered: ** >>>>> **Method entered: ** >>>>> **Method entered:* >>>>> Method exited: return value = , "thread=main", >>>>> java.lang.Object.(), line=44 bci=0 >>>>> >>>>> main[1] next >>>>> > >>>>> *Method entered: ** >>>>> **Method entered: ** >>>>> **Method entered: ** >>>>> **Method entered: * >>>>> Method exited: return value = true, "thread=main", >>>>> java.lang.String.isLatin1(), line=4,546 bci=18 >>>>> >>>>> Unfortunately jdb does not show method description for the events >>>>> with suspend policy thread (except for the last one), but you can >>>>> see that there are 5 events in one set here. >>>>> >>>>> Hope it helps, >>>>> Egor >>>>> >>>>> On 05.08.2022 22:02, Chris Plummer wrote: >>>>>> >>>>>> Hi Egor, >>>>>> >>>>>> >>>>>> That is odd, and clearly wrong. It means that MethodEntryEvents >>>>>> are being delivered when no longer even executing in the method. >>>>>> And you are using the EVENT_THREAD suspend policy, so there >>>>>> should be a suspend for each event. Offhand I can't think of any >>>>>> changes that would have caused this. I also don't see how our >>>>>> testing would passed with this behavior. I'm suspecting a faulty >>>>>> interaction with the debug agent and IDEA (possibly the IDEA >>>>>> version of JDI). >>>>>> >>>>>> Can you see where the thread is actually suspended at when you >>>>>> get the event set? >>>>>> >>>>>> Does this happen with 17 also? It would be nice to know what >>>>>> version introduced this problem. >>>>>> >>>>>> Can you create a JDI test case for this? >>>>>> >>>>>> >>>>>> > Without the active step request it works in jdk 18 as in jdk 11: >>>>>> >>>>>> >>>>>> I'm not sure what you mean by "active step". Do you mean single >>>>>> stepping is enabled? The JDWP spec does allow BreakPoint, >>>>>> SingleStep, MethodEntry, and MethodExit events to be combined >>>>>> into the same composite event (which should translate to the same >>>>>> JDI event set) if they occur at the same location and in the same >>>>>> thread. So I can see enabling single stepping having an impact on >>>>>> the behavior you are seeing. >>>>>> >>>>>> >>>>>> Chris >>>>>> >>>>>> On 8/5/22 9:59 AM, Egor Ushakov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> we're experiencing strange grouping of method entry/exit events, >>>>>>> is this a bug or a feature? >>>>>>> We have one method entry request active with suspend policy 1 >>>>>>> (suspend thread). >>>>>>> important: we also have one active step request (step over) >>>>>>> >>>>>>> In jdk 11 we have one composite event for each event, which is >>>>>>> what's expected: >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.ClassLoader:522 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:170 >>>>>>> in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.System:375 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:579 in >>>>>>> thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:591 in >>>>>>> thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.ClassLoader:665 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.Object:50 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>>>> thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>>>> thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.String:1502 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.String:3266 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.StringLatin1:194 in thread main} >>>>>>> ... >>>>>>> >>>>>>> In jdk 18 they are grouped now! >>>>>>> event set, policy:1, count:17 = >>>>>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, >>>>>>> MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>>>>> in thread main, MethodEntryEvent at java.lang.System:490 in thread >>>>>>> main, MethodEntryEvent at java.lang.System:198 in thread main, >>>>>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>>>>> thread main, >>>>>>> MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>>>>> thread main, MethodEntryEvent at java.lang.ClassLoader:664 in >>>>>>> thread main, MethodEntryEvent at java.lang.Object:44 in thread >>>>>>> main, >>>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>>>> thread main, >>>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>>>> thread main, MethodEntryEvent at java.lang.String:2336 in thread >>>>>>> main, MethodEntryEvent at java.lang.String:4546 in thread main, >>>>>>> MethodEntryEvent at java.lang.StringLatin1:192 in thread main, >>>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:697 in >>>>>>> thread main, >>>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:760 in >>>>>>> thread main, MethodEntryEvent at jdk.internal.misc.Unsafe:2153 in >>>>>>> thread main, >>>>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.getReferenceVolatile(java.lang.Object, >>>>>>> long)+-1 in thread main} >>>>>>> event set, policy:1, count:4 = >>>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap$Node:631 >>>>>>> in thread main, MethodEntryEvent at java.lang.Object:44 in thread >>>>>>> main, >>>>>>> MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:765 in >>>>>>> thread main, >>>>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, >>>>>>> long, java.lang.Object, java.lang.Object)+-1 in thread main} >>>>>>> event set, policy:1, count:2 = >>>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:2326 in >>>>>>> thread main, >>>>>>> MethodEntryEvent at jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, >>>>>>> long, long, long)+-1 in thread main} >>>>>>> >>>>>>> Which is really strange and breaks some login in IDEA debugger. >>>>>>> >>>>>>> Without the active step request it works in jdk 18 as in jdk 11: >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.ClassLoader:521 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 >>>>>>> in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.System:490 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.System:198 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:639 in >>>>>>> thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at jdk.internal.loader.BuiltinClassLoader:651 in >>>>>>> thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.ClassLoader:664 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.Object:44 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1541 in >>>>>>> thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.util.concurrent.ConcurrentHashMap:1011 in >>>>>>> thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.String:2336 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.String:4546 in thread main} >>>>>>> event set, policy:1, count:1 = >>>>>>> {MethodEntryEvent at java.lang.StringLatin1:192 in thread main} >>>>>>> >>>>>>> Could anyone have a look please. >>>>>>> Thanks, >>>>>>> Egor >>>>> From duke at openjdk.org Wed Aug 10 15:52:44 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Aug 2022 15:52:44 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v3] In-Reply-To: <1duR3VoLYDa4MDvYCuEOmKf1IgrI_XAWIFeAoaxfYKE=.7aff1a6d-60c5-4777-8ddb-e21368a31cf8@github.com> References: <1duR3VoLYDa4MDvYCuEOmKf1IgrI_XAWIFeAoaxfYKE=.7aff1a6d-60c5-4777-8ddb-e21368a31cf8@github.com> Message-ID: <1Ljfdir6k-NRJMOGOckyr92l-l7UULx-aBsX5GeDHDY=.31cb5b2e-174d-4daa-9d92-1da25cef36c1@github.com> On Wed, 10 Aug 2022 15:23:46 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: > > - Initial draft new terminology > - Make _context_active atomic > - Missed merge changes > - Merge remote-tracking branch 'upstream/master' into JDK-8291237 > - Merge branch 'JDK-8291718' into JDK-8291237 > - Remove indentation > - Fix for shenandoah > - Merge remote-tracking branch 'upstream/master' into JDK-8291718 > - Extend CodeCache::UnloadingScope to include klass unloading > - Remove double counting _perf_total_buckets_deallocated_count > - ... and 10 more: https://git.openjdk.org/jdk/compare/443af4e1...9f6f981d Merged [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) into this as this change is dependent on that patch. Backed out the linked list enhancement. This is still a draft, and still need some work on the semantics of some enum statuses, and naming. Changed the terminology for deoptimization to stop using mark. Because the steps for deoptimization is always the following: 1. Create a list of nmethods to deoptimize (enqueueing) 2. Process the list 2.1. Make `nmethod` non entrant 2.2. (With continuations) patch `nmethod` `NativePostCallNop` instructions 3. Walk all frames and patch return pcs The mark_for was renamed enqueue, this makes it easier to talk about deoptimization in a context where marking is already a thing (e.g. GCs) and is more correct with regards to what the codes actually does. All remaining changes are with regards to `deoptimize_done` and that it does not really mean what it says. The comment in `update_recompile_counts()` describes the issue. The most correct thing would be to rename it to something like `deoptimize_post_call_installed` or `deoptimize_post_call_patched` and just leave it like that. No code currently cares if the deoptimization logic is completed (with regards to stack frame walking), only if an `nmethod` has enqueued deoptimization or not, and if `NativePostCallNop` instructions has been installed for loom. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From duke at openjdk.org Wed Aug 10 18:26:36 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 10 Aug 2022 18:26:36 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang wrote: > This task converts 5 shell tests below to java version. > test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh > test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh > test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh > test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > test/java/lang/management/MemoryMXBean/PendingAllGC.sh It should be okay to remove the GC settings for these tests. I am just wondering how it would impact the test coverage in ATR. Let me bring this up to the SQE team. ------------- PR: https://git.openjdk.org/jdk/pull/9813 From lmesnik at openjdk.org Wed Aug 10 18:29:36 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 10 Aug 2022 18:29:36 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version In-Reply-To: References: Message-ID: <3Mg1niwPI-4uyEH9ifLqN0ERzNGdNNcl7_w4_gfyfMw=.f42f8f15-1237-41d1-ba80-2a7cd9f72ead@github.com> On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang wrote: > This task converts 5 shell tests below to java version. > test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh > test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh > test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh > test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > test/java/lang/management/MemoryMXBean/PendingAllGC.sh We should run these tests with differrent GC in CI. ------------- PR: https://git.openjdk.org/jdk/pull/9813 From duke at openjdk.org Wed Aug 10 18:34:35 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 10 Aug 2022 18:34:35 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version In-Reply-To: References: Message-ID: On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang wrote: > This task converts 5 shell tests below to java version. > test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh > test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh > test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh > test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > test/java/lang/management/MemoryMXBean/PendingAllGC.sh It sounds good to me as long as we don't lose coverage. I will update the scripts. ------------- PR: https://git.openjdk.org/jdk/pull/9813 From duke at openjdk.org Wed Aug 10 18:50:51 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 10 Aug 2022 18:50:51 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version [v2] In-Reply-To: References: Message-ID: > This task converts 5 shell tests below to java version. > test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh > test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh > test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh > test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > test/java/lang/management/MemoryMXBean/PendingAllGC.sh Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Removed GC settings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9813/files - new: https://git.openjdk.org/jdk/pull/9813/files/2fa6e2f8..75e7f722 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=00-01 Stats: 33 lines in 4 files changed: 0 ins; 31 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9813/head:pull/9813 PR: https://git.openjdk.org/jdk/pull/9813 From cjplummer at openjdk.org Wed Aug 10 20:52:32 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Aug 2022 20:52:32 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v3] In-Reply-To: References: Message-ID: <5DsPjhUwjM0F4aafgQp8xBxH_k2mFLBKcMoWZ3aMb44=.2d064dcd-6286-46b0-86a7-b7a61afe0ce8@github.com> On Tue, 9 Aug 2022 20:29:42 GMT, Leonid Mesnik wrote: >> The test should use the same locales in all processes, the default language should work fine. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed print test/jdk/sun/tools/jstatd/JstatGCUtilParser.java line 112: > 110: double percentage = NumberFormat.getInstance().parse(value).doubleValue(); > 111: assertTrue(0 <= percentage && percentage <= 100, > 112: "Not a percentage. value: " + value + " percentage: " + percentage); This doesn't look right. If the type is `INTEGER_OR_DASH` and the value is not a "-", then we don't do the `NumberFormat` check that we previously would have done if the type was `INTEGER`. Instead we treat it as a double and assert that the value is between 0 and 100. Same issue with `DOUBLE_OR_DASH`. ------------- PR: https://git.openjdk.org/jdk/pull/9798 From lmesnik at openjdk.org Wed Aug 10 21:13:04 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 10 Aug 2022 21:13:04 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version [v2] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 18:50:51 GMT, Bill Huang wrote: >> This task converts 5 shell tests below to java version. >> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh >> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh >> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh >> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh >> test/java/lang/management/MemoryMXBean/PendingAllGC.sh > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Removed GC settings. Sorry, that I missed these comments first time. Now the code is much cleaner. test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java line 39: > 37: * @summary Test low memory detection of non-heap memory pool > 38: * > 39: * @run build MemoryUtil Not sure if you need this build, jtreg should build required files by itself. test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java line 41: > 39: * @run build MemoryUtil > 40: * > 41: * @run main/othervm/timeout=600 -noclassgc -XX:MaxMetaspaceSize=32m I would prefer to have multiply tests rather than multiply 'run' in single tests. It allow jtreg to fail only one test which fail and run them parallel. test/jdk/java/lang/management/MemoryMXBean/MemoryManagement.java line 35: > 33: * @modules jdk.management > 34: * @build MemoryManagement MemoryUtil > 35: * @run main/othervm/timeout=600 -Xmn8m -XX:+IgnoreUnrecognizedVMOptions Do we want to run this configuration without G1? Might be separate runs and add requires? ------------- Changes requested by lmesnik (Reviewer). PR: https://git.openjdk.org/jdk/pull/9813 From lmesnik at openjdk.org Wed Aug 10 21:17:10 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 10 Aug 2022 21:17:10 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v4] In-Reply-To: References: Message-ID: > The test should use the same locales in all processes, the default language should work fine. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9798/files - new: https://git.openjdk.org/jdk/pull/9798/files/2702a24a..43aedc96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9798&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9798&range=02-03 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9798.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9798/head:pull/9798 PR: https://git.openjdk.org/jdk/pull/9798 From duke at openjdk.org Wed Aug 10 21:24:35 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 10 Aug 2022 21:24:35 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version [v2] In-Reply-To: References: Message-ID: <0PK8yhJEINzYjG9vsCpb7ceOk779HGn1x8o2hVOmt4U=.6049910f-3447-4b5a-acde-c1086ff62b5e@github.com> On Wed, 10 Aug 2022 21:09:42 GMT, Leonid Mesnik wrote: >> Bill Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed GC settings. > > test/jdk/java/lang/management/MemoryMXBean/MemoryManagement.java line 35: > >> 33: * @modules jdk.management >> 34: * @build MemoryManagement MemoryUtil >> 35: * @run main/othervm/timeout=600 -Xmn8m -XX:+IgnoreUnrecognizedVMOptions > > Do we want to run this configuration without G1? Might be separate runs and add requires? It doesn't fail with other GC modes, but I agree that it is misleading. We can make it a separate test and add @requires. ------------- PR: https://git.openjdk.org/jdk/pull/9813 From cjplummer at openjdk.org Wed Aug 10 22:01:38 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 10 Aug 2022 22:01:38 GMT Subject: RFR: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" [v4] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 21:17:10 GMT, Leonid Mesnik wrote: >> The test should use the same locales in all processes, the default language should work fine. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9798 From duke at openjdk.org Wed Aug 10 22:02:52 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 10 Aug 2022 22:02:52 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version [v3] In-Reply-To: References: Message-ID: > This task converts 5 shell tests below to java version. > test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh > test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh > test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh > test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > test/java/lang/management/MemoryMXBean/PendingAllGC.sh Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Removed @build and move runs to separate tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9813/files - new: https://git.openjdk.org/jdk/pull/9813/files/75e7f722..b363daa3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9813&range=01-02 Stats: 25 lines in 2 files changed: 22 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9813.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9813/head:pull/9813 PR: https://git.openjdk.org/jdk/pull/9813 From lmesnik at openjdk.org Thu Aug 11 00:30:40 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 11 Aug 2022 00:30:40 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version [v3] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 22:02:52 GMT, Bill Huang wrote: >> This task converts 5 shell tests below to java version. >> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh >> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh >> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh >> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh >> test/java/lang/management/MemoryMXBean/PendingAllGC.sh > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Removed @build and move runs to separate tests. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9813 From lmesnik at openjdk.org Thu Aug 11 00:32:52 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 11 Aug 2022 00:32:52 GMT Subject: Integrated: 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 19:52:47 GMT, Leonid Mesnik wrote: > The test should use the same locales in all processes, the default language should work fine. This pull request has now been integrated. Changeset: 36ef4c1a Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/36ef4c1a92348b392b6009ea8b3e5636bfa1b726 Stats: 31 lines in 2 files changed: 8 ins; 5 del; 18 mod 8291081: Some sun/tools/jstatd/TestJstatd* tests fail with "Not a percentage\: 68.31\: expected true, was false" Reviewed-by: kevinw, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/9798 From duke at openjdk.org Thu Aug 11 01:49:38 2022 From: duke at openjdk.org (xpbob) Date: Thu, 11 Aug 2022 01:49:38 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v7] In-Reply-To: <1GxIcg5723Xpmw0AwwNNx_aD-joLaJbyZF2xkrKmBbA=.06dde6e6-64fb-4145-b20e-847598843f87@github.com> References: <1GxIcg5723Xpmw0AwwNNx_aD-joLaJbyZF2xkrKmBbA=.06dde6e6-64fb-4145-b20e-847598843f87@github.com> Message-ID: On Wed, 3 Aug 2022 09:18:26 GMT, Alan Bateman wrote: >> xpbob has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove line >> - add export > > What happened with the experiment to move ContainerInfoMXBean to jdk.management? Hi, @AlanBateman I updated the code and move ContainerInfoMXBean to jdk.management Can the CSR tag be removed? ------------- PR: https://git.openjdk.org/jdk/pull/9372 From sspitsyn at openjdk.org Thu Aug 11 03:13:45 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 11 Aug 2022 03:13:45 GMT Subject: RFR: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version [v3] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 22:02:52 GMT, Bill Huang wrote: >> This task converts 5 shell tests below to java version. >> test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh >> test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh >> test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh >> test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh >> test/java/lang/management/MemoryMXBean/PendingAllGC.sh > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Removed @build and move runs to separate tests. Looks good to me. Thank you for taking care about these tests! Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9813 From dholmes at openjdk.org Thu Aug 11 05:26:56 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Aug 2022 05:26:56 GMT Subject: Integrated: Merge jdk19 Message-ID: Forward port JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8288769: Revert unintentional change to deflate.c - 8291496: Allocating card table before heap causes underflow asserts in CardTable::addr_for() - 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9828/files Stats: 686 lines in 44 files changed: 89 ins; 540 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/9828.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9828/head:pull/9828 PR: https://git.openjdk.org/jdk/pull/9828 From dholmes at openjdk.org Thu Aug 11 05:26:56 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Aug 2022 05:26:56 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 00:06:35 GMT, David Holmes wrote: > Forward port JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 85a60235 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/85a602355ff6e92bb468135d712e0b0b41753db4 Stats: 686 lines in 44 files changed: 89 ins; 540 del; 57 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9828 From djelinski at openjdk.org Thu Aug 11 07:34:52 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 11 Aug 2022 07:34:52 GMT Subject: RFR: 8292233: Increase symtab hash table size Message-ID: Resize the hash table to minimize collisions. The correct size was already calculated, but was not used. ------------- Commit messages: - Increase hash table size Changes: https://git.openjdk.org/jdk/pull/9834/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292233 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9834.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9834/head:pull/9834 PR: https://git.openjdk.org/jdk/pull/9834 From kevinw at openjdk.org Thu Aug 11 13:01:25 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Aug 2022 13:01:25 GMT Subject: RFR: 8292233: Increase symtab hash table size In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 07:12:17 GMT, Daniel Jeli?ski wrote: > Resize the hash table to minimize collisions. The correct size was already calculated, but was not used. Yes this looks like the original intent! ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/9834 From duke at openjdk.org Thu Aug 11 14:38:34 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 11 Aug 2022 14:38:34 GMT Subject: Integrated: JDK-8292064 Convert java/lang/management/MemoryMXBean shell tests to java version In-Reply-To: References: Message-ID: <2lsSCwEjUh2Q6JFbJkcgOMCzo_Rt6BF1x8w-yhDalwg=.9949ffa6-854a-4e48-a1f8-8a4a76a398e0@github.com> On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang wrote: > This task converts 5 shell tests below to java version. > test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh > test/java/lang/management/MemoryMXBean/MemoryManagementParallelGC.sh > test/java/lang/management/MemoryMXBean/MemoryManagementSerialGC.sh > test/java/lang/management/MemoryMXBean/MemoryTestAllGC.sh > test/java/lang/management/MemoryMXBean/PendingAllGC.sh This pull request has now been integrated. Changeset: 7ea9ba1f Author: Bill Huang Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/7ea9ba1f6c18ace5aa0896ab8676926fdc0d64ea Stats: 346 lines in 9 files changed: 37 ins; 303 del; 6 mod 8292064: Convert java/lang/management/MemoryMXBean shell tests to java version Reviewed-by: lmesnik, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/9813 From cjplummer at openjdk.org Thu Aug 11 14:52:28 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Aug 2022 14:52:28 GMT Subject: RFR: 8292233: Increase symtab hash table size In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 07:12:17 GMT, Daniel Jeli?ski wrote: > Resize the hash table to minimize collisions. The correct size was already calculated, but was not used. Looks good. For some historical perspective, it looks like this change came with the following commit: https://github.com/openjdk/jdk/commit/2841c5eb2b502f7b299347a203df52ab918cadce#diff-166f525c275cf2d9812ceb9f8c9c98352974e23a898df4d71762d9c7d0dc2481 Oddly that is for the initial push of AOT support. My first guess was that AOT greatly increased the number of symbols, and maybe some performance profiling picked up this hash table performance, but that seems unlikely since I see no reason why AOT would have resulted in profiling SA support. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/9834 From cjplummer at openjdk.org Thu Aug 11 16:16:36 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Aug 2022 16:16:36 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events Message-ID: We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. ------------- Commit messages: - Make it clear that testcase #1 and #2 failures are ignored. - Fix jcheck failures. - Add new test for co-located events Changes: https://git.openjdk.org/jdk/pull/9840/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292250 Stats: 449 lines in 2 files changed: 449 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9840.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9840/head:pull/9840 PR: https://git.openjdk.org/jdk/pull/9840 From cjplummer at openjdk.org Thu Aug 11 16:16:36 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Aug 2022 16:16:36 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 16:03:58 GMT, Chris Plummer wrote: > We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). > > https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html > > And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. Here is output from a test run that might be useful when reviewing the test: Got main thread: instance of java.lang.Thread(name='main', id=1) Waiting for events: EventSet for test case #0: event set, policy:2, count:1 = {BreakpointEvent at CLEDebugee:75 in thread main} Got BreakpointEvent(1): CLEDebugee.test1:75 EventSet for test case #1: event set, policy:2, count:5 = {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 in thread main, MethodEntryEvent at java.lang.System:497 in thread main, MethodEntryEvent at java.lang.System:205 in thread main, MethodExitEvent at java.lang.System:205 in thread main} TESTCASE #1 FAILED (ignoring): too many events in EventSest: 5 Got MethodEntryEvent: java.lang.ClassLoader.loadClass:521 Got MethodEntryEvent: jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass:180 Got MethodEntryEvent: java.lang.System.getSecurityManager:497 Got MethodEntryEvent: java.lang.System.allowSecurityManager:205 Got MethodExitEvent: java.lang.System.allowSecurityManager:205 EventSet for test case #1: event set, policy:2, count:1 = {StepEvent at CLEDebugee:76 in thread main} Got StepEvent: CLEDebugee.test1:76 EventSet for test case #1: event set, policy:2, count:1 = {BreakpointEvent at CLEDebugee:78 in thread main} Got BreakpointEvent(2): CLEDebugee.test2:78 EventSet for test case #2: event set, policy:2, count:5 = {MethodEntryEvent at java.lang.ClassLoader:521 in thread main, MethodEntryEvent at jdk.internal.loader.ClassLoaders$AppClassLoader:180 in thread main, MethodEntryEvent at java.lang.System:497 in thread main, MethodEntryEvent at java.lang.System:205 in thread main, MethodExitEvent at java.lang.System:205 in thread main} TESTCASE #2 FAILED (ignoring): too many events in EventSest: 5 Got MethodEntryEvent: java.lang.ClassLoader.loadClass:521 Got MethodEntryEvent: jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass:180 Got MethodEntryEvent: java.lang.System.getSecurityManager:497 Got MethodEntryEvent: java.lang.System.allowSecurityManager:205 Got MethodExitEvent: java.lang.System.allowSecurityManager:205 EventSet for test case #2: event set, policy:2, count:1 = {StepEvent at t2:44 in thread main} Got StepEvent: t2.foo:44 EventSet for test case #2: event set, policy:2, count:1 = {BreakpointEvent at CLEDebugee:63 in thread main} Got BreakpointEvent(3): CLEDebugee.runTests:63 EventSet for test case #3: event set, policy:2, count:3 = {MethodEntryEvent at CLEDebugee:87 in thread main, StepEvent at CLEDebugee:87 in thread main, BreakpointEvent at CLEDebugee:87 in thread main} Got MethodEntryEvent: CLEDebugee.test3:87 Got StepEvent: CLEDebugee.test3:87 Got BreakpointEvent(4): CLEDebugee.test3:87 TESTCASE #3 PASSED EventSet for test case #3: event set, policy:2, count:1 = {BreakpointEvent at CLEDebugee:64 in thread main} Got BreakpointEvent(5): CLEDebugee.runTests:64 EventSet for test case #4: event set, policy:2, count:2 = {MethodEntryEvent at CLEDebugee:95 in thread main, BreakpointEvent at CLEDebugee:95 in thread main} Got MethodEntryEvent: CLEDebugee.test4:95 Got BreakpointEvent(6): CLEDebugee.test4:95 TESTCASE #4 PASSED EventSet for test case #4: event set, policy:2, count:1 = {BreakpointEvent at CLEDebugee:65 in thread main} Got BreakpointEvent(7): CLEDebugee.runTests:65 EventSet for test case #5: event set, policy:2, count:2 = {StepEvent at CLEDebugee:102 in thread main, BreakpointEvent at CLEDebugee:102 in thread main} Got StepEvent: CLEDebugee.test5:102 Got BreakpointEvent(8): CLEDebugee.test5:102 TESTCASE #5 PASSED EventSet for test case #5: event set, policy:2, count:1 = {BreakpointEvent at CLEDebugee:66 in thread main} Got BreakpointEvent(9): CLEDebugee.runTests:66 EventSet for test case #6: event set, policy:2, count:2 = {MethodEntryEvent at CLEDebugee:109 in thread main, StepEvent at CLEDebugee:109 in thread main} Got MethodEntryEvent: CLEDebugee.test6:109 Got StepEvent: CLEDebugee.test6:109 TESTCASE #6 PASSED EventSet for test case #6: event set, policy:2, count:2 = {VMDeathEvent, VMDeathEvent} All done... EventSet for test case #6: event set, policy:0, count:1 = {VMDisconnectEvent} ------------- PR: https://git.openjdk.org/jdk/pull/9840 From cjplummer at openjdk.org Thu Aug 11 16:45:54 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Aug 2022 16:45:54 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v2] In-Reply-To: References: Message-ID: > We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). > > https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html > > And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Fix minor typo in output. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9840/files - new: https://git.openjdk.org/jdk/pull/9840/files/93fa1957..6bf3dd79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9840.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9840/head:pull/9840 PR: https://git.openjdk.org/jdk/pull/9840 From dcubed at openjdk.org Thu Aug 11 20:25:05 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 11 Aug 2022 20:25:05 GMT Subject: RFR: 8292262: adjust timeouts in several M&M tests Message-ID: Trivial fixes to adjust timeouts in several M&M tests. This fix is being tested in my jdk-20+10 stress testing. ------------- Commit messages: - 8292262: adjust timeouts in several M&M tests Changes: https://git.openjdk.org/jdk/pull/9847/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9847&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292262 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9847/head:pull/9847 PR: https://git.openjdk.org/jdk/pull/9847 From kevinw at openjdk.org Thu Aug 11 20:23:23 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Aug 2022 20:23:23 GMT Subject: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" Message-ID: This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. Attempting more heuristics to sense these unrelated changes just means we skip more pools. The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: ----------System.out:(15/796)---------- ... 5 pool G1 Old Gen of type: Heap memory used value is 1024000 max is 1038090240 isExceeded = false peak used value is 1024000 threshold set to 1024001 threshold count 0 reset peak usage. peak usage = 1024000 isExceeded = false Allocated heap. isExceeded = true used value is 106930176 max is 1038090240 isExceeded = true peak used value is 106930176 peak max is 1038090240 threshold count 1 ------------- Commit messages: - 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" Changes: https://git.openjdk.org/jdk/pull/9842/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9842&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290909 Stats: 19 lines in 1 file changed: 5 ins; 7 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9842.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9842/head:pull/9842 PR: https://git.openjdk.org/jdk/pull/9842 From cjplummer at openjdk.org Thu Aug 11 21:04:09 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Aug 2022 21:04:09 GMT Subject: RFR: 8292262: adjust timeouts in several M&M tests In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 20:15:14 GMT, Daniel D. Daugherty wrote: > Trivial fixes to adjust timeouts in several M&M tests. > > This fix is being tested in my jdk-20+10 stress testing. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9847 From cjplummer at openjdk.org Thu Aug 11 21:09:55 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Aug 2022 21:09:55 GMT Subject: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 18:27:12 GMT, Kevin Walls wrote: > This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. > Attempting more heuristics to sense these unrelated changes just means we skip more pools. > > The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). > > There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. > > Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). > > > Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: > > ----------System.out:(15/796)---------- > ... > 5 pool G1 Old Gen of type: Heap memory > used value is 1024000 max is 1038090240 isExceeded = false > peak used value is 1024000 > threshold set to 1024001 > threshold count 0 > reset peak usage. peak usage = 1024000 isExceeded = false > Allocated heap. isExceeded = true > used value is 106930176 max is 1038090240 isExceeded = true > peak used value is 106930176 peak max is 1038090240 > threshold count 1 test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001.java line 71: > 69: long max = usage.getMax(); > 70: long peakUsed = peakUsage.getUsed(); > 71: long peakMax = peakUsage.getMax(); You fetch peakMax here, but you don't display it until after you fetch it again below (for monitor). ------------- PR: https://git.openjdk.org/jdk/pull/9842 From kevinw at openjdk.org Thu Aug 11 21:19:11 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 11 Aug 2022 21:19:11 GMT Subject: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 21:06:05 GMT, Chris Plummer wrote: >> This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. >> Attempting more heuristics to sense these unrelated changes just means we skip more pools. >> >> The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). >> >> There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. >> >> Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). >> >> >> Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: >> >> ----------System.out:(15/796)---------- >> ... >> 5 pool G1 Old Gen of type: Heap memory >> used value is 1024000 max is 1038090240 isExceeded = false >> peak used value is 1024000 >> threshold set to 1024001 >> threshold count 0 >> reset peak usage. peak usage = 1024000 isExceeded = false >> Allocated heap. isExceeded = true >> used value is 106930176 max is 1038090240 isExceeded = true >> peak used value is 106930176 peak max is 1038090240 >> threshold count 1 > > test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001.java line 71: > >> 69: long max = usage.getMax(); >> 70: long peakUsed = peakUsage.getUsed(); >> 71: long peakMax = peakUsage.getMax(); > > You fetch peakMax here, but you don't display it until after you fetch it again below (for monitor). Actually yes that shows some hesitation where I wanted to take out peakMax, having stared at the logs it never adds any useful info, we are not stressing the pools such that their max capacity is changing... I will update, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9842 From duke at openjdk.org Thu Aug 11 21:21:23 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 11 Aug 2022 21:21:23 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version Message-ID: This task converts 2 shell tests to java version. test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh test/java/lang/management/RuntimeMXBean/TestInputArgument.sh ------------- Commit messages: - Updated copyright header. - Converted TestInputArgument.sh to java version. - Coverted TestSystemLoadAvg shell test to java version. Changes: https://git.openjdk.org/jdk/pull/9848/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9848&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292066 Stats: 200 lines in 4 files changed: 43 ins; 144 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/9848.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9848/head:pull/9848 PR: https://git.openjdk.org/jdk/pull/9848 From dcubed at openjdk.org Thu Aug 11 21:40:05 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 11 Aug 2022 21:40:05 GMT Subject: RFR: 8292262: adjust timeouts in several M&M tests In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 21:01:20 GMT, Chris Plummer wrote: >> Trivial fixes to adjust timeouts in several M&M tests. >> >> This fix is being tested in my jdk-20+10 stress testing. > > Marked as reviewed by cjplummer (Reviewer). @plummercj - Thanks for the review. Do you agree that these are trivial changes? ------------- PR: https://git.openjdk.org/jdk/pull/9847 From cjplummer at openjdk.org Thu Aug 11 21:40:06 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 11 Aug 2022 21:40:06 GMT Subject: RFR: 8292262: adjust timeouts in several M&M tests In-Reply-To: References: Message-ID: <6hppKWMn_ytWtM2txTOUUKOOt4aZ-eXPAUiwrMSW9jQ=.4f085fcb-ba7e-4aa8-af1f-844772f53725@github.com> On Thu, 11 Aug 2022 21:01:20 GMT, Chris Plummer wrote: >> Trivial fixes to adjust timeouts in several M&M tests. >> >> This fix is being tested in my jdk-20+10 stress testing. > > Marked as reviewed by cjplummer (Reviewer). > @plummercj - Thanks for the review. Do you agree that these are trivial changes? ok ------------- PR: https://git.openjdk.org/jdk/pull/9847 From dcubed at openjdk.org Thu Aug 11 21:54:55 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 11 Aug 2022 21:54:55 GMT Subject: RFR: 8292262: adjust timeouts in several M&M tests In-Reply-To: <6hppKWMn_ytWtM2txTOUUKOOt4aZ-eXPAUiwrMSW9jQ=.4f085fcb-ba7e-4aa8-af1f-844772f53725@github.com> References: <6hppKWMn_ytWtM2txTOUUKOOt4aZ-eXPAUiwrMSW9jQ=.4f085fcb-ba7e-4aa8-af1f-844772f53725@github.com> Message-ID: On Thu, 11 Aug 2022 21:36:41 GMT, Chris Plummer wrote: >> Marked as reviewed by cjplummer (Reviewer). > >> @plummercj - Thanks for the review. Do you agree that these are trivial changes? > > ok @plummercj - Thanks. My current stress testing cycle will finish on Sunday. ------------- PR: https://git.openjdk.org/jdk/pull/9847 From dcubed at openjdk.org Thu Aug 11 23:20:02 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 11 Aug 2022 23:20:02 GMT Subject: RFR: 8292261: adjust timeouts in JLI GetObjectSizeIntrinsicsTest.java Message-ID: A trivial fix to adjust the timeouts for two of the sub-tests in JLI GetObjectSizeIntrinsicsTest.java. This fix is being tested in my jdk-20+10 stress testing. ------------- Commit messages: - 8292261: adjust timeouts in JLI GetObjectSizeIntrinsicsTest.java Changes: https://git.openjdk.org/jdk/pull/9846/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9846&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292261 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9846.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9846/head:pull/9846 PR: https://git.openjdk.org/jdk/pull/9846 From iklam at openjdk.org Fri Aug 12 03:15:02 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Aug 2022 03:15:02 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp Message-ID: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Fix two problems with synchronizer.hpp: - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. These headers are included much less after this PR (out of ~1000 hotspot .o files) linkedlist.hpp 857 -> 101 synchronizer.hpp 848 -> 122 resourceHash.hpp 850 -> 270 ------------- Commit messages: - added back inlined functions in case their performance matters - fixed copyright - 8292267: Clean up synchronizer.hpp Changes: https://git.openjdk.org/jdk/pull/9849/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292267 Stats: 54 lines in 21 files changed: 27 ins; 20 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9849.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9849/head:pull/9849 PR: https://git.openjdk.org/jdk/pull/9849 From djelinski at openjdk.org Fri Aug 12 05:29:08 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 12 Aug 2022 05:29:08 GMT Subject: Integrated: 8292233: Increase symtab hash table size In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 07:12:17 GMT, Daniel Jeli?ski wrote: > Resize the hash table to minimize collisions. The correct size was already calculated, but was not used. This pull request has now been integrated. Changeset: 083e014d Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/083e014d0caf673f5da04229ba263f45724cb418 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8292233: Increase symtab hash table size Reviewed-by: kevinw, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/9834 From kevinw at openjdk.org Fri Aug 12 10:05:39 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 12 Aug 2022 10:05:39 GMT Subject: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" [v2] In-Reply-To: References: Message-ID: > This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. > Attempting more heuristics to sense these unrelated changes just means we skip more pools. > > The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). > > There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. > > Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). > > > Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: > > ----------System.out:(15/796)---------- > ... > 5 pool G1 Old Gen of type: Heap memory > used value is 1024000 max is 1038090240 isExceeded = false > peak used value is 1024000 > threshold set to 1024001 > threshold count 0 > reset peak usage. peak usage = 1024000 isExceeded = false > Allocated heap. isExceeded = true > used value is 106930176 max is 1038090240 isExceeded = true > peak used value is 106930176 peak max is 1038090240 > threshold count 1 Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove fetching and logging of peak max usage. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9842/files - new: https://git.openjdk.org/jdk/pull/9842/files/2583e89f..07a05ea0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9842&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9842&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9842.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9842/head:pull/9842 PR: https://git.openjdk.org/jdk/pull/9842 From coleenp at openjdk.org Fri Aug 12 13:24:18 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Aug 2022 13:24:18 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com> On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam wrote: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Very nice. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9849 From dcubed at openjdk.org Fri Aug 12 15:30:18 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 12 Aug 2022 15:30:18 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam wrote: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Looks great. I only posted a few nit comments. src/hotspot/share/gc/shenandoah/shenandoahPadding.hpp line 28: > 26: #define SHARE_GC_SHENANDOAH_SHENANDOAHPADDING_HPP > 27: > 28: #include "memory/padded.hpp" This one surprised me, but I'm guessing it was included indirectly from synchronizer.hpp via some frame header... src/hotspot/share/prims/jvmtiExport.hpp line 50: > 48: class JvmtiEnv; > 49: class JvmtiThreadState; > 50: class ThreadsList; Not in sorted order relative to OopStorage. Does it need to be? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9849 From dholmes at openjdk.org Fri Aug 12 21:11:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Aug 2022 21:11:13 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam wrote: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Looks fine. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9849 From iklam at openjdk.org Fri Aug 12 21:45:23 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Aug 2022 21:45:23 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp [v2] In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dcubed-ojdk review comments - reorder class forward declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9849/files - new: https://git.openjdk.org/jdk/pull/9849/files/9b372650..f2dfac39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9849.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9849/head:pull/9849 PR: https://git.openjdk.org/jdk/pull/9849 From cjplummer at openjdk.org Fri Aug 12 22:17:20 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 12 Aug 2022 22:17:20 GMT Subject: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" [v2] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls wrote: >> This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. >> Attempting more heuristics to sense these unrelated changes just means we skip more pools. >> >> The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). >> >> There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. >> >> Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). >> >> >> Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: >> >> ----------System.out:(15/796)---------- >> ... >> 5 pool G1 Old Gen of type: Heap memory >> used value is 1024000 max is 1038090240 isExceeded = false >> peak used value is 1024000 >> threshold set to 1024001 >> threshold count 0 >> reset peak usage. peak usage = 1024000 isExceeded = false >> Allocated heap. isExceeded = true >> used value is 106930176 max is 1038090240 isExceeded = true >> peak used value is 106930176 peak max is 1038090240 >> threshold count 1 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove fetching and logging of peak max usage. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9842 From adacooke99 at gmail.com Sat Aug 13 22:20:14 2022 From: adacooke99 at gmail.com (Ada) Date: Sat, 13 Aug 2022 23:20:14 +0100 Subject: JVMTI invokedynamic bytecode parsing Message-ID: Hi, I'm writing a JVMTI tool that needs to parse bytecode. To parse invokedynamic, you need to read from the parent class' bootstrap methods attribute, there is no current function in the JVMTI spec to get this information, not having this information isn't the end of the world but it seems odd. Am I missing something in regards to this, if not, are there any plans for adding this functionality in the future? From aturbanov at openjdk.org Mon Aug 15 08:23:08 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 15 Aug 2022 08:23:08 GMT Subject: RFR: 8292350: Use static methods for hashCode/toString primitives Message-ID: It's a bit shorter and clearer. ------------- Commit messages: - [PATCH] Use static methods for hashCode/toString primitives Changes: https://git.openjdk.org/jdk/pull/9816/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9816&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292350 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9816.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9816/head:pull/9816 PR: https://git.openjdk.org/jdk/pull/9816 From duke at openjdk.org Mon Aug 15 08:23:09 2022 From: duke at openjdk.org (ExE Boss) Date: Mon, 15 Aug 2022 08:23:09 GMT Subject: RFR: 8292350: Use static methods for hashCode/toString primitives In-Reply-To: References: Message-ID: <7O38TdppE3N6L3AVwmwskuzGAMYhslZEk6LNPRPvddk=.ee44fa2d-5624-42a4-a757-7c4b74874699@github.com> On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov wrote: > It's a bit shorter and clearer. Also, it?avoids unnecessary?boxing. ------------- PR: https://git.openjdk.org/jdk/pull/9816 From aboldtch at openjdk.org Mon Aug 15 15:20:04 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Aug 2022 15:20:04 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v4] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Rename deoptimize_done enum value - Add missing code from list revert - Initial draft new terminology - Make _context_active atomic - Missed merge changes - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Merge branch 'JDK-8291718' into JDK-8291237 - Remove indentation - Fix for shenandoah - ... and 13 more: https://git.openjdk.org/jdk/compare/fd4b2f28...2be7b152 ------------- Changes: https://git.openjdk.org/jdk/pull/9655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=03 Stats: 685 lines in 27 files changed: 283 ins; 284 del; 118 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From prr at openjdk.org Mon Aug 15 16:45:13 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 15 Aug 2022 16:45:13 GMT Subject: RFR: 8292350: Use static methods for hashCode/toString primitives In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov wrote: > It's a bit shorter and clearer. Approving (just) the client change ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.org/jdk/pull/9816 From cjplummer at openjdk.org Mon Aug 15 18:24:14 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 15 Aug 2022 18:24:14 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 16:45:54 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix minor typo in output. Ping! ------------- PR: https://git.openjdk.org/jdk/pull/9840 From rriggs at openjdk.org Mon Aug 15 19:04:10 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Aug 2022 19:04:10 GMT Subject: RFR: 8292350: Use static methods for hashCode/toString primitives In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov wrote: > It's a bit shorter and clearer. lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9816 From kevinw at openjdk.org Tue Aug 16 15:02:17 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 16 Aug 2022 15:02:17 GMT Subject: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" [v2] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls wrote: >> This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. >> Attempting more heuristics to sense these unrelated changes just means we skip more pools. >> >> The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). >> >> There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. >> >> Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). >> >> >> Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: >> >> ----------System.out:(15/796)---------- >> ... >> 5 pool G1 Old Gen of type: Heap memory >> used value is 1024000 max is 1038090240 isExceeded = false >> peak used value is 1024000 >> threshold set to 1024001 >> threshold count 0 >> reset peak usage. peak usage = 1024000 isExceeded = false >> Allocated heap. isExceeded = true >> used value is 106930176 max is 1038090240 isExceeded = true >> peak used value is 106930176 peak max is 1038090240 >> threshold count 1 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove fetching and logging of peak max usage. thanks Chris! ------------- PR: https://git.openjdk.org/jdk/pull/9842 From cjplummer at openjdk.org Tue Aug 16 17:43:37 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 16 Aug 2022 17:43:37 GMT Subject: RFR: 8292261: adjust timeouts in JLI GetObjectSizeIntrinsicsTest.java In-Reply-To: References: Message-ID: <4mLOF33JCf-dylPUyy7SeZeFYmIOKcvQz9LKzCFAlJ4=.3a3703b5-3216-49a0-b2dc-de2ebe7f6b2c@github.com> On Thu, 11 Aug 2022 20:14:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to adjust the timeouts for two of the sub-tests in JLI GetObjectSizeIntrinsicsTest.java. > > This fix is being tested in my jdk-20+10 stress testing. Marked as reviewed by cjplummer (Reviewer). Changes are trivial. ------------- PR: https://git.openjdk.org/jdk/pull/9846 From sgehwolf at openjdk.org Tue Aug 16 17:53:18 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 16 Aug 2022 17:53:18 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> Message-ID: On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor hotspot gtest > - Separate into function. Fix comment. Don't close bot, please. ------------- PR: https://git.openjdk.org/jdk/pull/8629 From chris.plummer at oracle.com Tue Aug 16 22:37:43 2022 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 16 Aug 2022 15:37:43 -0700 Subject: JVMTI invokedynamic bytecode parsing In-Reply-To: References: Message-ID: <94f570d6-9fe4-d17b-921d-e36395ae4631@oracle.com> I'm no expert in this area, especially regarding invokedynamic and bootstrap methods attributes. I see from the JVM spec that you are referring to the constant pool BootstrapMethods attribute. Also from the JVM spec I see that there are other attributes that JVMTI does not provide any special access to. Some you can get with various JVMTI APIs, like GetLocalVariableTable, which gives you the part of the LocalVariableTable attribute that is relevant to the specified method. But there are attributes that don't have any special APIs to access, such as NestHost, NestMembers, Record, or PermittedSubclasses, What might work for you is to just to fetch the constant pool using GetConstantPool, and get the BootstrapMethods attribute from it. Chris On 8/13/22 3:20 PM, Ada wrote: > Hi, > I'm writing a JVMTI tool that needs to parse bytecode. To parse > invokedynamic, you need to read from the parent class' bootstrap > methods attribute, there is no current function in the JVMTI spec to > get this information, not having this information isn't the end of the > world but it seems odd. Am I missing something in regards to this, if > not, are there any plans for adding this functionality in the future? From Alan.Bateman at oracle.com Wed Aug 17 07:13:42 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Aug 2022 08:13:42 +0100 Subject: JVMTI invokedynamic bytecode parsing In-Reply-To: <94f570d6-9fe4-d17b-921d-e36395ae4631@oracle.com> References: <94f570d6-9fe4-d17b-921d-e36395ae4631@oracle.com> Message-ID: <07016971-3ab2-9137-3cf4-02fb74498a4b@oracle.com> On 16/08/2022 23:37, Chris Plummer wrote: > I'm no expert in this area, especially regarding invokedynamic and > bootstrap methods attributes. I see from the JVM spec that you are > referring to the constant pool BootstrapMethods attribute. Also from > the JVM spec I see that there are other attributes that JVMTI does not > provide any special access to. Some you can get with various JVMTI > APIs, like GetLocalVariableTable, which gives you the part of the > LocalVariableTable attribute that is relevant to the specified method. > But there are attributes that don't have any special APIs to access, > such as NestHost, NestMembers, Record, or PermittedSubclasses, > > What might work for you is to just to fetch the constant pool using > GetConstantPool, and get the BootstrapMethods attribute from it. Right now, to get the class bytes you have to set a CFLH, re-run the transformation pipeline with RetransformClasses and have the CFLH capture the bytes. I think there were a requests for a GetClassfile like API at one point. -Alan From aboldtch at openjdk.org Wed Aug 17 14:13:08 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 17 Aug 2022 14:13:08 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v5] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Add list optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/2be7b152..bea67dea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=03-04 Stats: 65 lines in 3 files changed: 50 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From hohensee at amazon.com Wed Aug 17 18:40:03 2022 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Aug 2022 18:40:03 +0000 Subject: OperatingSystemMXBean and network usage and limit information Message-ID: <2730DAF1-DA41-4E35-B3E7-A541DA336211@amazon.com> This is a serviceability-dev issue, redirected. Thanks, Paul ?-----Original Message----- From: discuss on behalf of Severin Gehwolf Date: Wednesday, August 17, 2022 at 2:00 AM To: "discuss at openjdk.org" Subject: RE: OperatingSystemMXBean and network usage and limit information Hi, On Wed, 2022-08-17 at 10:05 +0300, Asaf Mesika wrote: > Hi, > > I've searched through the various mailing lists, but couldn't find a > suitable one so I'm posting it here. > > I would like to have the ability to know from an application the > current network usage and limit (relative to host or cgroup). > > I have seen the class OperatingSystemMXBean that is provided by the > JDK. I was wondering if the idea of adding that information to this > bean has been considered in the past. > > Currently, the best option I found, which is operating system- > specific code, is to use the /sys/class/net/ files. One challenge for this would be to do this in a version agnostic way. Another is that nothing is using this info at present and we'd have to have a compelling use-case where adding such an API would be useful. AFAIK, net_cls which would allow something like that in v1, does not exist for v2. With all that said, I don't think there are any plans to do this. Thanks, Severin From aboldtch at openjdk.org Thu Aug 18 08:18:27 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 18 Aug 2022 08:18:27 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Cleanup comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/bea67dea..4b95396c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From aboldtch at openjdk.org Thu Aug 18 08:55:22 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 18 Aug 2022 08:55:22 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup comment Opening this PR for review. Terminology for deoptimizing compiled methods has been updated and the process encapsulated. The terminology was chosen to better reflect what is happening and not clash with other terminology used when working with compiled methods. The encapsulation was done with a RAII object which enables more rigorous assertion of the usage and behaviour of the code. The fix for the deviation mentioned in the issue and the comments above was address in [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) and has been merged. I made some comments about moving out the linked list optimisation into a separate issue, however there are two tests that currently are sensitive to (I suspect) asserts inside the critical sections of the deoptimization. The tests are: * `vmTestbase/vm/mlvm/indy/stress/java/volatileCallSiteDekker/TestDescription.java` * `vmTestbase/vm/mlvm/indy/stress/java/mutableCallSiteDekker/TestDescription.java` They will (most of the time) timeout on linux debug builds, but succeed with a larger `timeoutFactor`. I do not yet have access to a linux machine to debug and investigate more thoroughly, but I suspect that, as this test just keep rebinding CallSites in a loop, they trigger a lot of deoptimizations which creates a lot of contention on the `Compile_lock` and `CodeCache_lock`, and the longer critical sections (due to more asserts) increase the probability of contention slowdowns. With the bea67de the timeout problem goes away as we are not walking the CodeCache when we do not need to. The unnecessary CodeCache walking time to safepoint issue is what motivated the encapsulation in the first place. __Testing: Oracle Platforms Tier 1-5__ ------------- PR: https://git.openjdk.org/jdk/pull/9655 From dlong at openjdk.org Thu Aug 18 09:01:15 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 18 Aug 2022 09:01:15 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup comment src/hotspot/share/code/compiledMethod.cpp line 128: > 126: if (old_status < new_status) { > 127: if (old_status == not_enqueued) { > 128: assert(extract_enqueued_deoptimization_method(_enqueued_deoptimization_link) == nullptr, "Compiled Method should not already be linked"); This doesn't work for the tail of the list, does it? That's why I suggested making the tail loop back to itself. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From aboldtch at openjdk.org Thu Aug 18 09:37:18 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 18 Aug 2022 09:37:18 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 08:57:19 GMT, Dean Long wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup comment > > src/hotspot/share/code/compiledMethod.cpp line 128: > >> 126: if (old_status < new_status) { >> 127: if (old_status == not_enqueued) { >> 128: assert(extract_enqueued_deoptimization_method(_enqueued_deoptimization_link) == nullptr, "Compiled Method should not already be linked"); > > This doesn't work for the tail of the list, does it? That's why I suggested making the tail loop back to itself > > I would also like to see similar asserts added to make sure we don't recycle an nmethod that is still on the list, perhaps in nmethod::flush(). I think you have to describe the scenario that does not work, because I am not sure I see it. For ease of writing, let me call the currently embedded status `status` and the currently embedded link `next_link` (`=>` means implies here) The assert checks this invariant: `status == not_enqueued => next_link == nullptr` After adding the first method (which will be the tail) to the list (`root == nullptr`) we will have: * `status > not_enqueued` * `next_link == nullptr` After adding any method after that ( `root != nullptr`) we will have: * `status > not_enqueued` * `next_link == previous_root` And there is also a fresh method * `status == not_enqueued` * `next_link == nullptr` If we try to enqueue an already enqueued method (calling `enqueue_deoptimization` twice) the method will have `status != not_enqueued` and will set `next_link == next_link` if `new_status > status`. (So just update the status to a stronger variant, but not change the link) All of these possibilities upholds the invariant. Maybe you are looking for some more invariant checks, like `status > not_enqueued => InList(method)` which can be asserted by setting `next_link == this` for the tail (when `root == nullptr`) and assert that `next_link != nullptr` if `status > not_enqueued`. But it just seems like we are adding another flag for something we already check, essentially `next_link != nullptr` iff `status > not_enqueued`. There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From mbaesken at openjdk.org Thu Aug 18 11:59:38 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 18 Aug 2022 11:59:38 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory Message-ID: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> There seems to be a case where utf_util.c getWideString might leak memory in an early return. ------------- Commit messages: - JDK-8292595 Changes: https://git.openjdk.org/jdk/pull/9918/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9918&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292595 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9918.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9918/head:pull/9918 PR: https://git.openjdk.org/jdk/pull/9918 From alanb at openjdk.org Thu Aug 18 12:34:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Aug 2022 12:34:11 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory In-Reply-To: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken wrote: > There seems to be a case where utf_util.c getWideString might leak memory in an early return. src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c line 346: > 344: if (MultiByteToWideChar(codePage, 0, str, len, wstr, wlen) == 0) { > 345: UTF_ERROR(("Can't get WIDE string")); > 346: free(wstr); Is this really an issue? I thought that UTF_ERROR prints the error and aborts the program. ------------- PR: https://git.openjdk.org/jdk/pull/9918 From mbaesken at openjdk.org Thu Aug 18 12:46:15 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 18 Aug 2022 12:46:15 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory In-Reply-To: References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: <8lDRYPoZ09b30Bkzj_bJ9rzZWgIDu1LAMHcpRW5M9v0=.dd68c09f-fb17-431e-8803-fe546f42622c@github.com> On Thu, 18 Aug 2022 12:30:57 GMT, Alan Bateman wrote: >> There seems to be a case where utf_util.c getWideString might leak memory in an early return. > > src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c line 346: > >> 344: if (MultiByteToWideChar(codePage, 0, str, len, wstr, wlen) == 0) { >> 345: UTF_ERROR(("Can't get WIDE string")); >> 346: free(wstr); > > Is this really an issue? I thought that UTF_ERROR prints the error and aborts the program. Hi Alan, yeah I saw that it prints an error but you are correct it does an abort() call too. So probably we can keep this as it is. Another MultiByteToWideChar / malloc case I just saw https://github.com/openjdk/jdk/blob/master/src/java.instrument/windows/native/libinstrument/EncodingSupport_md.c#L79 shouldn't there be the free call after line 80 ? ------------- PR: https://git.openjdk.org/jdk/pull/9918 From alanb at openjdk.org Thu Aug 18 12:56:16 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Aug 2022 12:56:16 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory In-Reply-To: <8lDRYPoZ09b30Bkzj_bJ9rzZWgIDu1LAMHcpRW5M9v0=.dd68c09f-fb17-431e-8803-fe546f42622c@github.com> References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> <8lDRYPoZ09b30Bkzj_bJ9rzZWgIDu1LAMHcpRW5M9v0=.dd68c09f-fb17-431e-8803-fe546f42622c@github.com> Message-ID: On Thu, 18 Aug 2022 12:42:48 GMT, Matthias Baesken wrote: > Another MultiByteToWideChar / malloc case I just saw > https://github.com/openjdk/jdk/blob/master/src/java.instrument/windows/native/libinstrument/EncodingSupport_md.c#L79 > shouldn't there be the free call after line 80 ? I think you are right, it won't free if MultiByteToWideChar were to fail. ------------- PR: https://git.openjdk.org/jdk/pull/9918 From dlong at openjdk.org Fri Aug 19 01:20:35 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 19 Aug 2022 01:20:35 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 09:32:54 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/code/compiledMethod.cpp line 128: >> >>> 126: if (old_status < new_status) { >>> 127: if (old_status == not_enqueued) { >>> 128: assert(extract_enqueued_deoptimization_method(_enqueued_deoptimization_link) == nullptr, "Compiled Method should not already be linked"); >> >> This doesn't work for the tail of the list, does it? That's why I suggested making the tail loop back to itself >> >> I would also like to see similar asserts added to make sure we don't recycle an nmethod that is still on the list, perhaps in nmethod::flush(). > > I think you have to describe the scenario that does not work, because I am not sure I see it. > > For ease of writing, let me call the currently embedded status `status` and the currently embedded link `next_link` > (`=>` means implies here) > > The assert checks this invariant: `status == not_enqueued => next_link == nullptr` > > After adding the first method (which will be the tail) to the list (`root == nullptr`) we will have: > * `status > not_enqueued` > * `next_link == nullptr` > > After adding any method after that ( `root != nullptr`) we will have: > * `status > not_enqueued` > * `next_link == previous_root` > > And there is also a fresh method > * `status == not_enqueued` > * `next_link == nullptr` > > If we try to enqueue an already enqueued method (calling `enqueue_deoptimization` twice) the method will have `status != not_enqueued` and will set `next_link == next_link` if `new_status > status`. (So just update the status to a stronger variant, but not change the link) > > All of these possibilities upholds the invariant. > > Maybe you are looking for some more invariant checks, like > `status > not_enqueued => InList(method)` which can be asserted by setting `next_link == this` for the tail (when `root == nullptr`) and assert that `next_link != nullptr` if `status > not_enqueued`. But it just seems like we are adding another flag for something we already check, essentially `next_link != nullptr` iff `status > not_enqueued`. > > There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. Yes, something like (status == not_enqueued) == !InList(method), which is strong than the current =>, and would be a sanity check on the status. > There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. That wouldn't necessarily catch accessing stale nmethod memory that has been released by CodeCache::free(), would it? ------------- PR: https://git.openjdk.org/jdk/pull/9655 From iklam at openjdk.org Fri Aug 19 06:32:26 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 06:32:26 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp [v3] In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into 8292267-clean-up-synchronizer-hpp - @dcubed-ojdk review comments - reorder class forward declarations - added back inlined functions in case their performance matters - fixed copyright - 8292267: Clean up synchronizer.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/9849/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=02 Stats: 54 lines in 21 files changed: 28 ins; 21 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9849.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9849/head:pull/9849 PR: https://git.openjdk.org/jdk/pull/9849 From aboldtch at openjdk.org Fri Aug 19 09:38:34 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 19 Aug 2022 09:38:34 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v6] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 01:17:14 GMT, Dean Long wrote: >> I think you have to describe the scenario that does not work, because I am not sure I see it. >> >> For ease of writing, let me call the currently embedded status `status` and the currently embedded link `next_link` >> (`=>` means implies here) >> >> The assert checks this invariant: `status == not_enqueued => next_link == nullptr` >> >> After adding the first method (which will be the tail) to the list (`root == nullptr`) we will have: >> * `status > not_enqueued` >> * `next_link == nullptr` >> >> After adding any method after that ( `root != nullptr`) we will have: >> * `status > not_enqueued` >> * `next_link == previous_root` >> >> And there is also a fresh method >> * `status == not_enqueued` >> * `next_link == nullptr` >> >> If we try to enqueue an already enqueued method (calling `enqueue_deoptimization` twice) the method will have `status != not_enqueued` and will set `next_link == next_link` if `new_status > status`. (So just update the status to a stronger variant, but not change the link) >> >> All of these possibilities upholds the invariant. >> >> Maybe you are looking for some more invariant checks, like >> `status > not_enqueued => InList(method)` which can be asserted by setting `next_link == this` for the tail (when `root == nullptr`) and assert that `next_link != nullptr` if `status > not_enqueued`. But it just seems like we are adding another flag for something we already check, essentially `next_link != nullptr` iff `status > not_enqueued`. >> >> There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. > > Yes, something like (status == not_enqueued) == !InList(method), which is strong than the current =>, and would be a sanity check on the status. > >> There is currently an assert when we iterate over the list; that the number of methods we find in the list is equal to number of methods we enqueued. > > That wouldn't necessarily catch accessing stale nmethod memory that has been released by CodeCache::free(), would it? Yeah the point of that assert was simply to check the sanity of the iteration implementation. The validity of the actual pointer is suppose to be guaranteed by the deoptimization context. I think adding asserts that we are inside deoptimization context would be good. You have a point about nmethods becoming stale. In the world with the sweeper my understanding is that if we add a `is_alive` method to the list it will not be flushed and freed until after the next safepoint, which the context ensures does not happen until the list is processed. And in the world after the sweeper the nmethods are just stable if no safepoint occurs. Because they would be unlinked in an earlier phase so we do not see them while iterating the code cache, and when walking dependency contexts it only returns not unloading nmethods. Maybe this deoptimization interface should just explicitly not add not alive, or unloading methods. Or just assert it and leave it up to the users of the interface. I think that invariant is upheld today. But I will investigate. Maybe some of the whitebox APIs. Erik will be back next week so I will discuss this with him. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From aboldtch at openjdk.org Fri Aug 19 10:25:49 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 19 Aug 2022 10:25:49 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: References: Message-ID: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Add context active assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9655/files - new: https://git.openjdk.org/jdk/pull/9655/files/4b95396c..ab144688 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=05-06 Stats: 10 lines in 3 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From shade at openjdk.org Fri Aug 19 13:30:40 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 19 Aug 2022 13:30:40 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory In-Reply-To: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken wrote: > There seems to be a case where utf_util.c getWideString might leak memory in an early return. As `UTF_ERROR` aborts the VM, this is not the "actual" memory leak :) ------------- PR: https://git.openjdk.org/jdk/pull/9918 From iklam at openjdk.org Fri Aug 19 17:25:41 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 17:25:41 GMT Subject: RFR: 8292267: Clean up synchronizer.hpp [v3] In-Reply-To: <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com> Message-ID: On Fri, 12 Aug 2022 13:20:32 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into 8292267-clean-up-synchronizer-hpp >> - @dcubed-ojdk review comments - reorder class forward declarations >> - added back inlined functions in case their performance matters >> - fixed copyright >> - 8292267: Clean up synchronizer.hpp > > Very nice. Thanks @coleenp @dholmes-ora @dcubed-ojdk for the review. Tiers 1,2 and build-tier5 passed on top of #9927 ------------- PR: https://git.openjdk.org/jdk/pull/9849 From iklam at openjdk.org Fri Aug 19 17:29:38 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Aug 2022 17:29:38 GMT Subject: Integrated: 8292267: Clean up synchronizer.hpp In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com> Message-ID: On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam wrote: > Fix two problems with synchronizer.hpp: > > - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration! > - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp. > > These headers are included much less after this PR (out of ~1000 hotspot .o files) > > > linkedlist.hpp 857 -> 101 > synchronizer.hpp 848 -> 122 > resourceHash.hpp 850 -> 270 This pull request has now been integrated. Changeset: 7244dd6f Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/7244dd6fab0c516ed76af594593b8378512620c8 Stats: 54 lines in 21 files changed: 28 ins; 21 del; 5 mod 8292267: Clean up synchronizer.hpp Reviewed-by: coleenp, dcubed, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9849 From hseigel at openjdk.org Fri Aug 19 19:26:20 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 19 Aug 2022 19:26:20 GMT Subject: RFR: 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags Message-ID: Please review this fix to obsolete two container JVM flags related to using CPU shares to compute active processor count within containers. This fix obsoletes the flags and removes the use of CPU shares from the calculations. The fix was tested by running the container tests on Linux x64 and Linux aarch64 using Mach5 Thanks, Harold ------------- Commit messages: - 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags Changes: https://git.openjdk.org/jdk/pull/9948/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9948&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282684 Stats: 117 lines in 4 files changed: 0 ins; 105 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9948.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9948/head:pull/9948 PR: https://git.openjdk.org/jdk/pull/9948 From dcubed at openjdk.org Fri Aug 19 19:58:28 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 19 Aug 2022 19:58:28 GMT Subject: RFR: 8292261: adjust timeouts in JLI GetObjectSizeIntrinsicsTest.java In-Reply-To: <4mLOF33JCf-dylPUyy7SeZeFYmIOKcvQz9LKzCFAlJ4=.3a3703b5-3216-49a0-b2dc-de2ebe7f6b2c@github.com> References: <4mLOF33JCf-dylPUyy7SeZeFYmIOKcvQz9LKzCFAlJ4=.3a3703b5-3216-49a0-b2dc-de2ebe7f6b2c@github.com> Message-ID: <8eO4p5nIGZWbbrHA91c3SEMIGJ4GOj9HnG8KaGhJpGc=.088de5d8-19f5-44eb-a8cd-8057818c1cca@github.com> On Tue, 16 Aug 2022 17:41:15 GMT, Chris Plummer wrote: >> A trivial fix to adjust the timeouts for two of the sub-tests in JLI GetObjectSizeIntrinsicsTest.java. >> >> This fix is being tested in my jdk-20+10 stress testing. > > Changes are trivial. @plummercj - Thanks for the review and for agreeing that the changes are trivial. ------------- PR: https://git.openjdk.org/jdk/pull/9846 From amenkov at openjdk.org Fri Aug 19 23:18:40 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 19 Aug 2022 23:18:40 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v2] In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 16:45:54 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix minor typo in output. test/jdk/com/sun/jdi/CLETest.java line 137: > 135: String method; > 136: String signature; > 137: int lineNumber; Should be final test/jdk/com/sun/jdi/CLETest.java line 161: > 159: try { > 160: List frames = thread.frames(); > 161: Iterator iter = frames.iterator(); List, Iterator and type cast is not needed2 lines below test/jdk/com/sun/jdi/CLETest.java line 231: > 229: testcaseFailed = false; > 230: } > 231: } break missed test/jdk/com/sun/jdi/CLETest.java line 237: > 235: testcaseFailed = false; > 236: } > 237: } break missed test/jdk/com/sun/jdi/CLETest.java line 243: > 241: testcaseFailed = false; > 242: } > 243: } break missed test/jdk/com/sun/jdi/CLETest.java line 249: > 247: testcaseFailed = false; > 248: } > 249: } break missed test/jdk/com/sun/jdi/CLETest.java line 409: > 407: // Setup all breakpoints > 408: for (MethodBreakpointData bpData : breakpoints) { > 409: Location loc = findMethodLocation(targetClass, bpData.method, Specify breakpoints by line number in a method is better than just line number, but did you think about mark them with some tag and parse source file to get line numbers? (like in test/jdk/com/sun/jdi/lib/jdb/JdbTest.java, parseBreakpoints method) ------------- PR: https://git.openjdk.org/jdk/pull/9840 From amenkov at openjdk.org Fri Aug 19 23:21:31 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 19 Aug 2022 23:21:31 GMT Subject: RFR: 8292350: Use static methods for hashCode/toString primitives In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov wrote: > It's a bit shorter and clearer. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9816 From amenkov at openjdk.org Fri Aug 19 23:31:36 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 19 Aug 2022 23:31:36 GMT Subject: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" [v2] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls wrote: >> This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. >> Attempting more heuristics to sense these unrelated changes just means we skip more pools. >> >> The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). >> >> There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. >> >> Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). >> >> >> Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: >> >> ----------System.out:(15/796)---------- >> ... >> 5 pool G1 Old Gen of type: Heap memory >> used value is 1024000 max is 1038090240 isExceeded = false >> peak used value is 1024000 >> threshold set to 1024001 >> threshold count 0 >> reset peak usage. peak usage = 1024000 isExceeded = false >> Allocated heap. isExceeded = true >> used value is 106930176 max is 1038090240 isExceeded = true >> peak used value is 106930176 peak max is 1038090240 >> threshold count 1 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove fetching and logging of peak max usage. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9842 From jpai at openjdk.org Sat Aug 20 02:02:30 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 20 Aug 2022 02:02:30 GMT Subject: RFR: 8292350: Use static methods for hashCode/toString primitives In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov wrote: > It's a bit shorter and clearer. Looks fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9816 From aturbanov at openjdk.org Sat Aug 20 10:08:52 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 20 Aug 2022 10:08:52 GMT Subject: Integrated: 8292350: Use static methods for hashCode/toString primitives In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov wrote: > It's a bit shorter and clearer. This pull request has now been integrated. Changeset: 37c0a136 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/37c0a13647e74fd02823a3f621e986f96904b933 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod 8292350: Use static methods for hashCode/toString primitives Reviewed-by: prr, rriggs, amenkov, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9816 From kevinw at openjdk.org Sat Aug 20 14:23:09 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 20 Aug 2022 14:23:09 GMT Subject: Integrated: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 18:27:12 GMT, Kevin Walls wrote: > This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. > Attempting more heuristics to sense these unrelated changes just means we skip more pools. > > The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). > > There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. > > Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). > > > Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: > > ----------System.out:(15/796)---------- > ... > 5 pool G1 Old Gen of type: Heap memory > used value is 1024000 max is 1038090240 isExceeded = false > peak used value is 1024000 > threshold set to 1024001 > threshold count 0 > reset peak usage. peak usage = 1024000 isExceeded = false > Allocated heap. isExceeded = true > used value is 106930176 max is 1038090240 isExceeded = true > peak used value is 106930176 peak max is 1038090240 > threshold count 1 This pull request has now been integrated. Changeset: 3601e30d Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/3601e30df794db122d8d04fb3c04868ccbaa0baf Stats: 19 lines in 1 file changed: 4 ins; 8 del; 7 mod 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" Reviewed-by: cjplummer, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9842 From kevinw at openjdk.org Sat Aug 20 14:21:02 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 20 Aug 2022 14:21:02 GMT Subject: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" [v2] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls wrote: >> This is test unstable when monitoring CodeHeap pools as they can change outside the test's control. >> Attempting more heuristics to sense these unrelated changes just means we skip more pools. >> >> The test design, making a Java allocation to affect a memory pool, shows it was intended for Java heap pools, so the test should focus on them. If we make a larger allocation during the test we actually can observe a change in size in the old gen pools it monitors (new gen pools are not expected to have thresholds, so they are skipped). >> >> There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which are intended for non-heap pools, so we should skip them intentionally here in isUsageThresholdExceeded. >> >> Other edits in the test to fix that the peak usage reported by the test was simply usage, not peak. Fetch the usage and peak usage as near together as possible in the test. At line 110 in the test, remove an attempt to skip pools we can't monitor (which was working, but does not cover all cases). >> >> >> Example test log, showing allocation that hits the old gen and triggers the threshold set by the test: >> >> ----------System.out:(15/796)---------- >> ... >> 5 pool G1 Old Gen of type: Heap memory >> used value is 1024000 max is 1038090240 isExceeded = false >> peak used value is 1024000 >> threshold set to 1024001 >> threshold count 0 >> reset peak usage. peak usage = 1024000 isExceeded = false >> Allocated heap. isExceeded = true >> used value is 106930176 max is 1038090240 isExceeded = true >> peak used value is 106930176 peak max is 1038090240 >> threshold count 1 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove fetching and logging of peak max usage. thanks Alex! ------------- PR: https://git.openjdk.org/jdk/pull/9842 From dholmes at openjdk.org Sun Aug 21 02:41:27 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 21 Aug 2022 02:41:27 GMT Subject: RFR: 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel wrote: > Please review this fix to obsolete two container JVM flags related to using CPU shares to compute active processor count within containers. This fix obsoletes the flags and removes the use of CPU shares from the calculations. The fix was tested by running the container tests on Linux x64 and Linux aarch64 using Mach5 > > Thanks, Harold Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9948 From iklam at openjdk.org Mon Aug 22 05:38:20 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Aug 2022 05:38:20 GMT Subject: RFR: 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags In-Reply-To: References: Message-ID: <2xa6alby12RtnUgyfrQxWnEG4156DgrJzvVVwwg779M=.541e9c79-388f-4233-b2d8-fa706bba5218@github.com> On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel wrote: > Please review this fix to obsolete two container JVM flags related to using CPU shares to compute active processor count within containers. This fix obsoletes the flags and removes the use of CPU shares from the calculations. The fix was tested by running the container tests on Linux x64 and Linux aarch64 using Mach5 > > Thanks, Harold LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9948 From sgehwolf at openjdk.org Mon Aug 22 08:08:32 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 22 Aug 2022 08:08:32 GMT Subject: RFR: 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel wrote: > Please review this fix to obsolete two container JVM flags related to using CPU shares to compute active processor count within containers. This fix obsoletes the flags and removes the use of CPU shares from the calculations. The fix was tested by running the container tests on Linux x64 and Linux aarch64 using Mach5 > > Thanks, Harold OK. Question: With this patch `cpu_shares()` related code becomes more or less dead code (other than for diagnostics via `VM.info` jcmd and `-XshowSettings:system`). Is the plan to remove that code too? Without any testing, this would likely bit-rot. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.org/jdk/pull/9948 From hseigel at openjdk.org Mon Aug 22 14:39:07 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 22 Aug 2022 14:39:07 GMT Subject: RFR: 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel wrote: > Please review this fix to obsolete two container JVM flags related to using CPU shares to compute active processor count within containers. This fix obsoletes the flags and removes the use of CPU shares from the calculations. The fix was tested by running the container tests on Linux x64 and Linux aarch64 using Mach5 > > Thanks, Harold Thanks David, Ioi, and Severin for the reviews! I'll create an issue about removing cpu_shares(). ------------- PR: https://git.openjdk.org/jdk/pull/9948 From hseigel at openjdk.org Mon Aug 22 14:39:07 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Mon, 22 Aug 2022 14:39:07 GMT Subject: Integrated: 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel wrote: > Please review this fix to obsolete two container JVM flags related to using CPU shares to compute active processor count within containers. This fix obsoletes the flags and removes the use of CPU shares from the calculations. The fix was tested by running the container tests on Linux x64 and Linux aarch64 using Mach5 > > Thanks, Harold This pull request has now been integrated. Changeset: db772276 Author: Harold Seigel URL: https://git.openjdk.org/jdk/commit/db772276848f6ad2d4d13e892bcd0eb3123d030f Stats: 117 lines in 4 files changed: 0 ins; 105 del; 12 mod 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags Reviewed-by: dholmes, iklam, sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/9948 From dcubed at openjdk.org Mon Aug 22 19:32:54 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 22 Aug 2022 19:32:54 GMT Subject: Integrated: 8292261: adjust timeouts in JLI GetObjectSizeIntrinsicsTest.java In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 20:14:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to adjust the timeouts for two of the sub-tests in JLI GetObjectSizeIntrinsicsTest.java. > > This fix is being tested in my jdk-20+10 stress testing. This pull request has now been integrated. Changeset: 8a0c3e53 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/8a0c3e53d541395ac32d656ac64d20ca0b9a187c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8292261: adjust timeouts in JLI GetObjectSizeIntrinsicsTest.java Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/9846 From dcubed at openjdk.org Mon Aug 22 19:36:32 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 22 Aug 2022 19:36:32 GMT Subject: Integrated: 8292262: adjust timeouts in several M&M tests In-Reply-To: References: Message-ID: <-fFQHKwyaYq2C49OBjNsRgG-hHdWe1WFYw1SBKa1Y1Q=.79ec9ed2-62d2-4e47-92c7-5d9ce339ecfd@github.com> On Thu, 11 Aug 2022 20:15:14 GMT, Daniel D. Daugherty wrote: > Trivial fixes to adjust timeouts in several M&M tests. > > This fix is being tested in my jdk-20+10 stress testing. This pull request has now been integrated. Changeset: f58aaab4 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/f58aaab4a40f09be03d77a8df8dfefa94e47b320 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod 8292262: adjust timeouts in several M&M tests Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/9847 From dcubed at openjdk.org Mon Aug 22 19:50:44 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 22 Aug 2022 19:50:44 GMT Subject: RFR: 8292261: adjust timeouts in JLI GetObjectSizeIntrinsicsTest.java In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 20:14:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to adjust the timeouts for two of the sub-tests in JLI GetObjectSizeIntrinsicsTest.java. > > This fix is being tested in my jdk-20+10 stress testing. java/lang/instrument/GetObjectSizeIntrinsicsTest.java passed 18 times in a Mach5 Tier3 job set. ------------- PR: https://git.openjdk.org/jdk/pull/9846 From dcubed at openjdk.org Mon Aug 22 19:52:29 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 22 Aug 2022 19:52:29 GMT Subject: RFR: 8292262: adjust timeouts in several M&M tests In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 20:15:14 GMT, Daniel D. Daugherty wrote: > Trivial fixes to adjust timeouts in several M&M tests. > > This fix is being tested in my jdk-20+10 stress testing. The 4 M&M tests passed 16 times in Mach5 Tier5 (4 tests x 4 configs). ------------- PR: https://git.openjdk.org/jdk/pull/9847 From duke at openjdk.org Mon Aug 22 23:00:07 2022 From: duke at openjdk.org (Bill Huang) Date: Mon, 22 Aug 2022 23:00:07 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version Message-ID: This task convert 3 shell tests below to java version. test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh ------------- Commit messages: - Coverted RmiBootstrapTest, RmiSslBootstrapTest and RmiSslNoKeyStoreTest to java version Changes: https://git.openjdk.org/jdk/pull/9973/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9973&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292067 Stats: 1607 lines in 9 files changed: 641 ins; 604 del; 362 mod Patch: https://git.openjdk.org/jdk/pull/9973.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9973/head:pull/9973 PR: https://git.openjdk.org/jdk/pull/9973 From mbaesken at openjdk.org Tue Aug 23 12:55:25 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 23 Aug 2022 12:55:25 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory In-Reply-To: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken wrote: > There seems to be a case where utf_util.c getWideString might leak memory in an early return. In case of failing getWideString, we have already a fallback in place that is just copying bytes : wstr = getWideString(CP_UTF8, (char*)utf8, len, &wlen); if ( wstr == NULL ) { // Can't allocate WIDE string goto just_copy_bytes; } So in these cases it is probably not needed to abort the VM, because fallback code exists anyway. So should we add the free, and replace UTF_ERROR by something like UTF_WARNING (thats just prints the problem - message without abort) ? ------------- PR: https://git.openjdk.org/jdk/pull/9918 From mbaesken at openjdk.org Tue Aug 23 14:10:20 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 23 Aug 2022 14:10:20 GMT Subject: RFR: JDK-8292778: EncodingSupport_md.c convertUtf8ToPlatformString wrong placing of free Message-ID: There seems to be a case where EncodingSupport_md.c convertUtf8ToPlatformString might leak memory because of a wrong placing of free.. ------------- Commit messages: - JDK-8292778 Changes: https://git.openjdk.org/jdk/pull/9981/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9981&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292778 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9981.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9981/head:pull/9981 PR: https://git.openjdk.org/jdk/pull/9981 From rriggs at openjdk.org Tue Aug 23 14:25:12 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 23 Aug 2022 14:25:12 GMT Subject: RFR: JDK-8292778: EncodingSupport_md.c convertUtf8ToPlatformString wrong placing of free In-Reply-To: References: Message-ID: <3l6qAT71ntWNAxZPuhAkUxGrdWS7XETq_71fiVChw9g=.db560545-1c3d-4f33-9e0c-9f015ba97fbd@github.com> On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken wrote: > There seems to be a case where EncodingSupport_md.c convertUtf8ToPlatformString might leak memory because of a wrong placing of free.. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9981 From kevinw at openjdk.org Tue Aug 23 17:45:11 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 23 Aug 2022 17:45:11 GMT Subject: RFR: JDK-8292778: EncodingSupport_md.c convertUtf8ToPlatformString wrong placing of free In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken wrote: > There seems to be a case where EncodingSupport_md.c convertUtf8ToPlatformString might leak memory because of a wrong placing of free.. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9981 From amenkov at openjdk.org Tue Aug 23 18:24:32 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 23 Aug 2022 18:24:32 GMT Subject: RFR: JDK-8292778: EncodingSupport_md.c convertUtf8ToPlatformString wrong placing of free In-Reply-To: References: Message-ID: <6gfGLU228_S7J7hqrdwMmiZjtLA5jChCjZwwwQr9xyY=.5e98cab9-a590-4bdd-95c3-af1208ee0547@github.com> On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken wrote: > There seems to be a case where EncodingSupport_md.c convertUtf8ToPlatformString might leak memory because of a wrong placing of free.. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9981 From cjplummer at openjdk.org Wed Aug 24 05:08:40 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 24 Aug 2022 05:08:40 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v3] In-Reply-To: References: Message-ID: > We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). > > https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html > > And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Some minor fixes and improvements. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9840/files - new: https://git.openjdk.org/jdk/pull/9840/files/6bf3dd79..81c7cdca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=01-02 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9840.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9840/head:pull/9840 PR: https://git.openjdk.org/jdk/pull/9840 From cjplummer at openjdk.org Wed Aug 24 05:08:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 24 Aug 2022 05:08:46 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v2] In-Reply-To: References: Message-ID: <5U9Ck8L2VlAzmXM-yq25ILdiMI-TAQ_hxo17KkW1UBY=.3e61878b-2e8b-4e24-9177-fa7826c4e6fa@github.com> On Fri, 19 Aug 2022 22:41:00 GMT, Alex Menkov wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix minor typo in output. > > test/jdk/com/sun/jdi/CLETest.java line 137: > >> 135: String method; >> 136: String signature; >> 137: int lineNumber; > > Should be final ok > test/jdk/com/sun/jdi/CLETest.java line 231: > >> 229: testcaseFailed = false; >> 230: } >> 231: } > > break missed ok > test/jdk/com/sun/jdi/CLETest.java line 237: > >> 235: testcaseFailed = false; >> 236: } >> 237: } > > break missed ok > test/jdk/com/sun/jdi/CLETest.java line 243: > >> 241: testcaseFailed = false; >> 242: } >> 243: } > > break missed ok > test/jdk/com/sun/jdi/CLETest.java line 249: > >> 247: testcaseFailed = false; >> 248: } >> 249: } > > break missed ok > test/jdk/com/sun/jdi/CLETest.java line 409: > >> 407: // Setup all breakpoints >> 408: for (MethodBreakpointData bpData : breakpoints) { >> 409: Location loc = findMethodLocation(targetClass, bpData.method, > > Specify breakpoints by line number in a method is better than just line number, but did you think about mark them with some tag and parse source file to get line numbers? (like in test/jdk/com/sun/jdi/lib/jdb/JdbTest.java, parseBreakpoints method) It looks like the tests in com/sun/jdi are split between those that extend `JdbTest` and those that extend `TestScaffold`. I'm not too sure of the rationale for using one over the other, but I ended up with `TestScaffold` because of the test I initially used as a template (BreakpointTest.java). `parseBreakpoints()` is only supported by `JdbTest`, so I would need to convert the test to extend it instead. I have no idea how disruptive this might be to the test. I think the breakpoints I have are fairly safe from code movement and modifications. It would require edits within the methods with the breakpoints, all of which are very simple and well commented, and there really is no reason to ever edit them in the first place. Also there are 8 other tests that are sensitive to line numbers (search for THIS TEST IS LINE NUMBER SENSITIVE), and they are at much greater risk (adding or removing a line anywhere before the breakpoint will break the test). ------------- PR: https://git.openjdk.org/jdk/pull/9840 From mbaesken at openjdk.org Wed Aug 24 07:09:20 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 24 Aug 2022 07:09:20 GMT Subject: RFR: JDK-8292778: EncodingSupport_md.c convertUtf8ToPlatformString wrong placing of free In-Reply-To: References: Message-ID: <5weg4u1VQuKzp9i6cqSJLcS3Hf2rxjNcTot30X-xytY=.ea00954b-0147-425f-83db-9afe1bdd7708@github.com> On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken wrote: > There seems to be a case where EncodingSupport_md.c convertUtf8ToPlatformString might leak memory because of a wrong placing of free.. Thanks for the reviews ! ------------- PR: https://git.openjdk.org/jdk/pull/9981 From mbaesken at openjdk.org Wed Aug 24 07:09:20 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 24 Aug 2022 07:09:20 GMT Subject: Integrated: JDK-8292778: EncodingSupport_md.c convertUtf8ToPlatformString wrong placing of free In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken wrote: > There seems to be a case where EncodingSupport_md.c convertUtf8ToPlatformString might leak memory because of a wrong placing of free.. This pull request has now been integrated. Changeset: ad2e0c4d Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/ad2e0c4df045261c04b00bfa1faf5c21392edc58 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod 8292778: EncodingSupport_md.c convertUtf8ToPlatformString wrong placing of free Reviewed-by: rriggs, kevinw, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9981 From cjplummer at openjdk.org Wed Aug 24 19:07:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 24 Aug 2022 19:07:10 GMT Subject: RFR: 8292880: Improve debuggee logging for com/sun/jdi/ClassUnloadEventTest.java Message-ID: In order to help debug [JDK-8292879](https://bugs.openjdk.org/browse/JDK-8292879) failures, turn on class unload tracing in the debuggee and also have the debugger dump all the debuggee output. See the CR for example output. ------------- Commit messages: - Improve debuggee output. Changes: https://git.openjdk.org/jdk/pull/10004/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10004&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292880 Stats: 25 lines in 1 file changed: 22 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10004/head:pull/10004 PR: https://git.openjdk.org/jdk/pull/10004 From amenkov at openjdk.org Wed Aug 24 19:39:53 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 24 Aug 2022 19:39:53 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v3] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 05:08:40 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Some minor fixes and improvements. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9840 From amenkov at openjdk.org Wed Aug 24 19:39:54 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 24 Aug 2022 19:39:54 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v2] In-Reply-To: <5U9Ck8L2VlAzmXM-yq25ILdiMI-TAQ_hxo17KkW1UBY=.3e61878b-2e8b-4e24-9177-fa7826c4e6fa@github.com> References: <5U9Ck8L2VlAzmXM-yq25ILdiMI-TAQ_hxo17KkW1UBY=.3e61878b-2e8b-4e24-9177-fa7826c4e6fa@github.com> Message-ID: On Wed, 24 Aug 2022 05:03:43 GMT, Chris Plummer wrote: >> test/jdk/com/sun/jdi/CLETest.java line 409: >> >>> 407: // Setup all breakpoints >>> 408: for (MethodBreakpointData bpData : breakpoints) { >>> 409: Location loc = findMethodLocation(targetClass, bpData.method, >> >> Specify breakpoints by line number in a method is better than just line number, but did you think about mark them with some tag and parse source file to get line numbers? (like in test/jdk/com/sun/jdi/lib/jdb/JdbTest.java, parseBreakpoints method) > > It looks like the tests in com/sun/jdi are split between those that extend `JdbTest` and those that extend `TestScaffold`. I'm not too sure of the rationale for using one over the other, but I ended up with `TestScaffold` because of the test I initially used as a template (BreakpointTest.java). `parseBreakpoints()` is only supported by `JdbTest`, so I would need to convert the test to extend it instead. I have no idea how disruptive this might be to the test. > > I think the breakpoints I have are fairly safe from code movement and modifications. It would require edits within the methods with the breakpoints, all of which are very simple and well commented, and there really is no reason to ever edit them in the first place. Also there are 8 other tests that are sensitive to line numbers (search for THIS TEST IS LINE NUMBER SENSITIVE), and they are at much greater risk (adding or removing a line anywhere before the breakpoint will break the test). AFAIR JdbTest is a base class to test jdb functionality, I didn't mean to extend it. But breakpoint parsing code is quite simple, I thought about add similar method to TestScaffold instead of findMethodLocation. As I wrote your way with findMethodLocation is much better than just line numbers (used in "THIS TEST IS LINE NUMBER SENSITIVE" tests), I'm okay with it. ------------- PR: https://git.openjdk.org/jdk/pull/9840 From amenkov at openjdk.org Wed Aug 24 20:00:34 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 24 Aug 2022 20:00:34 GMT Subject: RFR: 8292880: Improve debuggee logging for com/sun/jdi/ClassUnloadEventTest.java In-Reply-To: References: Message-ID: <7y5EOBt873C0ZyAAvKQJkq39E8ir8SULO44CXZxkzx8=.52f8ed97-ad27-47d7-855e-cb4db7ae3ec1@github.com> On Wed, 24 Aug 2022 18:57:13 GMT, Chris Plummer wrote: > In order to help debug [JDK-8292879](https://bugs.openjdk.org/browse/JDK-8292879) failures, turn on class unload tracing in the debuggee and also have the debugger dump all the debuggee output. See the CR for example output. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10004 From cjplummer at openjdk.org Wed Aug 24 20:03:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 24 Aug 2022 20:03:48 GMT Subject: RFR: 8292880: Improve debuggee logging for com/sun/jdi/ClassUnloadEventTest.java [v2] In-Reply-To: References: Message-ID: > In order to help debug [JDK-8292879](https://bugs.openjdk.org/browse/JDK-8292879) failures, turn on class unload tracing in the debuggee and also have the debugger dump all the debuggee output. See the CR for example output. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Add GC logging. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10004/files - new: https://git.openjdk.org/jdk/pull/10004/files/0812d708..2553ecbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10004&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10004&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10004.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10004/head:pull/10004 PR: https://git.openjdk.org/jdk/pull/10004 From duke at openjdk.org Wed Aug 24 20:41:41 2022 From: duke at openjdk.org (duke) Date: Wed, 24 Aug 2022 20:41:41 GMT Subject: Withdrawn: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote: > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8831 From cjplummer at openjdk.org Thu Aug 25 00:20:26 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 00:20:26 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v2] In-Reply-To: References: <5U9Ck8L2VlAzmXM-yq25ILdiMI-TAQ_hxo17KkW1UBY=.3e61878b-2e8b-4e24-9177-fa7826c4e6fa@github.com> Message-ID: On Wed, 24 Aug 2022 19:37:11 GMT, Alex Menkov wrote: >> It looks like the tests in com/sun/jdi are split between those that extend `JdbTest` and those that extend `TestScaffold`. I'm not too sure of the rationale for using one over the other, but I ended up with `TestScaffold` because of the test I initially used as a template (BreakpointTest.java). `parseBreakpoints()` is only supported by `JdbTest`, so I would need to convert the test to extend it instead. I have no idea how disruptive this might be to the test. >> >> I think the breakpoints I have are fairly safe from code movement and modifications. It would require edits within the methods with the breakpoints, all of which are very simple and well commented, and there really is no reason to ever edit them in the first place. Also there are 8 other tests that are sensitive to line numbers (search for THIS TEST IS LINE NUMBER SENSITIVE), and they are at much greater risk (adding or removing a line anywhere before the breakpoint will break the test). > > AFAIR JdbTest is a base class to test jdb functionality, I didn't mean to extend it. But breakpoint parsing code is quite simple, I thought about add similar method to TestScaffold instead of findMethodLocation. > As I wrote your way with findMethodLocation is much better than just line numbers (used in "THIS TEST IS LINE NUMBER SENSITIVE" tests), I'm okay with it. Ok. Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/9840 From cjplummer at openjdk.org Thu Aug 25 03:39:42 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 03:39:42 GMT Subject: RFR: 8282410: Remove SA ProcDebugger support Message-ID: SA has the following source directory: src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc However, there are no references to any classes in this directory. There used to be a reference to ProcDebuggerLocal, but this reference was removed, along with the class, when solaris support was removed by [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224). There appears to be no other need for anything in this directory now, and I believe it can be safely removed. ------------- Commit messages: - Remove ProcDebugger support. Hasn't been needed since Solaris support was removed. Changes: https://git.openjdk.org/jdk/pull/10013/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10013&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282410 Stats: 1655 lines in 23 files changed: 0 ins; 1653 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10013.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10013/head:pull/10013 PR: https://git.openjdk.org/jdk/pull/10013 From kevinw at openjdk.org Thu Aug 25 08:54:34 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Aug 2022 08:54:34 GMT Subject: RFR: 8292880: Improve debuggee logging for com/sun/jdi/ClassUnloadEventTest.java [v2] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 20:03:48 GMT, Chris Plummer wrote: >> In order to help debug [JDK-8292879](https://bugs.openjdk.org/browse/JDK-8292879) failures, turn on class unload tracing in the debuggee and also have the debugger dump all the debuggee output. See the CR for example output. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Add GC logging. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/10004 From kevinw at openjdk.org Thu Aug 25 10:46:14 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Aug 2022 10:46:14 GMT Subject: RFR: 8282410: Remove SA ProcDebugger support In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer wrote: > SA has the following source directory: > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc > > However, there are no references to any classes in this directory. There used to be a reference to ProcDebuggerLocal, but this reference was removed, along with the class, when solaris support was removed by [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224). There appears to be no other need for anything in this directory now, and I believe it can be safely removed. A lot of files 8-) 3 files in riscv64 were surprising to me, as they are new, from: 8276799: Implementation of JEP 422: Linux/RISC-V Port But there are "non-proc" versions of the RISCV64 files, and I don't see any references to the /proc/ files that were added. e.g. sun/jvm/hotspot/debugger/linux/riscv64/LinuxRISCV64CFrame uses RISCV64ThreadContext, and LinuxCDebugger uses RISCV64ThreadContext. These might have been added due to honourably mirroring what other platforms had, although they aren't needed, so this looks good. ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/10013 From kevinw at openjdk.org Thu Aug 25 11:51:32 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Aug 2022 11:51:32 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v3] In-Reply-To: References: Message-ID: <_BV0F_eLC0wcpOz6SmpK6rR9Uk96B5yoSvyjNXvcuaU=.ac5959b4-7e5c-4293-b4d5-4b8fb8c667ad@github.com> On Wed, 24 Aug 2022 05:08:40 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Some minor fixes and improvements. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9840 From cjplummer at openjdk.org Thu Aug 25 14:35:41 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 14:35:41 GMT Subject: RFR: 8282410: Remove SA ProcDebugger support In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer wrote: > SA has the following source directory: > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc > > However, there are no references to any classes in this directory. There used to be a reference to ProcDebuggerLocal, but this reference was removed, along with the class, when solaris support was removed by [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224). There appears to be no other need for anything in this directory now, and I believe it can be safely removed. Yes, I think much of this was just copied when doing new ports, including RISCV64, AARCH64 and PPC64. ------------- PR: https://git.openjdk.org/jdk/pull/10013 From cjplummer at openjdk.org Thu Aug 25 15:15:38 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 15:15:38 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v4] In-Reply-To: References: Message-ID: > We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). > > https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html > > And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Assert that we are at the expected breakpoint. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9840/files - new: https://git.openjdk.org/jdk/pull/9840/files/81c7cdca..12941b77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=02-03 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9840.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9840/head:pull/9840 PR: https://git.openjdk.org/jdk/pull/9840 From kevinw at openjdk.org Thu Aug 25 15:43:40 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Aug 2022 15:43:40 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v4] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:15:38 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Assert that we are at the expected breakpoint. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9840 From amenkov at openjdk.org Thu Aug 25 18:48:07 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 25 Aug 2022 18:48:07 GMT Subject: RFR: 8282410: Remove SA ProcDebugger support In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer wrote: > SA has the following source directory: > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc > > However, there are no references to any classes in this directory. There used to be a reference to ProcDebuggerLocal, but this reference was removed, along with the class, when solaris support was removed by [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224). There appears to be no other need for anything in this directory now, and I believe it can be safely removed. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10013 From cjplummer at openjdk.org Thu Aug 25 19:14:22 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 19:14:22 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v4] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:15:38 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Assert that we are at the expected breakpoint. I had to undo the last change that checked if the breakpoint was the expected one. There were two issues. The first was that the breakpoints are not in order, so it always threw an exception on the first breakpoint. However, the test still passed. That was because of a pre-existing bug. I declared `testFailed` locally within the test class. The overrode the one declared in `TestScaffold`, and which gets set `false` if there is an exception thrown in the event handler. I got rid of the override, and then test started to properly fail due to the incorrect breakpoint checks, which I have now also removed. ------------- PR: https://git.openjdk.org/jdk/pull/9840 From cjplummer at openjdk.org Thu Aug 25 19:14:21 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 19:14:21 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v5] In-Reply-To: References: Message-ID: > We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). > > https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html > > And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Undo last change to validate breakpoints. Fix bug with setting testFailed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9840/files - new: https://git.openjdk.org/jdk/pull/9840/files/12941b77..7c37d83d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9840&range=03-04 Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9840.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9840/head:pull/9840 PR: https://git.openjdk.org/jdk/pull/9840 From kevinw at openjdk.org Thu Aug 25 21:13:05 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 25 Aug 2022 21:13:05 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v5] In-Reply-To: References: Message-ID: <6--cO39SqaueJNBTW1HzkEXkgeWQsCnGUjp0jKxgIZM=.216fc65f-fa81-4a13-878c-90b1bd5b58cf@github.com> On Thu, 25 Aug 2022 19:14:21 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Undo last change to validate breakpoints. Fix bug with setting testFailed. OK thanks, the extra breakpoint check might have been nice but maybe not worth it right now. ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/9840 From amenkov at openjdk.org Thu Aug 25 21:37:24 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 25 Aug 2022 21:37:24 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem Message-ID: The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) ------------- Commit messages: - one more tab - tabs - Fixed cached_class_file Changes: https://git.openjdk.org/jdk/pull/10032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7124710 Stats: 555 lines in 4 files changed: 539 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Thu Aug 25 21:46:54 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 25 Aug 2022 21:46:54 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v5] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 19:14:21 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Undo last change to validate breakpoints. Fix bug with setting testFailed. Still LGTM ------------- Marked as reviewed by amenkov (Reviewer). PR: https://git.openjdk.org/jdk/pull/9840 From cjplummer at openjdk.org Thu Aug 25 22:03:56 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 22:03:56 GMT Subject: RFR: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events [v5] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 19:14:21 GMT, Chris Plummer wrote: >> We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). >> >> https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html >> >> And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Undo last change to validate breakpoints. Fix bug with setting testFailed. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9840 From coleenp at openjdk.org Thu Aug 25 22:06:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 22:06:59 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> References: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> Message-ID: On Fri, 19 Aug 2022 10:25:49 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Add context active assert src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4157: > 4155: } > 4156: } > 4157: log_debug(redefine, class, nmethod)("Enqueued all nmethods for deopt"); This seems to do the opposite of encapsulating nmethod logic by exposing RedefineClasses to the interesting bits of CodeCache iteration. And details of deoptimization that redefine classes really has other things to worry about. I didn't realize you were doing this. I suppose it's better than a big #if JVMTI in codeCache.cpp. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From cjplummer at openjdk.org Thu Aug 25 22:08:05 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 22:08:05 GMT Subject: Integrated: 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 16:03:58 GMT, Chris Plummer wrote: > We currently have no tests for co-located MethodEntry, Step, and Breakpoint events. We should make sure they are being properly co-located as described in the JDI spec, and also do special test cases for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217). > > https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/event/EventSet.html > > And sorry in advance that the logic is a bit hard to follow in this test due to having multiple test cases, and dealing with the async nature of JDI testing. All I can say is that is used to be a lot worse before I did multiple passes to improve it. This pull request has now been integrated. Changeset: d83faeaf Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/d83faeaf9ab3584de6af23de16aad3738d179c86 Stats: 452 lines in 2 files changed: 452 ins; 0 del; 0 mod 8292250: Create test for co-located JDI MethodEntry, Step, and Breakpoint events Reviewed-by: amenkov, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/9840 From coleenp at openjdk.org Thu Aug 25 22:22:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Aug 2022 22:22:59 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: References: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> Message-ID: On Thu, 25 Aug 2022 22:04:47 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Add context active assert > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4157: > >> 4155: } >> 4156: } >> 4157: log_debug(redefine, class, nmethod)("Enqueued all nmethods for deopt"); > > This seems to do the opposite of encapsulating nmethod logic by exposing RedefineClasses to the interesting bits of CodeCache iteration. And details of deoptimization that redefine classes really has other things to worry about. I didn't realize you were doing this. I suppose it's better than a big #if JVMTI in codeCache.cpp. Maybe this is ok, but I want to look at it more. The reason these functions started out in codeCache is because they looked like other functions in codeCache. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From cjplummer at openjdk.org Thu Aug 25 22:30:06 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 22:30:06 GMT Subject: Integrated: 8282410: Remove SA ProcDebugger support In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer wrote: > SA has the following source directory: > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc > > However, there are no references to any classes in this directory. There used to be a reference to ProcDebuggerLocal, but this reference was removed, along with the class, when solaris support was removed by [JDK-8244224](https://bugs.openjdk.org/browse/JDK-8244224). There appears to be no other need for anything in this directory now, and I believe it can be safely removed. This pull request has now been integrated. Changeset: 55f5a83b Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/55f5a83b88d7259bf7965ff12abd8dff4f79315f Stats: 1655 lines in 23 files changed: 0 ins; 1653 del; 2 mod 8282410: Remove SA ProcDebugger support Reviewed-by: kevinw, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/10013 From cjplummer at openjdk.org Thu Aug 25 22:57:27 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Aug 2022 22:57:27 GMT Subject: Integrated: 8292880: Improve debuggee logging for com/sun/jdi/ClassUnloadEventTest.java In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 18:57:13 GMT, Chris Plummer wrote: > In order to help debug [JDK-8292879](https://bugs.openjdk.org/browse/JDK-8292879) failures, turn on class unload tracing in the debuggee and also have the debugger dump all the debuggee output. See the CR for example output. This pull request has now been integrated. Changeset: 3e187730 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/3e187730162965981a5e6d238935e46d1015708e Stats: 25 lines in 1 file changed: 22 ins; 0 del; 3 mod 8292880: Improve debuggee logging for com/sun/jdi/ClassUnloadEventTest.java Reviewed-by: amenkov, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/10004 From aboldtch at openjdk.org Fri Aug 26 08:41:34 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 26 Aug 2022 08:41:34 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v8] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Add asserts and comments - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Add context active assert - Cleanup comment - Add list optimization - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Rename deoptimize_done enum value - Add missing code from list revert - Initial draft new terminology - Make _context_active atomic - ... and 18 more: https://git.openjdk.org/jdk/compare/054c23f4...11d9dd24 ------------- Changes: https://git.openjdk.org/jdk/pull/9655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=07 Stats: 753 lines in 27 files changed: 351 ins; 282 del; 120 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From aboldtch at openjdk.org Fri Aug 26 09:28:07 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 26 Aug 2022 09:28:07 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: References: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> Message-ID: On Thu, 25 Aug 2022 22:20:43 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4157: >> >>> 4155: } >>> 4156: } >>> 4157: log_debug(redefine, class, nmethod)("Enqueued all nmethods for deopt"); >> >> This seems to do the opposite of encapsulating nmethod logic by exposing RedefineClasses to the interesting bits of CodeCache iteration. And details of deoptimization that redefine classes really has other things to worry about. I didn't realize you were doing this. I suppose it's better than a big #if JVMTI in codeCache.cpp. > > Maybe this is ok, but I want to look at it more. The reason these functions started out in codeCache is because they looked like other functions in codeCache. The encapsulation is about defining an API for deoptimization which can enforce invariants and be safer to use. ```C++ // A DeoptimizationContext provides an API for deoptimizing CompileMethods // The contract for using a DeoptimizationContext is as follows // The context is active from the DeoptimizationContext objects creating // until deoptimize() is called on the object. // While the context is active, // * no safepoint may be taken // * any interaction with the context object must be done under // the Compile_lock // * deoptimize() must be called // While the context is inactive // * only interaction with the DeoptimizationContext object may // calls to enqueued() and its destruction The idea with the API is that the logic of how compiled methods are selected is done in a context which wants to use the API, like class redefinition, class dependency changes, method handles, call site changes etc. The goal was to move all the deoptimization logic from the codeCache to deoptimization. The JTMTI code got moved to jvmtiRedefineClasses as it had separate JVMTI specific logic. Storing old methods, etc. But I think some of the code that got moved from codeCache to deoptimization should/could be moved to instanceKlass, method, dependencies etc. as well. The reason I only moved the JVMTI code is because it had side effects(separate from deoptimization). While all the other were only help functions which made dependency traversal easier. The only reason I feel reluctance about moving the JVMTI code to deoptimization is because it then must be old_compiled_method_table aware. But if you have some reason why it should be in deoptimization I would like to know. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From mbaesken at openjdk.org Fri Aug 26 12:04:57 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 Aug 2022 12:04:57 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory [v2] In-Reply-To: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: > There seems to be a case where utf_util.c getWideString might leak memory in an early return. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Introduce UTF_WARNING and use the fallback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9918/files - new: https://git.openjdk.org/jdk/pull/9918/files/ab7fb549..9331f320 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9918&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9918&range=00-01 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9918.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9918/head:pull/9918 PR: https://git.openjdk.org/jdk/pull/9918 From coleenp at openjdk.org Fri Aug 26 13:52:31 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Aug 2022 13:52:31 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable Message-ID: Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. Also tested with tier1-7. ------------- Commit messages: - Beef up the Test for statistics - 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/10043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292375 Stats: 285 lines in 9 files changed: 84 ins; 148 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From lucy at openjdk.org Fri Aug 26 13:56:13 2022 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 26 Aug 2022 13:56:13 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory [v2] In-Reply-To: References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: <9WSxalTKUe7L5hNTqGHMB57ja3Q2dMZVP3mUmZwMy2c=.0890a5cb-601f-45da-90da-ba4dc9fec21b@github.com> On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken wrote: >> There seems to be a case where utf_util.c getWideString might leak memory in an early return. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce UTF_WARNING and use the fallback Looks good to me. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.org/jdk/pull/9918 From coleenp at openjdk.org Fri Aug 26 14:14:55 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Aug 2022 14:14:55 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Cleanup things I just noticed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/20eeab38..1a817535 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Fri Aug 26 17:07:54 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Aug 2022 17:07:54 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: Message-ID: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: include mutexLocker.hpp for minimal build. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/1a817535..842b30ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From cjplummer at openjdk.org Fri Aug 26 18:35:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 26 Aug 2022 18:35:10 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory [v2] In-Reply-To: References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken wrote: >> There seems to be a case where utf_util.c getWideString might leak memory in an early return. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce UTF_WARNING and use the fallback I'm not so sure I agree with enabling this "copy bytes" fallback code that has seemingly never been exercised. Until we find a use case where a `MultiByteToWideChar` failure is not deemed to be a fatal error, I think we should keep the code as is. Note these are possible reasons for `MultiByteToWideChar` failing: ERROR_INSUFFICIENT_BUFFER. A supplied buffer size was not large enough, or it was incorrectly set to NULL. ERROR_INVALID_FLAGS. The values supplied for flags were not valid. ERROR_INVALID_PARAMETER. Any of the parameter values was invalid. ERROR_NO_UNICODE_TRANSLATION. Invalid Unicode was found in a string. Is there ever a reason we would not want to abort if one of these errors happened? ------------- PR: https://git.openjdk.org/jdk/pull/9918 From sspitsyn at openjdk.org Fri Aug 26 20:19:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Aug 2022 20:19:53 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals Message-ID: If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. ------------- Commit messages: - 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals Changes: https://git.openjdk.org/jdk/pull/10051/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10051&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292657 Stats: 41 lines in 6 files changed: 26 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10051.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10051/head:pull/10051 PR: https://git.openjdk.org/jdk/pull/10051 From coleenp at openjdk.org Fri Aug 26 20:25:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Aug 2022 20:25:59 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v7] In-Reply-To: References: <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com> Message-ID: On Fri, 26 Aug 2022 09:25:52 GMT, Axel Boldt-Christmas wrote: >> Maybe this is ok, but I want to look at it more. The reason these functions started out in codeCache is because they looked like other functions in codeCache. > > The encapsulation is about defining an API for deoptimization which can enforce invariants and be safer to use. > ```C++ > // A DeoptimizationContext provides an API for deoptimizing CompileMethods > // The contract for using a DeoptimizationContext is as follows > // The context is active from the DeoptimizationContext objects creating > // until deoptimize() is called on the object. > // While the context is active, > // * no safepoint may be taken > // * any interaction with the context object must be done under > // the Compile_lock > // * deoptimize() must be called > // While the context is inactive > // * only interaction with the DeoptimizationContext object may > // calls to enqueued() and its destruction > > The idea with the API is that the logic of how compiled methods are selected is done in a context which wants to use the API, like class redefinition, class dependency changes, method handles, call site changes etc. > The goal was to move all the deoptimization logic from the codeCache to deoptimization. The JTMTI code got moved to jvmtiRedefineClasses as it had separate JVMTI specific logic. Storing old methods, etc. But I think some of the code that got moved from codeCache to deoptimization should/could be moved to instanceKlass, method, dependencies etc. as well. > The reason I only moved the JVMTI code is because it had side effects(separate from deoptimization). While all the other were only help functions which made dependency traversal easier. > > The only reason I feel reluctance about moving the JVMTI code to deoptimization is because it then must be old_compiled_method_table aware. > > But if you have some reason why it should be in deoptimization I would like to know. Okay, I looked at the change to jvmtiRedefineClasses.cpp in context and I like where you moved it. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From cjplummer at openjdk.org Fri Aug 26 20:45:55 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 26 Aug 2022 20:45:55 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 20:13:28 GMT, Serguei Spitsyn wrote: > If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. > > The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. > It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. > > The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. > > The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. > > The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. > > The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/libGetSetLocalTest.cpp line 316: > 314: Values values1 = { NULL, NULL, 2, 3L, (jfloat)4.2F, (jdouble)5.500000047683716 }; > 315: // jthread cthread = at_event ? get_carrier_thread(jvmti, jni, get_current_thread(jvmti, jni)) > 316: // : get_carrier_thread(jvmti, jni, vthread); Is there a reason to keep this around? ------------- PR: https://git.openjdk.org/jdk/pull/10051 From sspitsyn at openjdk.org Fri Aug 26 21:31:01 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Aug 2022 21:31:01 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 20:42:01 GMT, Chris Plummer wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/libGetSetLocalTest.cpp line 316: > >> 314: Values values1 = { NULL, NULL, 2, 3L, (jfloat)4.2F, (jdouble)5.500000047683716 }; >> 315: // jthread cthread = at_event ? get_carrier_thread(jvmti, jni, get_current_thread(jvmti, jni)) >> 316: // : get_carrier_thread(jvmti, jni, vthread); > > Is there a reason to keep this around? You are right. Will remove this. ------------- PR: https://git.openjdk.org/jdk/pull/10051 From sspitsyn at openjdk.org Fri Aug 26 21:33:13 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Aug 2022 21:33:13 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: > If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. > > The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. > It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. > > The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. > > The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. > > The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. > > The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: remove unneeded commented lines in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10051/files - new: https://git.openjdk.org/jdk/pull/10051/files/56fcb6ea..7033bcb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10051&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10051&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10051.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10051/head:pull/10051 PR: https://git.openjdk.org/jdk/pull/10051 From duke at openjdk.org Fri Aug 26 21:47:12 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 26 Aug 2022 21:47:12 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 21:12:08 GMT, Bill Huang wrote: > This task converts 2 shell tests to java version. > test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh > test/java/lang/management/RuntimeMXBean/TestInputArgument.sh @lmesnik Could you please review this PR? ------------- PR: https://git.openjdk.org/jdk/pull/9848 From duke at openjdk.org Fri Aug 26 21:47:14 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 26 Aug 2022 21:47:14 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 22:51:50 GMT, Bill Huang wrote: > This task convert 3 shell tests below to java version. > test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh @lmesnik Could you please review this PR? ------------- PR: https://git.openjdk.org/jdk/pull/9973 From cjplummer at openjdk.org Sat Aug 27 00:30:51 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 27 Aug 2022 00:30:51 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded commented lines in test Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10051 From duke at openjdk.org Sat Aug 27 18:50:56 2022 From: duke at openjdk.org (Daniel Skantz) Date: Sat, 27 Aug 2022 18:50:56 GMT Subject: RFR: 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 Message-ID: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> Update MachineDescriptionTwosComplement.java comment to indicate that LP64 machines are no longer uncommon. ------------- Commit messages: - JDK-8283627 Changes: https://git.openjdk.org/jdk/pull/9967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9967&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283627 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9967.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9967/head:pull/9967 PR: https://git.openjdk.org/jdk/pull/9967 From alanb at openjdk.org Sat Aug 27 19:02:19 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 27 Aug 2022 19:02:19 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory [v2] In-Reply-To: References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken wrote: >> There seems to be a case where utf_util.c getWideString might leak memory in an early return. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce UTF_WARNING and use the fallback src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c line 339: > 337: *pwlen = wlen; > 338: if (wlen <= 0) { > 339: UTF_WARNING(("Can't get WIDE string length")); If you are changing this to a warning then it should probably be limited to the NO_UNICODE_TRANSLATION case, I think you still want to abort if it fails due to invalid flags or parameters or buffer issue as that would a JDK (or Windows) bug. ------------- PR: https://git.openjdk.org/jdk/pull/9918 From cjplummer at openjdk.org Sat Aug 27 22:28:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 27 Aug 2022 22:28:10 GMT Subject: RFR: 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 In-Reply-To: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> References: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> Message-ID: On Mon, 22 Aug 2022 15:06:31 GMT, Daniel Skantz wrote: > Update MachineDescriptionTwosComplement.java comment to indicate that LP64 machines are no longer uncommon. How about this one in MachineDescription.java: /** Indicates whether the underlying machine supports the LP64 data model (currently only SPARC/64). */ public boolean isLP64(); The comment is wrong regarding SPARC/64 (which we don't event support anymore). ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/9967 From cjplummer at openjdk.org Sun Aug 28 22:44:16 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sun, 28 Aug 2022 22:44:16 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory [v2] In-Reply-To: References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: <1OvsMD6wHNVsnsBALSFO8hHO9iOsUP32WJ4rT4FUhqM=.e9330040-1f8c-4a33-98a9-e66783827f19@github.com> On Sat, 27 Aug 2022 18:58:40 GMT, Alan Bateman wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce UTF_WARNING and use the fallback > > src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c line 339: > >> 337: *pwlen = wlen; >> 338: if (wlen <= 0) { >> 339: UTF_WARNING(("Can't get WIDE string length")); > > If you are changing this to a warning then it should probably be limited to the NO_UNICODE_TRANSLATION case, I think you still want to abort if it fails due to invalid flags or parameters or buffer issue as that would a JDK (or Windows) bug. If you are going to do that, then you should track down all uses of this code (direct and indirect) to see if this error is ever acceptable and is handled properly. It seems that if the unicode string is bad, we should be exiting. I see this code being used indirectly from setAgentPropertyValue(), which only seems to be used for sun.jdwp.listenerAddress. Do we want the raw unicode bytes to be used in this case if they cannot be converted? It's also used from printLastError(), which gets the unicode bytes from GetLastError(). Should't they always be valid? ------------- PR: https://git.openjdk.org/jdk/pull/9918 From dholmes at openjdk.org Mon Aug 29 00:36:12 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Aug 2022 00:36:12 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Fri, 26 Aug 2022 17:07:54 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > include mutexLocker.hpp for minimal build. Hi Coleen, Probably due to my lack of understanding of the existing code I found this conversion very hard to follow. A number of comments below. Thanks. src/hotspot/share/classfile/protectionDomainCache.cpp line 42: > 40: #include "utilities/resourceHash.hpp" > 41: > 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { Why are we now using `WeakHandle` everywhere? src/hotspot/share/classfile/protectionDomainCache.cpp line 43: > 41: > 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { > 43: return (unsigned int)(protection_domain.resolve()->identity_hash()); And if it is a `WeakHandle` can't `resolve` now return NULL? src/hotspot/share/classfile/protectionDomainCache.cpp line 50: > 48: } > 49: > 50: ResourceHashtable 160: // Purge any deleted entries outside of the SystemDictionary_lock. > 161: purge_deleted_entries(); > 162: int oops_removed = purge_entries_from_table(); Maybe add comment `int oops_removed = purge_entries_from_table(); // reacquires SD lock` otherwise it gives the false impression this is done lock-free. src/hotspot/share/classfile/protectionDomainCache.cpp line 168: > 166: } > 167: > 168: void ProtectionDomainCacheTable::print_on(outputStream* st) { It is a little disconcerting that `print_on` can no longer be a `const` function! src/hotspot/share/classfile/protectionDomainCache.cpp line 186: > 184: > 185: // The object_no_keepalive() call peeks at the phantomly reachable oop without > 186: // keeping it alive. This is okay to do in the VM thread state if it is not You don't call `object_no_keepalive()` any more src/hotspot/share/classfile/protectionDomainCache.cpp line 202: > 200: // Keep entry alive > 201: (void)wk->resolve(); > 202: return *wk; Can't this be factored out of the if-else as `wk` is always the right entry to resolve and return? ------------- PR: https://git.openjdk.org/jdk/pull/10043 From mbaesken at openjdk.org Mon Aug 29 07:15:58 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 29 Aug 2022 07:15:58 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory [v2] In-Reply-To: References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken wrote: >> There seems to be a case where utf_util.c getWideString might leak memory in an early return. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce UTF_WARNING and use the fallback Hi, if it is still considered better to always abort in the MultiByteToWideChar failure cases and not use the fallback code, that's fine with me too. ------------- PR: https://git.openjdk.org/jdk/pull/9918 From aboldtch at openjdk.org Mon Aug 29 08:35:58 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 29 Aug 2022 08:35:58 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v9] In-Reply-To: References: Message-ID: > The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: > ```C++ > class DeoptimizationMarkerClosure : StackObj { > public: > virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; > }; > > This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. > ```C++ > { > NoSafepointVerifier nsv; > assert_locked_or_safepoint(Compile_lock); > marker_closure.marker_do(MarkFn()); > anything_deoptimized = deoptimize_all_marked(); > } > if (anything_deoptimized) { > run_deoptimize_closure(); > } > > This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. > > The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. > > An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. > > Testing: Tier 1-5 > > _Update_ > --- > Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. > > Testing: Tier 1-7 > > _Update_ > --- >> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >> >> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >> >> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >> >> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. > > _Update_ > --- > Testing after 11d9dd2: Oracle platforms tier 1-5 Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Add asserts and comments - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Add context active assert - Cleanup comment - Add list optimization - Merge remote-tracking branch 'upstream/master' into JDK-8291237 - Rename deoptimize_done enum value - Add missing code from list revert - Initial draft new terminology - ... and 19 more: https://git.openjdk.org/jdk/compare/512fee1d...c35f5ed6 ------------- Changes: https://git.openjdk.org/jdk/pull/9655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9655&range=08 Stats: 753 lines in 27 files changed: 351 ins; 282 del; 120 mod Patch: https://git.openjdk.org/jdk/pull/9655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9655/head:pull/9655 PR: https://git.openjdk.org/jdk/pull/9655 From sspitsyn at openjdk.org Mon Aug 29 09:27:23 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 29 Aug 2022 09:27:23 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded commented lines in test Thank you for review, Chris! ------------- PR: https://git.openjdk.org/jdk/pull/10051 From alanb at openjdk.org Mon Aug 29 10:26:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 29 Aug 2022 10:26:58 GMT Subject: RFR: JDK-8292595: jdwp utf_util getWideString might leak memory [v2] In-Reply-To: <1OvsMD6wHNVsnsBALSFO8hHO9iOsUP32WJ4rT4FUhqM=.e9330040-1f8c-4a33-98a9-e66783827f19@github.com> References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> <1OvsMD6wHNVsnsBALSFO8hHO9iOsUP32WJ4rT4FUhqM=.e9330040-1f8c-4a33-98a9-e66783827f19@github.com> Message-ID: On Sun, 28 Aug 2022 22:42:14 GMT, Chris Plummer wrote: > If you are going to do that, then you should track down all uses of this code (direct and indirect) to see if this error is ever acceptable and is handled properly. It seems that if the unicode string is bad, we should be exiting. I see this code being used indirectly from setAgentPropertyValue(), which only seems to be used for sun.jdwp.listenerAddress. Do we want the raw unicode bytes to be used in this case if they cannot be converted? It's also used from printLastError(), which gets the unicode bytes from GetLastError(). Should't they always be valid? I agree it complicates things and it would require looking at all usages. My comment was just to say that if it is changed to emit a warning then it would only make sense to do so in limited cases (the NO_UNICODE_TRANSLATION mostly). It may be simpler to not change the code of course. ------------- PR: https://git.openjdk.org/jdk/pull/9918 From coleenp at openjdk.org Mon Aug 29 12:22:16 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Aug 2022 12:22:16 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Fri, 26 Aug 2022 17:07:54 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > include mutexLocker.hpp for minimal build. Thanks for reading through this. I was going to make a larger change, then changed my mind. This conversion is limited. It is able to take advantage of the ability to copy WeakHandle without side effects, so that we don't have to store ProtectionDomainCacheEntry into the pd_set linked list, which makes it nicer. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Mon Aug 29 12:22:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Aug 2022 12:22:22 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Mon, 29 Aug 2022 00:12:36 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> include mutexLocker.hpp for minimal build. > > src/hotspot/share/classfile/protectionDomainCache.cpp line 42: > >> 40: #include "utilities/resourceHash.hpp" >> 41: >> 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { > > Why are we now using `WeakHandle` everywhere? WeakHandle is the object we're storing as in the hashtable. It also turns out to be the key. > src/hotspot/share/classfile/protectionDomainCache.cpp line 43: > >> 41: >> 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { >> 43: return (unsigned int)(protection_domain.resolve()->identity_hash()); > > And if it is a `WeakHandle` can't `resolve` now return NULL? compute_hash() is always called on a live WeakHandle so will never return null. > src/hotspot/share/classfile/protectionDomainCache.cpp line 50: > >> 48: } >> 49: >> 50: ResourceHashtable > I am struggling to understand what the key and values types are in this hashtable ??? WeakHandle is the key and the value in this hashtable. We need to match the WeakHandle in the input by value (see equals function), but we also want to return the WeakHandle to store in to the pd_set list in the DictionaryEntry. > src/hotspot/share/classfile/protectionDomainCache.cpp line 162: > >> 160: // Purge any deleted entries outside of the SystemDictionary_lock. >> 161: purge_deleted_entries(); >> 162: int oops_removed = purge_entries_from_table(); > > Maybe add comment > > `int oops_removed = purge_entries_from_table(); // reacquires SD lock` > > otherwise it gives the false impression this is done lock-free. Ok. > src/hotspot/share/classfile/protectionDomainCache.cpp line 168: > >> 166: } >> 167: >> 168: void ProtectionDomainCacheTable::print_on(outputStream* st) { > > It is a little disconcerting that `print_on` can no longer be a `const` function! It's static, so it can't. > src/hotspot/share/classfile/protectionDomainCache.cpp line 186: > >> 184: >> 185: // The object_no_keepalive() call peeks at the phantomly reachable oop without >> 186: // keeping it alive. This is okay to do in the VM thread state if it is not > > You don't call `object_no_keepalive()` any more This one (not the one I removed), is called by dictionary.cpp - the pd_set is a linked list of ProtectionDomainEntry, where we don't keep the WeakHandle alive when looking at the value. > src/hotspot/share/classfile/protectionDomainCache.cpp line 202: > >> 200: // Keep entry alive >> 201: (void)wk->resolve(); >> 202: return *wk; > > Can't this be factored out of the if-else as `wk` is always the right entry to resolve and return? Yes, that works. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Mon Aug 29 12:24:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 29 Aug 2022 12:24:33 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: David's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/842b30ab..ac67b187 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=02-03 Stats: 9 lines in 1 file changed: 3 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From cjplummer at openjdk.org Mon Aug 29 19:04:35 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 29 Aug 2022 19:04:35 GMT Subject: RFR: 8293037: Remove DebuggerBase.writeBytes() and related code from SA Message-ID: DebuggerBase.writeBytes() is not needed. It is only called by a number of other "write" methods, such as writeJBoolean(), but these methods are never called, so they can be removed along with writeBytes(). Lastly, writeBytes() calls writeBytesToProcess() which has no other callers, so it too can be removed. All it currently does is throw an exception. I imagine there may have been some use for this "write" capability 20+ years ago on Solaris/x86, or maybe it was part of future plans that never panned out. In any case, it's all just baggage now that can be removed. ------------- Commit messages: - Get rid of writeBytes() and related code. Changes: https://git.openjdk.org/jdk/pull/10068/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10068&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293037 Stats: 118 lines in 7 files changed: 0 ins; 116 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10068.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10068/head:pull/10068 PR: https://git.openjdk.org/jdk/pull/10068 From cjplummer at openjdk.org Mon Aug 29 20:22:28 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 29 Aug 2022 20:22:28 GMT Subject: RFR: 8292995: improve the SA page cache Message-ID: The page caching support in SA is woefully dated. I think it has stayed the same for over 20 years when it was originally done for solarix-x86. This code has been replicated for every port. Currently all ports only have a 16mb cache. They use 4k pages and there are 4k of them. I think the 4k page size is fine. The following comment appears in all the ports: // ... This is a cache of 4096 4K pages, or 16 MB. The page // size must be adjusted to be the hardware's page size. // (FIXME: should pick this up from the debugger.) I disagree with this. Matching the possibly very large hardware page size (I think maybe they meant OS page size) would require the SA page cache to be very very large, using a lot of java heap space. It would also require a lot of unnecessary copying from the debuggee process's memory. There's no reason for the SA cache's page size to match the OS page size. However, 16mb seems very small. I tried 256mb and this gave about a 10% performance improvement in a heap dump, and is still fairly small, so I think it is a reasonable adjustment. Another comment you see in all the ports (copied from solaris-x86) is: // FIXME: re-test necessity of cache on Linux, where data // fetching is faster // Cache portion of the remote process's address space. // Fetching data over the socket connection to dbx is slow. // Might be faster if we were using a binary protocol to talk to // dbx, but would have to test. For now, this cache works best // if it covers the entire heap of the remote process. FIXME: at At least on linux the cache is definitely needed. I turned it off and a heap dump took 9x longer. Also I think covering the entire heap is overkill, and I doubt was ever being done given how small the cache is. So I think this comment can just be removed. ------------- Commit messages: - Do some tuning and cleanup of SA page cache. Changes: https://git.openjdk.org/jdk/pull/10069/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10069&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292995 Stats: 48 lines in 4 files changed: 0 ins; 40 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10069.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10069/head:pull/10069 PR: https://git.openjdk.org/jdk/pull/10069 From lmesnik at openjdk.org Mon Aug 29 22:00:14 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 29 Aug 2022 22:00:14 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 21:12:08 GMT, Bill Huang wrote: > This task converts 2 shell tests to java version. > test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh > test/java/lang/management/RuntimeMXBean/TestInputArgument.sh test/jdk/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java line 59: > 57: // The system load average may be changing due to other jobs running. > 58: // Allow some delta. > 59: private static double DELTA = 0.05; Not a part of your fix but could you make it final? test/jdk/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java line 69: > 67: } > 68: > 69: @Test(invocationCount = 5, timeOut = 300) I am not sure it is the correct replacement. Accordingly to TestNG doc the invocationCount = 5 means that TestNG calls the test 5 times. And test fails if any of the invocations fail while the bash script makes 5 attempts and passes if testcase passed in any of them. test/jdk/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java line 71: > 69: @Test(invocationCount = 5, timeOut = 300) > 70: void testSystemLoadAvg() throws Exception { > 71: if (!OS.contains("Win")) { Check /test/lib/jdk/test/lib/Platform.java, it contains "Platform.isWindows()" which could be used for this. ------------- PR: https://git.openjdk.org/jdk/pull/9848 From amenkov at openjdk.org Mon Aug 29 22:04:57 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 29 Aug 2022 22:04:57 GMT Subject: RFR: 8293037: Remove DebuggerBase.writeBytes() and related code from SA In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer wrote: > DebuggerBase.writeBytes() is not needed. It is only called by a number of other "write" methods, such as writeJBoolean(), but these methods are never called, so they can be removed along with writeBytes(). Lastly, writeBytes() calls writeBytesToProcess() which has no other callers, so it too can be removed. All it currently does is throw an exception. I imagine there may have been some use for this "write" capability 20+ years ago on Solaris/x86, or maybe it was part of future plans that never panned out. In any case, it's all just baggage now that can be removed. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10068 From duke at openjdk.org Mon Aug 29 22:46:05 2022 From: duke at openjdk.org (Bill Huang) Date: Mon, 29 Aug 2022 22:46:05 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version In-Reply-To: References: Message-ID: <_JEvlPcMihkyNEH0Ltc7We7rnVjVnZNTrHVy_6n8vM4=.46a89164-0822-4f1a-8b28-989c19a43d1a@github.com> On Mon, 29 Aug 2022 21:50:14 GMT, Leonid Mesnik wrote: >> This task converts 2 shell tests to java version. >> test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh >> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh > > test/jdk/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java line 69: > >> 67: } >> 68: >> 69: @Test(invocationCount = 5, timeOut = 300) > > I am not sure it is the correct replacement. Accordingly to TestNG doc the invocationCount = 5 means that TestNG calls the test 5 times. And test fails if any of the invocations fail while the bash script makes 5 attempts and passes if testcase passed in any of them. Good catch! I've missed the exit statement in the original shell script. ------------- PR: https://git.openjdk.org/jdk/pull/9848 From lmesnik at openjdk.org Mon Aug 29 23:15:11 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 29 Aug 2022 23:15:11 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 22:51:50 GMT, Bill Huang wrote: > This task convert 3 shell tests below to java version. > test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 33: > 31: import java.rmi.server.ExportException; > 32: > 33: import java.util.*; wildcards in import are not welcome, please avoid them not needed to replace existing, just don't introduce them test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 115: > 113: throws IOException { > 114: > 115: final Set names = server.queryNames(pattern, query); Since you change these lines, might add template parameters here? Set names = ... and simplify if it is possible. Not a request, just a proposal. test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 166: > 164: if (args.length == 0) { > 165: throw new IllegalArgumentException("Argument is required for this" + > 166: " test"); not needed to split lines test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 700: > 698: } > 699: } > 700: System.err.println( I think that the previous indentation was good enough. No need to change it. test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 716: > 714: throws InterruptedException, IOException { > 715: String errStr = null; > 716: errStr = testConfiguration(conf); Merge with errStr = null ? test/jdk/sun/management/jmxremote/bootstrap/RmiTestBase.java line 47: > 45: static final String TEST_SRC = "@TEST-SRC@"; > 46: > 47: static final boolean isWindows = System.getProperty("os.name").contains( Check Platform.java. test/jdk/sun/management/jmxremote/bootstrap/RmiTestBase.java line 112: > 110: > 111: static String getDefaultFileName(String basename) { > 112: final StringBuffer defaultFileName = Why don't just create final String = System.getProperty(.._) + SEP + .... + basename; or even make static final variable like defaultFileNamePrefix = ... and return defaultFileNamePrefix + basename; test/jdk/sun/management/jmxremote/bootstrap/RmiTestBase.java line 130: > 128: **/ > 129: static String getDefaultStoreName(String basename) { > 130: final StringBuffer defaultFileName = the same as previous test/jdk/sun/management/jmxremote/bootstrap/RmiTestBase.java line 162: > 160: Utils.replaceFilesString(propertyFiles, > 161: (s) -> s.replace(TEST_SRC, DEST) > 162: .replaceAll("[/\\\\]", "\\\\\\\\")); Could you please comment this replacement. ------------- PR: https://git.openjdk.org/jdk/pull/9973 From duke at openjdk.org Mon Aug 29 23:25:11 2022 From: duke at openjdk.org (Bill Huang) Date: Mon, 29 Aug 2022 23:25:11 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version [v2] In-Reply-To: References: Message-ID: > This task converts 2 shell tests to java version. > test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh > test/java/lang/management/RuntimeMXBean/TestInputArgument.sh Bill Huang has updated the pull request incrementally with two additional commits since the last revision: - Added a blank line between fields and methods. - Implemented review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9848/files - new: https://git.openjdk.org/jdk/pull/9848/files/41a45483..21e7ce84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9848&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9848&range=00-01 Stats: 47 lines in 1 file changed: 26 ins; 7 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9848.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9848/head:pull/9848 PR: https://git.openjdk.org/jdk/pull/9848 From duke at openjdk.org Mon Aug 29 23:39:10 2022 From: duke at openjdk.org (Bill Huang) Date: Mon, 29 Aug 2022 23:39:10 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version In-Reply-To: References: Message-ID: <10yedZhGkPqW3RjSV49MNMOaz_-VH2OelDjAgm2KQs4=.8836d0a7-0607-40a5-ade6-80f32dfd7252@github.com> On Mon, 29 Aug 2022 22:06:18 GMT, Leonid Mesnik wrote: >> This task convert 3 shell tests below to java version. >> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh >> test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh > > test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 33: > >> 31: import java.rmi.server.ExportException; >> 32: >> 33: import java.util.*; > > wildcards in import are not welcome, please avoid them > not needed to replace existing, just don't introduce them Good catch! I didn't introduce this intentionally. It was automatically rearranged by IntelliJ. I will find out a way to disable that feature. ------------- PR: https://git.openjdk.org/jdk/pull/9973 From lmesnik at openjdk.org Mon Aug 29 23:40:12 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 29 Aug 2022 23:40:12 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 23:25:11 GMT, Bill Huang wrote: >> This task converts 2 shell tests to java version. >> test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh >> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh > > Bill Huang has updated the pull request incrementally with two additional commits since the last revision: > > - Added a blank line between fields and methods. > - Implemented review comments. test/jdk/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java line 73: > 71: String.format("Run %d: TestSystemLoadAvg", i)); > 72: if (!Platform.isWindows()) { > 73: // On Linux or Solaris Sorry, if missed the first time. It is Linux or Mac, or better something like *mix. test/jdk/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java line 95: > 93: i)); > 94: if (i == MAX_RETRIES) > 95: { please move move brace to the prev line ------------- PR: https://git.openjdk.org/jdk/pull/9848 From duke at openjdk.org Tue Aug 30 01:00:15 2022 From: duke at openjdk.org (Bill Huang) Date: Tue, 30 Aug 2022 01:00:15 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 22:11:38 GMT, Leonid Mesnik wrote: >> This task convert 3 shell tests below to java version. >> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh >> test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh > > test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 115: > >> 113: throws IOException { >> 114: >> 115: final Set names = server.queryNames(pattern, query); > > Since you change these lines, might add template parameters here? > Set names = ... > and simplify if it is possible. > Not a request, just a proposal. Actually, I didn't make changes to these lines. They were done by the IDEA auto formatter. But I can simplify it and add template parameters. > test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 166: > >> 164: if (args.length == 0) { >> 165: throw new IllegalArgumentException("Argument is required for this" + >> 166: " test"); > > not needed to split lines The IDEA splits the lines for a line limit of 80 characters. ------------- PR: https://git.openjdk.org/jdk/pull/9973 From kevinw at openjdk.org Tue Aug 30 09:19:24 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Aug 2022 09:19:24 GMT Subject: RFR: 8293037: Remove DebuggerBase.writeBytes() and related code from SA In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer wrote: > DebuggerBase.writeBytes() is not needed. It is only called by a number of other "write" methods, such as writeJBoolean(), but these methods are never called, so they can be removed along with writeBytes(). Lastly, writeBytes() calls writeBytesToProcess() which has no other callers, so it too can be removed. All it currently does is throw an exception. I imagine there may have been some use for this "write" capability 20+ years ago on Solaris/x86, or maybe it was part of future plans that never panned out. In any case, it's all just baggage now that can be removed. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/10068 From kevinw at openjdk.org Tue Aug 30 10:04:11 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Aug 2022 10:04:11 GMT Subject: RFR: 8292995: improve the SA page cache In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer wrote: > The page caching support in SA is woefully dated. I think it has stayed the same for over 20 years when it was originally done for solarix-x86. This code has been replicated for every port. Currently all ports only have a 16mb cache. They use 4k pages and there are 4k of them. > > I think the 4k page size is fine. The following comment appears in all the ports: > > // ... This is a cache of 4096 4K pages, or 16 MB. The page > // size must be adjusted to be the hardware's page size. > // (FIXME: should pick this up from the debugger.) > > I disagree with this. Matching the possibly very large hardware page size (I think maybe they meant OS page size) would require the SA page cache to be very very large, using a lot of java heap space. It would also require a lot of unnecessary copying from the debuggee process's memory. There's no reason for the SA cache's page size to match the OS page size. > > However, 16mb seems very small. I tried 256mb and this gave about a 10% performance improvement in a heap dump, and is still fairly small, so I think it is a reasonable adjustment. > > Another comment you see in all the ports (copied from solaris-x86) is: > > // FIXME: re-test necessity of cache on Linux, where data > // fetching is faster > // Cache portion of the remote process's address space. > // Fetching data over the socket connection to dbx is slow. > // Might be faster if we were using a binary protocol to talk to > // dbx, but would have to test. For now, this cache works best > // if it covers the entire heap of the remote process. FIXME: at > > At least on linux the cache is definitely needed. I turned it off and a heap dump took 9x longer. Also I think covering the entire heap is overkill, and I doubt was ever being done given how small the cache is. So I think this comment can just be removed. Looks good. Interesting to see the old comments talking about when it would drive a dbx process and issue commands to inspect memory. (Based on that I was just checking WindbgDebuggerLocal as that's maybe confusingly named - just noting here that it doesn't drive the "WinDbg" tool exactly, it uses the Debugger Engine from dbgeng.dll (which is good).) ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/10069 From alanb at openjdk.org Tue Aug 30 11:44:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Aug 2022 11:44:11 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded commented lines in test Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10051 From cjplummer at openjdk.org Tue Aug 30 16:27:20 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 30 Aug 2022 16:27:20 GMT Subject: RFR: 8293037: Remove DebuggerBase.writeBytes() and related code from SA In-Reply-To: References: Message-ID: <_oekHMD4p6wJ60ieHGVuqsHJ5FCL9gZ-ZrlBO50jSKU=.bfa0454e-3b6a-4d38-b8fa-7686336b832e@github.com> On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer wrote: > DebuggerBase.writeBytes() is not needed. It is only called by a number of other "write" methods, such as writeJBoolean(), but these methods are never called, so they can be removed along with writeBytes(). Lastly, writeBytes() calls writeBytesToProcess() which has no other callers, so it too can be removed. All it currently does is throw an exception. I imagine there may have been some use for this "write" capability 20+ years ago on Solaris/x86, or maybe it was part of future plans that never panned out. In any case, it's all just baggage now that can be removed. Thanks Alex and Kevin! ------------- PR: https://git.openjdk.org/jdk/pull/10068 From cjplummer at openjdk.org Tue Aug 30 16:27:21 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 30 Aug 2022 16:27:21 GMT Subject: Integrated: 8293037: Remove DebuggerBase.writeBytes() and related code from SA In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer wrote: > DebuggerBase.writeBytes() is not needed. It is only called by a number of other "write" methods, such as writeJBoolean(), but these methods are never called, so they can be removed along with writeBytes(). Lastly, writeBytes() calls writeBytesToProcess() which has no other callers, so it too can be removed. All it currently does is throw an exception. I imagine there may have been some use for this "write" capability 20+ years ago on Solaris/x86, or maybe it was part of future plans that never panned out. In any case, it's all just baggage now that can be removed. This pull request has now been integrated. Changeset: f285cea9 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/f285cea9a6cbf7e46840eab74094e9588af4e147 Stats: 118 lines in 7 files changed: 0 ins; 116 del; 2 mod 8293037: Remove DebuggerBase.writeBytes() and related code from SA Reviewed-by: amenkov, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/10068 From sspitsyn at openjdk.org Tue Aug 30 16:45:49 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Aug 2022 16:45:49 GMT Subject: RFR: 8292995: improve the SA page cache In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer wrote: > The page caching support in SA is woefully dated. I think it has stayed the same for over 20 years when it was originally done for solarix-x86. This code has been replicated for every port. Currently all ports only have a 16mb cache. They use 4k pages and there are 4k of them. > > I think the 4k page size is fine. The following comment appears in all the ports: > > // ... This is a cache of 4096 4K pages, or 16 MB. The page > // size must be adjusted to be the hardware's page size. > // (FIXME: should pick this up from the debugger.) > > I disagree with this. Matching the possibly very large hardware page size (I think maybe they meant OS page size) would require the SA page cache to be very very large, using a lot of java heap space. It would also require a lot of unnecessary copying from the debuggee process's memory. There's no reason for the SA cache's page size to match the OS page size. > > However, 16mb seems very small. I tried 256mb and this gave about a 10% performance improvement in a heap dump, and is still fairly small, so I think it is a reasonable adjustment. > > Another comment you see in all the ports (copied from solaris-x86) is: > > // FIXME: re-test necessity of cache on Linux, where data > // fetching is faster > // Cache portion of the remote process's address space. > // Fetching data over the socket connection to dbx is slow. > // Might be faster if we were using a binary protocol to talk to > // dbx, but would have to test. For now, this cache works best > // if it covers the entire heap of the remote process. FIXME: at > > At least on linux the cache is definitely needed. I turned it off and a heap dump took 9x longer. Also I think covering the entire heap is overkill, and I doubt was ever being done given how small the cache is. So I think this comment can just be removed. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java line 123: > 121: > 122: if (useCache) { > 123: initCache(4096, parseCacheNumPagesProperty(1024 * 64)); Not a review. Just a minor comment. The indent does not match the above lines. As I see, the indent in the updated files is not unified. There is even indent 3. ------------- PR: https://git.openjdk.org/jdk/pull/10069 From sspitsyn at openjdk.org Tue Aug 30 16:47:14 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Aug 2022 16:47:14 GMT Subject: RFR: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn wrote: >> If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. >> >> The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. >> It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. >> >> The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. >> >> The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. >> >> The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. >> >> The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded commented lines in test Thank you for review, Alan! ------------- PR: https://git.openjdk.org/jdk/pull/10051 From iklam at openjdk.org Tue Aug 30 18:17:12 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 30 Aug 2022 18:17:12 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Mon, 29 Aug 2022 12:10:48 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/protectionDomainCache.cpp line 43: >> >>> 41: >>> 42: unsigned int ProtectionDomainCacheTable::compute_hash(const WeakHandle& protection_domain) { >>> 43: return (unsigned int)(protection_domain.resolve()->identity_hash()); >> >> And if it is a `WeakHandle` can't `resolve` now return NULL? > > compute_hash() is always called on a live WeakHandle so will never return null. I think you should add an assert that the `protection_domain.resolve()` never returns null, with a comment explaining why. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From duke at openjdk.org Tue Aug 30 18:17:28 2022 From: duke at openjdk.org (Bill Huang) Date: Tue, 30 Aug 2022 18:17:28 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version [v2] In-Reply-To: References: Message-ID: > This task convert 3 shell tests below to java version. > test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh Bill Huang has updated the pull request incrementally with two additional commits since the last revision: - Relax line-length limit restriction - Implemented review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9973/files - new: https://git.openjdk.org/jdk/pull/9973/files/11cfefdd..126bf292 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9973&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9973&range=00-01 Stats: 407 lines in 3 files changed: 33 ins; 206 del; 168 mod Patch: https://git.openjdk.org/jdk/pull/9973.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9973/head:pull/9973 PR: https://git.openjdk.org/jdk/pull/9973 From sspitsyn at openjdk.org Tue Aug 30 18:32:30 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Aug 2022 18:32:30 GMT Subject: Integrated: 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 20:13:28 GMT, Serguei Spitsyn wrote: > If JVM TI GetLocalXXX/SetLocalXXX is called from a virtual thread with the thread parameter set to NULL (meaning current thread) then it should get/set the value of the locals in the virtual thread frames. Instead, it reads the carrier thread locals and/or crashes. > > The fix is that the relevant checking of the jthread parameter for NULL and adjusting it to current thread is added. > It is done in new utility `function current_thread_obj_or_resolve_external_guard(jthread thread)`. For more convenient testing the same adjustment is done in the JVM TI extension function `GetCarrierThread()`. > > The test serviceability/jvmti/vthread/GetSetLocalTest is updated to add previously missed test coverage. > > The test serviceability/jvmti/vthread/VThreadTest has been updated to adopt to update behavior of the `GetCarrierThread`. > > The fix was verified with the test/hotspot/jtreg/serviceability/jvmti/vthread/ tests. > > The fix was also tested with the existing JVM TI and JDI tests to make sure no regressions are introduced. This pull request has now been integrated. Changeset: f5ebbf32 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/f5ebbf3225fc10367ef4e2b4ec62e9077565e6aa Stats: 39 lines in 6 files changed: 24 ins; 2 del; 13 mod 8292657: Calling GetLocalXXX from virtual thread with thread parameter set to NULL returns carrier locals Reviewed-by: cjplummer, alanb ------------- PR: https://git.openjdk.org/jdk/pull/10051 From coleenp at openjdk.org Tue Aug 30 19:31:00 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 19:31:00 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v5] In-Reply-To: References: Message-ID: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add comment about key,value. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/ac67b187..b549a473 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From iklam at openjdk.org Tue Aug 30 19:32:23 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 30 Aug 2022 19:32:23 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 12:24:33 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > David's comments Looks good overall and seems to be equivalent to the old code. Just a couple of nits. src/hotspot/share/classfile/protectionDomainCache.cpp line 162: > 160: // Purge any deleted entries outside of the SystemDictionary_lock. > 161: purge_deleted_entries(); > 162: int oops_removed = purge_entries_from_table(); // reacquires SD lock It's confusing to have two similarly named functions (purge_deleted_entries and purge_entries_from_table). Maybe the two functions should be combined into a single `purge()` function that performs the two steps? src/hotspot/share/classfile/protectionDomainCache.hpp line 35: > 33: // The amount of different protection domains used is typically magnitudes smaller > 34: // than the number of system dictionary entries (loaded classes). > 35: class ProtectionDomainCacheTable : public AllStatic { How about adding a comment to say what this table maps from/to? Something like: // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Tue Aug 30 20:18:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 20:18:40 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v6] In-Reply-To: References: Message-ID: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Ioi comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/b549a473..3634521f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=04-05 Stats: 56 lines in 2 files changed: 25 ins; 28 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Tue Aug 30 20:18:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 20:18:40 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v5] In-Reply-To: References: Message-ID: <70cl_bIxCFd16WL9j-O__wWS6MHJQuVR8fwe7vVDptY=.a8cbb465-095f-4170-b4fb-e26f502e33a6@github.com> On Tue, 30 Aug 2022 19:31:00 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about key,value. Thank you for reviewing, Ioi. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Tue Aug 30 20:18:41 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 Aug 2022 20:18:41 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 18:20:26 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> David's comments > > src/hotspot/share/classfile/protectionDomainCache.cpp line 162: > >> 160: // Purge any deleted entries outside of the SystemDictionary_lock. >> 161: purge_deleted_entries(); >> 162: int oops_removed = purge_entries_from_table(); // reacquires SD lock > > It's confusing to have two similarly named functions (purge_deleted_entries and purge_entries_from_table). Maybe the two functions should be combined into a single `purge()` function that performs the two steps? I'll put purge_entries_from_table back in the mainline of this function where it used to be. I'd separated it because it was long. purge_deleted_entries should be its own function because it goes to a safepoint so it's special. > src/hotspot/share/classfile/protectionDomainCache.hpp line 35: > >> 33: // The amount of different protection domains used is typically magnitudes smaller >> 34: // than the number of system dictionary entries (loaded classes). >> 35: class ProtectionDomainCacheTable : public AllStatic { > > How about adding a comment to say what this table maps from/to? Something like: > > // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are > // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. Okay, I added your comment. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From sspitsyn at openjdk.org Tue Aug 30 21:27:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 30 Aug 2022 21:27:22 GMT Subject: RFR: 8292995: improve the SA page cache In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer wrote: > The page caching support in SA is woefully dated. I think it has stayed the same for over 20 years when it was originally done for solarix-x86. This code has been replicated for every port. Currently all ports only have a 16mb cache. They use 4k pages and there are 4k of them. > > I think the 4k page size is fine. The following comment appears in all the ports: > > // ... This is a cache of 4096 4K pages, or 16 MB. The page > // size must be adjusted to be the hardware's page size. > // (FIXME: should pick this up from the debugger.) > > I disagree with this. Matching the possibly very large hardware page size (I think maybe they meant OS page size) would require the SA page cache to be very very large, using a lot of java heap space. It would also require a lot of unnecessary copying from the debuggee process's memory. There's no reason for the SA cache's page size to match the OS page size. > > However, 16mb seems very small. I tried 256mb and this gave about a 10% performance improvement in a heap dump, and is still fairly small, so I think it is a reasonable adjustment. > > Another comment you see in all the ports (copied from solaris-x86) is: > > // FIXME: re-test necessity of cache on Linux, where data > // fetching is faster > // Cache portion of the remote process's address space. > // Fetching data over the socket connection to dbx is slow. > // Might be faster if we were using a binary protocol to talk to > // dbx, but would have to test. For now, this cache works best > // if it covers the entire heap of the remote process. FIXME: at > > At least on linux the cache is definitely needed. I turned it off and a heap dump took 9x longer. Also I think covering the entire heap is overkill, and I doubt was ever being done given how small the cache is. So I think this comment can just be removed. Nice simplification. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10069 From lmesnik at openjdk.org Tue Aug 30 22:05:18 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 30 Aug 2022 22:05:18 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version [v2] In-Reply-To: References: Message-ID: <-zD4cslKX5ax8Fy3zluU6-Frh0pWfON8aiKesIA3JXA=.09d79b29-6c5c-4841-96d0-0cfec72b3975@github.com> On Tue, 30 Aug 2022 18:17:28 GMT, Bill Huang wrote: >> This task convert 3 shell tests below to java version. >> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh >> test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh > > Bill Huang has updated the pull request incrementally with two additional commits since the last revision: > > - Relax line-length limit restriction > - Implemented review comments. Marked as reviewed by lmesnik (Reviewer). test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java line 206: > 204: } > 205: FileInputStream fin = new FileInputStream(passwordFileName); > 206: try { You could use try with resources. test/jdk/sun/management/jmxremote/bootstrap/RmiTestBase.java line 172: > 170: } else { > 171: if (!thisEntry.principal().getName().contains("NULL SID") && > 172: thisEntry.type() != AclEntryType.ALLOW) { I think the previous indentation was correct. We put "&&", "+" and "." in the beginning of next line usually. ------------- PR: https://git.openjdk.org/jdk/pull/9973 From lmesnik at openjdk.org Tue Aug 30 22:23:23 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 30 Aug 2022 22:23:23 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version [v2] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 23:25:11 GMT, Bill Huang wrote: >> This task converts 2 shell tests to java version. >> test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh >> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh > > Bill Huang has updated the pull request incrementally with two additional commits since the last revision: > > - Added a blank line between fields and methods. > - Implemented review comments. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9848 From duke at openjdk.org Tue Aug 30 22:39:06 2022 From: duke at openjdk.org (Bill Huang) Date: Tue, 30 Aug 2022 22:39:06 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version [v3] In-Reply-To: References: Message-ID: > This task converts 2 shell tests to java version. > test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh > test/java/lang/management/RuntimeMXBean/TestInputArgument.sh Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Implemented more review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9848/files - new: https://git.openjdk.org/jdk/pull/9848/files/21e7ce84..9ae1663d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9848&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9848&range=01-02 Stats: 19 lines in 1 file changed: 2 ins; 8 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9848.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9848/head:pull/9848 PR: https://git.openjdk.org/jdk/pull/9848 From duke at openjdk.org Tue Aug 30 22:39:15 2022 From: duke at openjdk.org (Bill Huang) Date: Tue, 30 Aug 2022 22:39:15 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version [v3] In-Reply-To: References: Message-ID: > This task convert 3 shell tests below to java version. > test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Implemented more review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9973/files - new: https://git.openjdk.org/jdk/pull/9973/files/126bf292..5e74c170 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9973&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9973&range=01-02 Stats: 8 lines in 2 files changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9973.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9973/head:pull/9973 PR: https://git.openjdk.org/jdk/pull/9973 From cjplummer at openjdk.org Tue Aug 30 23:02:02 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 30 Aug 2022 23:02:02 GMT Subject: RFR: 8292995: improve the SA page cache [v2] In-Reply-To: References: Message-ID: > The page caching support in SA is woefully dated. I think it has stayed the same for over 20 years when it was originally done for solarix-x86. This code has been replicated for every port. Currently all ports only have a 16mb cache. They use 4k pages and there are 4k of them. > > I think the 4k page size is fine. The following comment appears in all the ports: > > // ... This is a cache of 4096 4K pages, or 16 MB. The page > // size must be adjusted to be the hardware's page size. > // (FIXME: should pick this up from the debugger.) > > I disagree with this. Matching the possibly very large hardware page size (I think maybe they meant OS page size) would require the SA page cache to be very very large, using a lot of java heap space. It would also require a lot of unnecessary copying from the debuggee process's memory. There's no reason for the SA cache's page size to match the OS page size. > > However, 16mb seems very small. I tried 256mb and this gave about a 10% performance improvement in a heap dump, and is still fairly small, so I think it is a reasonable adjustment. > > Another comment you see in all the ports (copied from solaris-x86) is: > > // FIXME: re-test necessity of cache on Linux, where data > // fetching is faster > // Cache portion of the remote process's address space. > // Fetching data over the socket connection to dbx is slow. > // Might be faster if we were using a binary protocol to talk to > // dbx, but would have to test. For now, this cache works best > // if it covers the entire heap of the remote process. FIXME: at > > At least on linux the cache is definitely needed. I turned it off and a heap dump took 9x longer. Also I think covering the entire heap is overkill, and I doubt was ever being done given how small the cache is. So I think this comment can just be removed. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Minor indent fix. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10069/files - new: https://git.openjdk.org/jdk/pull/10069/files/9f528186..5b34d066 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10069&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10069&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10069.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10069/head:pull/10069 PR: https://git.openjdk.org/jdk/pull/10069 From cjplummer at openjdk.org Tue Aug 30 23:02:04 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 30 Aug 2022 23:02:04 GMT Subject: RFR: 8292995: improve the SA page cache In-Reply-To: References: Message-ID: <_qWP2tHLOf8toK1e-eZzGH5EgieTtXep07of8B0625I=.168f6885-5ade-4947-9301-405aa840e996@github.com> On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer wrote: > The page caching support in SA is woefully dated. I think it has stayed the same for over 20 years when it was originally done for solarix-x86. This code has been replicated for every port. Currently all ports only have a 16mb cache. They use 4k pages and there are 4k of them. > > I think the 4k page size is fine. The following comment appears in all the ports: > > // ... This is a cache of 4096 4K pages, or 16 MB. The page > // size must be adjusted to be the hardware's page size. > // (FIXME: should pick this up from the debugger.) > > I disagree with this. Matching the possibly very large hardware page size (I think maybe they meant OS page size) would require the SA page cache to be very very large, using a lot of java heap space. It would also require a lot of unnecessary copying from the debuggee process's memory. There's no reason for the SA cache's page size to match the OS page size. > > However, 16mb seems very small. I tried 256mb and this gave about a 10% performance improvement in a heap dump, and is still fairly small, so I think it is a reasonable adjustment. > > Another comment you see in all the ports (copied from solaris-x86) is: > > // FIXME: re-test necessity of cache on Linux, where data > // fetching is faster > // Cache portion of the remote process's address space. > // Fetching data over the socket connection to dbx is slow. > // Might be faster if we were using a binary protocol to talk to > // dbx, but would have to test. For now, this cache works best > // if it covers the entire heap of the remote process. FIXME: at > > At least on linux the cache is definitely needed. I turned it off and a heap dump took 9x longer. Also I think covering the entire heap is overkill, and I doubt was ever being done given how small the cache is. So I think this comment can just be removed. Thanks Kevin and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10069 From cjplummer at openjdk.org Tue Aug 30 23:17:33 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 30 Aug 2022 23:17:33 GMT Subject: RFR: 8175382: clhsdb pmap should print the end addresses of the load modules Message-ID: The clhsdb 'pmap' command prints the start addresses and the sizes of the various load modules. It would be more intuitive to have the end address printed as the VM.dynlibs jcmd does. Before: 0x00007f8839c38000 5920K /usr/lib64/libc-2.17.so 0x00007f883a006000 4072K /usr/lib64/libdl-2.17.so 0x00007f883a20a000 4056K /usr/lib64/libpthread-2.17.so 0x00007f883a426000 3944K /usr/lib64/libz.so.1.2.7 After: 0x7f0f8e482000-0x7f0f8ea00000 5624K /usr/lib64/libc-2.17.so 0x7f0f8e850000-0x7f0f8ec00000 3776K /usr/lib64/libdl-2.17.so 0x7f0f8ea54000-0x7f0f8ee00000 3760K /usr/lib64/libpthread-2.17.so 0x7f0f8ec70000-0x7f0f8f000000 3648K /usr/lib64/libz.so.1.2.7 Note that VM.dynlibs doesn't use the 0x prefix. I considered doing the same for pmap, but it did cause one test failure that was searching for the address starting with 0x, so I decided to leave it in. Notice I also dropped the leading 0's to keep things a big more compact (VM.dynlibs does the same). ------------- Commit messages: - Output map range rather than just start and length. Changes: https://git.openjdk.org/jdk/pull/10087/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10087&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8175382 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10087.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10087/head:pull/10087 PR: https://git.openjdk.org/jdk/pull/10087 From cjplummer at openjdk.org Tue Aug 30 23:18:14 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 30 Aug 2022 23:18:14 GMT Subject: Integrated: 8292995: improve the SA page cache In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer wrote: > The page caching support in SA is woefully dated. I think it has stayed the same for over 20 years when it was originally done for solarix-x86. This code has been replicated for every port. Currently all ports only have a 16mb cache. They use 4k pages and there are 4k of them. > > I think the 4k page size is fine. The following comment appears in all the ports: > > // ... This is a cache of 4096 4K pages, or 16 MB. The page > // size must be adjusted to be the hardware's page size. > // (FIXME: should pick this up from the debugger.) > > I disagree with this. Matching the possibly very large hardware page size (I think maybe they meant OS page size) would require the SA page cache to be very very large, using a lot of java heap space. It would also require a lot of unnecessary copying from the debuggee process's memory. There's no reason for the SA cache's page size to match the OS page size. > > However, 16mb seems very small. I tried 256mb and this gave about a 10% performance improvement in a heap dump, and is still fairly small, so I think it is a reasonable adjustment. > > Another comment you see in all the ports (copied from solaris-x86) is: > > // FIXME: re-test necessity of cache on Linux, where data > // fetching is faster > // Cache portion of the remote process's address space. > // Fetching data over the socket connection to dbx is slow. > // Might be faster if we were using a binary protocol to talk to > // dbx, but would have to test. For now, this cache works best > // if it covers the entire heap of the remote process. FIXME: at > > At least on linux the cache is definitely needed. I turned it off and a heap dump took 9x longer. Also I think covering the entire heap is overkill, and I doubt was ever being done given how small the cache is. So I think this comment can just be removed. This pull request has now been integrated. Changeset: c3380c03 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/c3380c03b12fcf9e8fd146525ff6ffb6e3c286bf Stats: 48 lines in 4 files changed: 0 ins; 40 del; 8 mod 8292995: improve the SA page cache Reviewed-by: kevinw, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10069 From cjplummer at openjdk.org Tue Aug 30 23:37:05 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 30 Aug 2022 23:37:05 GMT Subject: RFR: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" Message-ID: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> The root cause of this CR is that we are trying to access the java heap during the middle of a GC. This particular test is prone to that happening since it runs jstack 4 times on the debuggee as it starts up (the debuggee is jshell, so it does a lot of initialization on startup). SA needs to deal with potentially bad references to java objects. These might come from VM structs (such as the JavaThread reference to its java Thread instance), or a java object reference from a field of another java objects. There's always the possibility that these can be invalid. We work around this in most of our testing by getting the debuggee into a steady state so no GC can be in progress. For the most part SA is pretty good about dealing with these bad object refernces, and fails gracefully with an exception, but otherwise continues to run. However, this test exposed some holes that resulted in (1) way to many exception stack traces and (2) exiting the SA tool rather than trying to continue. The main fix is in JavaThread.printThreadInfo() where we now do a better job of dealing with exceptions if any of the java objects references are not valid. Even without access to the Thread instance, we can still produce a stack trace, but it will be missing things like the thread name and priority. This is a lot better than just giving up with the first exception. The other changes are for the most part just improvements in the error output, and getting rid of the printStackTrace() that was cluttering up the output. ------------- Commit messages: - When dumping the stack, be more cautious with references to java objects that might not be valid due to a GC in progress. Changes: https://git.openjdk.org/jdk/pull/10088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293006 Stats: 77 lines in 5 files changed: 38 ins; 0 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/10088.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10088/head:pull/10088 PR: https://git.openjdk.org/jdk/pull/10088 From sspitsyn at openjdk.org Wed Aug 31 00:05:07 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Aug 2022 00:05:07 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 21:16:22 GMT, Alex Menkov wrote: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. src/hotspot/share/classfile/klassFactory.cpp line 135: > 133: if (state != NULL) { > 134: Klass* k = state->get_class_being_redefined(); > 135: // use cached_class_file only for RetransformClasses More detailed comment would be nice to have here to explain in what scenario this change is needed. ------------- PR: https://git.openjdk.org/jdk/pull/10032 From cjplummer at openjdk.org Wed Aug 31 00:32:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 31 Aug 2022 00:32:50 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce Message-ID: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " ------------- Commit messages: - Workaround for JDK-8292217 for step over. Changes: https://git.openjdk.org/jdk/pull/10091/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10091&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293143 Stats: 17 lines in 2 files changed: 10 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10091.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10091/head:pull/10091 PR: https://git.openjdk.org/jdk/pull/10091 From dholmes at openjdk.org Wed Aug 31 05:18:25 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:18:25 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Tue, 30 Aug 2022 18:13:21 GMT, Ioi Lam wrote: >> compute_hash() is always called on a live WeakHandle so will never return null. > > I think you should add an assert that the `protection_domain.resolve()` never returns null, with a comment explaining why. I agree. In general if code is using WeakHandle's then I would expect to see null checks. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Wed Aug 31 05:18:29 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:18:29 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Mon, 29 Aug 2022 12:11:03 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/protectionDomainCache.cpp line 168: >> >>> 166: } >>> 167: >>> 168: void ProtectionDomainCacheTable::print_on(outputStream* st) { >> >> It is a little disconcerting that `print_on` can no longer be a `const` function! > > It's static, so it can't. Ah I see - I hadn't noticed it was now static. >> src/hotspot/share/classfile/protectionDomainCache.cpp line 186: >> >>> 184: >>> 185: // The object_no_keepalive() call peeks at the phantomly reachable oop without >>> 186: // keeping it alive. This is okay to do in the VM thread state if it is not >> >> You don't call `object_no_keepalive()` any more > > This one (not the one I removed), is called by dictionary.cpp - the pd_set is a linked list of ProtectionDomainEntry, where we don't keep the WeakHandle alive when looking at the value. I don't understand your point. My point is that the comment no longer seems correct. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Wed Aug 31 05:18:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 31 Aug 2022 05:18:30 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 20:11:51 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/protectionDomainCache.hpp line 35: >> >>> 33: // The amount of different protection domains used is typically magnitudes smaller >>> 34: // than the number of system dictionary entries (loaded classes). >>> 35: class ProtectionDomainCacheTable : public AllStatic { >> >> How about adding a comment to say what this table maps from/to? Something like: >> >> // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are >> // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. > > Okay, I added your comment. I still can't decipher what this "map" actually holds. What does the unique WeakHandle actually refer to? ------------- PR: https://git.openjdk.org/jdk/pull/10043 From mbaesken at openjdk.org Wed Aug 31 07:46:19 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 31 Aug 2022 07:46:19 GMT Subject: Withdrawn: JDK-8292595: jdwp utf_util getWideString might leak memory In-Reply-To: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com> Message-ID: On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken wrote: > There seems to be a case where utf_util.c getWideString might leak memory in an early return. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9918 From sspitsyn at openjdk.org Wed Aug 31 09:44:03 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Aug 2022 09:44:03 GMT Subject: RFR: 8175382: clhsdb pmap should print the end addresses of the load modules In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 23:04:18 GMT, Chris Plummer wrote: > The clhsdb 'pmap' command prints the start addresses and the sizes of the various load modules. It would be more intuitive to have the end address printed as the VM.dynlibs jcmd does. > > Before: > > 0x00007f8839c38000 5920K /usr/lib64/libc-2.17.so > 0x00007f883a006000 4072K /usr/lib64/libdl-2.17.so > 0x00007f883a20a000 4056K /usr/lib64/libpthread-2.17.so > 0x00007f883a426000 3944K /usr/lib64/libz.so.1.2.7 > > After: > > 0x7f0f8e482000-0x7f0f8ea00000 5624K /usr/lib64/libc-2.17.so > 0x7f0f8e850000-0x7f0f8ec00000 3776K /usr/lib64/libdl-2.17.so > 0x7f0f8ea54000-0x7f0f8ee00000 3760K /usr/lib64/libpthread-2.17.so > 0x7f0f8ec70000-0x7f0f8f000000 3648K /usr/lib64/libz.so.1.2.7 > > Note that VM.dynlibs doesn't use the 0x prefix. I considered doing the same for pmap, but it did cause one test failure that was searching for the address starting with 0x, so I decided to leave it in. Notice I also dropped the leading 0's to keep things a big more compact (VM.dynlibs does the same). Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10087 From sspitsyn at openjdk.org Wed Aug 31 09:51:10 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Aug 2022 09:51:10 GMT Subject: RFR: 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 In-Reply-To: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> References: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> Message-ID: On Mon, 22 Aug 2022 15:06:31 GMT, Daniel Skantz wrote: > Update MachineDescriptionTwosComplement.java comment to indicate that LP64 machines are no longer uncommon. This correction looks okay modulo comment from Chris about one more place. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9967 From coleenp at openjdk.org Wed Aug 31 12:34:11 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 12:34:11 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 05:15:22 GMT, David Holmes wrote: >> Okay, I added your comment. > > I still can't decipher what this "map" actually holds. What does the unique WeakHandle actually refer to? WeakHandles are wrappers around a pointer to an oop that has been allocated in OopStorage. We cannot hold oops directly in hashtables because then we'd have to tell GC how and when to walk the hashtable. We want to save the oops though because they tell us whether this protection domain has been checked for the class that we're currently loading. The Old Hashtable held WeakHandles. So does this one, except with the wart in that we need the WeakHandle for both lookup and to return a unique WeakHandle for the protection domain oop. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Wed Aug 31 12:39:08 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 12:39:08 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix comments, add assert. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10043/files - new: https://git.openjdk.org/jdk/pull/10043/files/3634521f..8bdc90e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10043&range=05-06 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10043.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10043/head:pull/10043 PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Wed Aug 31 12:39:09 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 12:39:09 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Wed, 31 Aug 2022 05:13:17 GMT, David Holmes wrote: >> This one (not the one I removed), is called by dictionary.cpp - the pd_set is a linked list of ProtectionDomainEntry, where we don't keep the WeakHandle alive when looking at the value. > > I don't understand your point. My point is that the comment no longer seems correct. The first sentence of the comment is correct. I don't know what the second sentence means, so I'll remove it. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Wed Aug 31 15:13:12 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 31 Aug 2022 15:13:12 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v3] In-Reply-To: References: <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com> Message-ID: On Wed, 31 Aug 2022 05:11:33 GMT, David Holmes wrote: >> I think you should add an assert that the `protection_domain.resolve()` never returns null, with a comment explaining why. > > I agree. In general if code is using WeakHandle's then I would expect to see null checks. I added the comment. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From amenkov at openjdk.org Wed Aug 31 21:28:24 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 31 Aug 2022 21:28:24 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: updated comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/a3558d0a..d86ae7fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Wed Aug 31 21:28:25 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 31 Aug 2022 21:28:25 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 00:01:29 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> updated comments > > src/hotspot/share/classfile/klassFactory.cpp line 135: > >> 133: if (state != NULL) { >> 134: Klass* k = state->get_class_being_redefined(); >> 135: // use cached_class_file only for RetransformClasses > > More detailed comment would be nice to have here to explain in what scenario this change is needed. I updated a comment before the code block and removed this one ------------- PR: https://git.openjdk.org/jdk/pull/10032 From sspitsyn at openjdk.org Wed Aug 31 21:54:46 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 31 Aug 2022 21:54:46 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking Message-ID: The problem is that the following assert in the JvmtiExport::post_object_free is wrong: ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. It has to be replaced with the check: if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { return; // the event type has been already disabled } In progress: mach5 nsk.jvmti and nsk.jdi test runs. ------------- Commit messages: - 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking Changes: https://git.openjdk.org/jdk/pull/10109/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293010 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10109.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10109/head:pull/10109 PR: https://git.openjdk.org/jdk/pull/10109