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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
Message-ID: <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@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

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: <DFmB_GB-FYx3rDZLwwdgc5KX9dDiedyc11BJO4XTYIc=.dc0abf3f-b117-4c48-83e8-336338120258@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
 <bMj6gZGek4GtRqIBrWw1ii6ewtuhSx4TXuUuutR6wiU=.3ecc4fbc-ec2e-4f06-9238-4d9adf38e26b@github.com>
 <M3Hz-gqEvF6J1GLzHJfpPrgaJ0asiPSpJeTyydLGljc=.76d4bd85-47aa-46e5-9e44-1343a3a20de1@github.com>
 <DFmB_GB-FYx3rDZLwwdgc5KX9dDiedyc11BJO4XTYIc=.dc0abf3f-b117-4c48-83e8-336338120258@github.com>
Message-ID: <rJ9Fo__a3KD7pESJJcjS75bZKogSIMRQeatXFVgAxPY=.b1291f86-a586-46fe-8594-f2f01a1f289a@github.com>

On Wed, 20 Jul 2022 07:41:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>

On Thu, 28 Jul 2022 16:11:12 GMT, Ao Qi <aoqi at openjdk.org> 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<T> 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: <rJ9Fo__a3KD7pESJJcjS75bZKogSIMRQeatXFVgAxPY=.b1291f86-a586-46fe-8594-f2f01a1f289a@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
 <bMj6gZGek4GtRqIBrWw1ii6ewtuhSx4TXuUuutR6wiU=.3ecc4fbc-ec2e-4f06-9238-4d9adf38e26b@github.com>
 <M3Hz-gqEvF6J1GLzHJfpPrgaJ0asiPSpJeTyydLGljc=.76d4bd85-47aa-46e5-9e44-1343a3a20de1@github.com>
 <DFmB_GB-FYx3rDZLwwdgc5KX9dDiedyc11BJO4XTYIc=.dc0abf3f-b117-4c48-83e8-336338120258@github.com>
 <rJ9Fo__a3KD7pESJJcjS75bZKogSIMRQeatXFVgAxPY=.b1291f86-a586-46fe-8594-f2f01a1f289a@github.com>
Message-ID: <242fMLhOfuOetmXzjh62jRknGs7rONTdXbybViyAizg=.0b8f1333-90a9-48f5-8cc6-6bce8d08067e@github.com>

On Mon, 1 Aug 2022 06:51:28 GMT, KIRIYAMA Takuya <duke at openjdk.org> 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: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
References: <aRBY6vM-4y25VCl8od3f7qcihIFfwV6-PoytWnDJAYM=.589ba26b-b731-4878-93a7-06738a9990fd@github.com>
Message-ID: <Ubj4N4134OMVykbhhXWM2y8KLpnDkX_cpFwMCObZRxE=.b941674f-355d-49e1-a917-b031c8e1444a@github.com>

On Tue, 19 Jul 2022 06:30:09 GMT, KIRIYAMA Takuya <duke at openjdk.org> 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 <kiriyama.takuya at fujitsu.com>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
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: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <Us2WLe6tvDTtiBgYBElsWmC_3OPgUAkagCIu45xbf3M=.c50985e0-e47b-49c2-b1e9-4ebd90963d52@github.com>

> `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 <alanb at openjdk.org>

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

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: <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
Message-ID: <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>

On Mon, 1 Aug 2022 07:18:52 GMT, Alan Bateman <alanb at openjdk.org> 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<T> 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: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@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.

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

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: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>

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: <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
 <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
Message-ID: <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>

On Mon, 1 Aug 2022 12:02:19 GMT, Ao Qi <aoqi at openjdk.org> 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: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <RVvuKD6GmNvSf0gvQITk2OWA2M_y7UG5IeSRmaeI4uY=.106152b7-0c27-4964-a9fc-f7f3c74eaa21@github.com>

> `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: <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
 <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
 <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>
Message-ID: <51V8ClPS3vEJ9ZwkzJZwiBUTQsJx5XPRLPY_z8IfSxQ=.9d5d5def-5e1d-459a-b0d7-b3e412c546bb@github.com>

On Mon, 1 Aug 2022 15:54:47 GMT, Alan Bateman <alanb at openjdk.org> 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: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
Message-ID: <O9yRN6jY9EjtvHp7fHIG81kU_uHr4nFmFs2tviKvJ5k=.a3ff6f40-de36-4f0c-af35-e1adf2c4bf55@github.com>

On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung <achung at openjdk.org> 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: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>
References: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>
Message-ID: <l6_Vv4nLP6L32_SG24C2om_jojBS9TPieU-sf1efWeI=.f0b973f0-d093-4364-93fd-2bbf88cf6d53@github.com>

On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <SZ9B5Z4esdhz-yNxeXX0snA0Ofu09X8PbHm5aMR5z0U=.55dfdcfa-1e18-47a7-947d-a52db4c33aeb@github.com>

On Mon, 1 Aug 2022 20:05:02 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <cweHn9m5WTC7pQgMJvEv2DqxAxQvhOZ18icYrQWvjso=.d808df99-b834-4fe1-b83b-0a5dae714d6b@github.com>

On Mon, 1 Aug 2022 21:02:39 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <ZN96QqNyJ-fP9y-fKv9mE2NSvUfl9OT-VQfB4l7fdP0=.373a175b-b742-4253-b534-f3723f180267@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> 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 <weijun at openjdk.org>
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: <cweHn9m5WTC7pQgMJvEv2DqxAxQvhOZ18icYrQWvjso=.d808df99-b834-4fe1-b83b-0a5dae714d6b@github.com>
References: <5a30LGcAeHansYPc2N7SNzWk1c51dt16p0LWjGKcOzs=.b1da831a-7042-4234-9e60-01f241a391ec@github.com>
 <cweHn9m5WTC7pQgMJvEv2DqxAxQvhOZ18icYrQWvjso=.d808df99-b834-4fe1-b83b-0a5dae714d6b@github.com>
Message-ID: <kuV3luzx5nt2pgblqHiFZ8Gy5eZiy-oizSgwl2gICew=.923ef1b6-bfc6-425d-8937-0d10b4d4ca00@github.com>

On Mon, 1 Aug 2022 21:25:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <FqlRNkz5NMYzd28AGDBb_20J5pdtP9DKL_sJgkxnRjw=.2db16fcc-ce80-45b4-a59d-a0b6d5a4818b@github.com>

On Mon, 1 Aug 2022 21:02:39 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>

> `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 <alanb at openjdk.org>
 - 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: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <RgSuOV1j5nPaotE4O96x5QU2Ab8R8corK5vCbsHzBXk=.288a6bf5-6d43-4954-8d90-b4cac8e4c5e7@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> 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 <alanb at openjdk.org>
>  - 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: <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
Message-ID: <7ZWXnITgRa_WubtuwnM3VTs62HqwzbMOUt9Tdp9Fx-s=.d3e48748-36fc-4ce1-a096-5830afa1c29d@github.com>

On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas <duke at openjdk.org> 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: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> 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 <alanb at openjdk.org>
>  - 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: <l7UFWL18tFuH0EHiPiNOCf1n_KkxgLyt7MUcOLiiaC0=.eb7bce46-484a-4047-8484-4d29c97520cf@github.com>

On Mon, 1 Aug 2022 20:05:02 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <Wikbha4eGiEqSbphyzGX16VubBNtPMihpAN3F0Ph2ac=.c01c7ca7-ad4d-4f15-b2b8-e8b838eda640@github.com>

On Mon, 1 Aug 2022 20:05:02 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <9udmozwzmOEm5-cfI85oeAVTafamwMrZj1-Y2q6mxLA=.1708e4bf-24ec-4d5b-9859-7129342628ab@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> 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 <alanb at openjdk.org>
>  - 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 <cjplummer at openjdk.org> 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: <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
Message-ID: <QuTdFxWX4o1iwUcN001JkqKEEFV3KbvJa0al4VIYsXw=.0df34f49-d958-4648-87ac-f7c1dde9c5f2@github.com>

On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas <duke at openjdk.org> 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: <hzYDp_fPzcYHCRN3dL2q9Gnx6b8H33pawP3ybj57S3g=.cea348e2-40f0-4433-a0b7-84ba6056fb80@github.com>

On Mon, 1 Aug 2022 20:05:02 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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: <KB4IsmFz6ssx4Fgh2TkNEogNdqD0Q_z6E6UrDx-rt0s=.048550f0-8137-47e0-9e93-226947cacc5b@github.com>

On Mon, 1 Aug 2022 21:02:39 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>
References: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>
Message-ID: <33PUVzpnb1IiVPy7U7CTIGr_cjAFn_Elj4uvoa3hw3Q=.40ee2a10-8dda-42ce-8054-1277b06588dc@github.com>

On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>
References: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>
Message-ID: <vzDILk1RJ4za_taflz6Ie3TIAopBQjujR2vHFLBiPCI=.8bd19ec5-f339-4063-840c-dac11be1c15b@github.com>

On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>
References: <mgCmKfF5O_mRoqvU0ziEN2oAWe77XrEq2Bhzxym8osw=.0a778b30-06d8-4c4b-9fed-7c84093185c0@github.com>
Message-ID: <rgjL19x6O1W5AbBrSrimrTIlhP8ma3PqLnilrG56APA=.c818f9e0-6a54-4b26-af19-15f8322b23bc@github.com>

On Mon, 1 Aug 2022 07:41:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 <sspitsyn at openjdk.org>
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: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>

> `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: <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
 <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>
Message-ID: <ga517T_Y4c-YsmdoMXQdVMQMggNA9yVlarfwuL8uCGU=.f20e6093-450d-410b-a85f-f0a9964e8b79@github.com>

On Tue, 2 Aug 2022 17:25:19 GMT, Alan Bateman <alanb at openjdk.org> 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: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@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 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: <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
Message-ID: <Hk6PusjOxKZgi0ACnTXGGFO9CCmg5YTquGvHIeWuBYU=.369b5231-7a68-4c4e-a738-4ae75e2ab577@github.com>

On Wed, 3 Aug 2022 09:06:39 GMT, xpbob <duke at openjdk.org> 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: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
References: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
Message-ID: <5YumC2qJXy3bLaZ0CFKYSe1MSIzfUkquNlP4kLDl1j0=.e31cfa03-845a-4d3f-ad61-df24fa8953e1@github.com>

On Mon, 1 Aug 2022 09:16:41 GMT, Alan Bateman <alanb at openjdk.org> 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: <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
Message-ID: <1GxIcg5723Xpmw0AwwNNx_aD-joLaJbyZF2xkrKmBbA=.06dde6e6-64fb-4145-b20e-847598843f87@github.com>

On Wed, 3 Aug 2022 09:06:39 GMT, xpbob <duke at openjdk.org> 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: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
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: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
References: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
Message-ID: <xnEflFjvceRO0xhgsE5_RAVTyCdAIehI7Od1B9RFkEs=.75459b02-8ab3-4220-8d50-70d301976f85@github.com>

On Mon, 1 Aug 2022 09:16:41 GMT, Alan Bateman <alanb at openjdk.org> 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: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
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: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <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 <duke at openjdk.org> 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: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <-I4q3Qy5ZVaGShBrUsPK2W9x_6cfUYRgBe42-GJtmi4=.59df8931-e165-4527-9d76-4f95e605abc8@github.com>
Message-ID: <L8hrCFA61JDjK9ixCkW-aOQtip4SzlygcCtQkFSA6gU=.108f69c2-3a0e-4158-bdb7-08b889a4a430@github.com>

On Wed, 3 Aug 2022 10:36:06 GMT, xpbob <duke at openjdk.org> 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: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
Message-ID: <6hRAKer8eW6kUHAIv-xHtLffshGe2OMmXiJe-wbmdHM=.ab4418e2-f40c-44c0-b546-686f0d09ef74@github.com>

On Wed, 3 Aug 2022 02:34:48 GMT, Ao Qi <aoqi at openjdk.org> 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: <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
Message-ID: <giJswzsEoPuz-zIzC4soxoDw278Vs5mZYGztLmHiJtk=.3523d23b-17e3-4446-b6ae-256daa7de1a8@github.com>

On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas <duke at openjdk.org> 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: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
References: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
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: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
 <6CQjn1v6rwjxnE5BWB8OQdVHSr0xKW4TGc6dPwEiPYE=.f5054692-bc94-4667-b687-859e6eb25ce7@github.com>
Message-ID: <eEktpy36rq2Rb9wMKkQ2smjseFH4H8eCNEmNjyau6kk=.d5179bd3-a1b4-4790-b10e-0caaeef648fa@github.com>

On Wed, 3 Aug 2022 14:37:52 GMT, Alan Bateman <alanb at openjdk.org> 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: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
Message-ID: <feOKmPYl5W1JQLFVLPQrblg18RKtcs6QQ4eEfPmCg4A=.8d1b1f89-14dc-45ac-acbb-58a3736faf51@github.com>

On Wed, 3 Aug 2022 02:34:48 GMT, Ao Qi <aoqi at openjdk.org> 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: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <shaZMSKrDCJTmFW5jYfs8ZWjLRlPvb8DEAaZdfR6IQI=.59c352ff-dcc9-4012-b044-b2513021cd3c@github.com>

On Thu, 28 Jul 2022 16:11:12 GMT, Ao Qi <aoqi at openjdk.org> 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 <aoqi at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
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: <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
Message-ID: <s_BJfGQr79DEkE38rukyS7dy-42yNEer8MEfzHWq65g=.e9d7b55e-b5e1-44bd-9cdc-394aaa81f329@github.com>

On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas <duke at openjdk.org> 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: <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
Message-ID: <QKvvDhgrKwiNLq0inCI7cLa_94iZXLqsVRa3XtOdjc4=.e8302317-d43c-4117-9ac8-38aa4539aa58@github.com>

On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas <duke at openjdk.org> 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: <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
Message-ID: <YoirF4OVKvJtnVu8bp3xc8xIx2tB9CxAx2BT7Ozyiok=.9deddb5c-7ddb-49a3-bd55-c6e890d7bf4a@github.com>

On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas <duke at openjdk.org> 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: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
 <6CQjn1v6rwjxnE5BWB8OQdVHSr0xKW4TGc6dPwEiPYE=.f5054692-bc94-4667-b687-859e6eb25ce7@github.com>
Message-ID: <b2t5uF4_wdd4C2nnGAF-alIT10PBr9iaOI9TBji94vo=.f71dd828-a5cf-4be1-998b-f73a41c3476e@github.com>

On Wed, 3 Aug 2022 14:37:52 GMT, Alan Bateman <alanb at openjdk.org> 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: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <6zyYs300tD4dVrr_FT6ILURyaxkXaKtDe3rbLm1rMD8=.64484460-e180-4b3b-97f9-8573daa11da0@github.com>

On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess <duke at openjdk.org> 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: <YoirF4OVKvJtnVu8bp3xc8xIx2tB9CxAx2BT7Ozyiok=.9deddb5c-7ddb-49a3-bd55-c6e890d7bf4a@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
 <YoirF4OVKvJtnVu8bp3xc8xIx2tB9CxAx2BT7Ozyiok=.9deddb5c-7ddb-49a3-bd55-c6e890d7bf4a@github.com>
Message-ID: <q-u6b5qfCkTVn1Xr_5blamvhgWsgKCvuCfdWF2tbK2c=.0e64440a-d2be-4c4a-9e5c-7b4b6928508f@github.com>

On Wed, 3 Aug 2022 20:42:59 GMT, Erik ?sterlund <eosterlund at openjdk.org> 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: <YoirF4OVKvJtnVu8bp3xc8xIx2tB9CxAx2BT7Ozyiok=.9deddb5c-7ddb-49a3-bd55-c6e890d7bf4a@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
 <YoirF4OVKvJtnVu8bp3xc8xIx2tB9CxAx2BT7Ozyiok=.9deddb5c-7ddb-49a3-bd55-c6e890d7bf4a@github.com>
Message-ID: <STmL_5dzPfki6c2U4do2jtNtYvuzxp5lfJ1XBbdBDNo=.cf3366b1-006b-4937-9730-0f0b2da0da42@github.com>

On Wed, 3 Aug 2022 20:42:59 GMT, Erik ?sterlund <eosterlund at openjdk.org> 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: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
References: <GSOebqarELt22G5NTUDqAo_TqNw_ibMyoVW-koWxQys=.21e6dc3f-c466-4a3a-9c65-e0479d757e2c@github.com>
Message-ID: <BAekJ2MiptYs4LZ_CpYMxn8JXywPYjHTwnN434TWmVw=.a0f8cc8b-a6d5-479e-923e-22626e55fbfe@github.com>

On Mon, 1 Aug 2022 09:16:41 GMT, Alan Bateman <alanb at openjdk.org> 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 <alanb at openjdk.org>
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: <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>

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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20220805/c35505a0/attachment.htm>

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: <ia97ycDhqbfK67CREj87gKnS9nOQTMgQRjXcOUkbrok=.254a41c4-194b-480f-b5e5-958f654f5cdc@github.com>

On Fri, 5 Aug 2022 22:29:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 87cda21c
Author:    David Holmes <dholmes at openjdk.org>
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: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>

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: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
Message-ID: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>

On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons <jjg at openjdk.org> 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: <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com>
 <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
Message-ID: <ad849200-655d-874d-ba0b-7c74b9e2e465@jetbrains.com>

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 = <void value>, "thread=main", 
java.lang.Object.<init>(), 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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20220806/32fc9636/attachment-0001.htm>

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: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
References: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
Message-ID: <YVrFDk5lzFyuj-U-ZV2RCEYTt_Wr0Uy2yJ6S2EwS-kY=.95bc1ca7-0bdd-4a77-9c7a-ac1336e9bf58@github.com>

On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam <iklam at openjdk.org> 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: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
 <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
Message-ID: <_53Ro95x3TDbVcRUoOr4L0HiWCyepU8CgcyPCwLwKLA=.6ce49e6c-9b4b-4c8e-b0b8-7ec76b0f3d85@github.com>

On Sat, 6 Aug 2022 09:01:39 GMT, Patrick Pfeifer <duke at openjdk.org> 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: <ad849200-655d-874d-ba0b-7c74b9e2e465@jetbrains.com>
References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com>
 <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
 <ad849200-655d-874d-ba0b-7c74b9e2e465@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: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20220807/6d829dbb/attachment.htm>

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: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
References: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
Message-ID: <D_U89ljj5da_kPSVkc3xTMdKbve_jkwQiunavaTtdBE=.da700f21-ecab-4c27-bb56-ecb2ecc3227f@github.com>

On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam <iklam at openjdk.org> 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.

<grumble grumble> 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: <YVrFDk5lzFyuj-U-ZV2RCEYTt_Wr0Uy2yJ6S2EwS-kY=.95bc1ca7-0bdd-4a77-9c7a-ac1336e9bf58@github.com>
References: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
 <YVrFDk5lzFyuj-U-ZV2RCEYTt_Wr0Uy2yJ6S2EwS-kY=.95bc1ca7-0bdd-4a77-9c7a-ac1336e9bf58@github.com>
Message-ID: <Q8QwywcnlJG3hq9XsfANy1fY1O01GGPZwnjvmI58owY=.cfe6d290-fce3-47f3-a092-dbea7942e661@github.com>

On Sat, 6 Aug 2022 13:09:01 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>
 <fzYPByODY9JgpYCl5MZf8YW9SDDT2ziR_RrqhfAd_rA=.55cde745-01d7-4dff-82ef-771afc1da2cd@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 <jjg at openjdk.org> 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: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
References: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
Message-ID: <SmruUMl7mVrYYXYoTqQ8emS2KNzWkzx8mglx3Gsj0Kc=.4971ec48-09b3-4102-b02c-fafaee6c0e3a@github.com>

On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam <iklam at openjdk.org> 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: <SmruUMl7mVrYYXYoTqQ8emS2KNzWkzx8mglx3Gsj0Kc=.4971ec48-09b3-4102-b02c-fafaee6c0e3a@github.com>
References: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
 <SmruUMl7mVrYYXYoTqQ8emS2KNzWkzx8mglx3Gsj0Kc=.4971ec48-09b3-4102-b02c-fafaee6c0e3a@github.com>
Message-ID: <8uh4O1V5TnmKsKxB0blcohCIcM26deY35AKvEG11l_I=.1213fbe8-9793-46ee-9f6e-c2c82b55cfaf@github.com>

On Mon, 8 Aug 2022 01:26:11 GMT, David Holmes <dholmes at openjdk.org> 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: <tc_d0ySuW8OBlut1XbQlTdRnGN1pbrSljKTnKC879Wc=.7aa1da5b-d6ac-4e4a-ae17-4eb69cff2376@github.com>
 <SmruUMl7mVrYYXYoTqQ8emS2KNzWkzx8mglx3Gsj0Kc=.4971ec48-09b3-4102-b02c-fafaee6c0e3a@github.com>
 <8uh4O1V5TnmKsKxB0blcohCIcM26deY35AKvEG11l_I=.1213fbe8-9793-46ee-9f6e-c2c82b55cfaf@github.com>
Message-ID: <WjnAFr2HWabxlWfQLjiiOLkAdbVD109WKV0Su8JRpiI=.36179de7-60f5-401f-bccb-72fb55d374e0@github.com>

On Mon, 8 Aug 2022 02:14:45 GMT, Ioi Lam <iklam at openjdk.org> 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: <ad849200-655d-874d-ba0b-7c74b9e2e465@jetbrains.com>
References: <11c7c221-6269-75f6-3666-aa7288613151@jetbrains.com>
 <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
 <ad849200-655d-874d-ba0b-7c74b9e2e465@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 = <void value>, "thread=main", 
> java.lang.Object.<init>(), 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>
 <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
 <ad849200-655d-874d-ba0b-7c74b9e2e465@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 = <void value>, "thread=main", 
>> java.lang.Object.<init>(), 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>
 <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
 <ad849200-655d-874d-ba0b-7c74b9e2e465@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 = <void value>, "thread=main", 
>>> java.lang.Object.<init>(), 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: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
References: <GVPRW0DDurIFj1uVCxI9vhNDSI8a_p3rPVx6PdqbO6E=.30a7ffe9-9ba8-4832-8f74-b98ae194c3c2@github.com>
Message-ID: <TxC2iKSSrFV6AvzHgUK8FJ8bs8twtVfwtduFoxpEa58=.5eae9e0d-03c3-499f-94e0-c7c204b0c747@github.com>

On Thu, 14 Jul 2022 21:56:57 GMT, Bill Huang <duke at openjdk.org> 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 <bill.w.huang at oracle.com>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>

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: <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <Zhz9ssqsVU6b2GDaoM5cvN2XHTqmpygTjukw0YP_hh8=.82cb5df7-40e3-4ba0-995c-957dfbaa8d19@github.com>
Message-ID: <fo2uFQC0GpMVFeE9eQ4aYfTjtCdSUinRZ6kv3NJOM7Q=.d70a7eca-bc82-4977-ab3b-1ede78f13d10@github.com>

On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas <duke at openjdk.org> 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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
Message-ID: <t1-FppdIElTX1Gu9TDUFMWVyXBJDt2gfxC0M2ZjN53g=.e648fe80-0d0a-4e5f-a8a0-6c9fa2190ee4@github.com>

On Mon, 8 Aug 2022 19:52:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <t1-FppdIElTX1Gu9TDUFMWVyXBJDt2gfxC0M2ZjN53g=.e648fe80-0d0a-4e5f-a8a0-6c9fa2190ee4@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <t1-FppdIElTX1Gu9TDUFMWVyXBJDt2gfxC0M2ZjN53g=.e648fe80-0d0a-4e5f-a8a0-6c9fa2190ee4@github.com>
Message-ID: <cFZuplchsd1iHDcUxiZT24nOyGqf8Cb7lSO0u_Tl17k=.4f693b06-d265-487e-bd56-ce3d2b7f3dd2@github.com>

On Mon, 8 Aug 2022 21:31:27 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
Message-ID: <hgiTn0ZzybaQwxqWdhMcyAR8z6JnZfSKh5GKKi4qEXU=.4666e78e-12d9-46f8-8392-f9ac9ded4933@github.com>

On Mon, 8 Aug 2022 19:52:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com>
Message-ID: <ouvVr2cvwgMorZnRwLwLK4HkjAQC-0kN2xzgAWle2dE=.98635408-aef0-4c95-a4a3-f21c659c1ffb@github.com>

On Tue, 9 Aug 2022 02:35:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com>
Message-ID: <NZkBpFAIaIFuQjlWr_Wn4duPcABod4RmoUzM7A-jx5w=.656f6a5c-1a16-4ea9-9ac8-f68cae7f1797@github.com>

On Tue, 9 Aug 2022 02:35:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
Message-ID: <k6yuO7WWfo6sUSzqiUmIpuktBZjIi1IlHrmDkULvDvY=.bd053666-f50f-4777-9377-0df00efd5fa5@github.com>

On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung <achung at openjdk.org> 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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
Message-ID: <V8EpP7b71dSCNft99LCQQJ_Gmk72HOR5p0U95PZp12o=.80db065c-a0da-4e2b-9cc1-bcc4ffb22c50@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:

  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: <NZkBpFAIaIFuQjlWr_Wn4duPcABod4RmoUzM7A-jx5w=.656f6a5c-1a16-4ea9-9ac8-f68cae7f1797@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <-uOgC18mi-6anBzpC6iknrixUfwkbiYPvHG9Uxm_QOs=.84bdc7a9-7fc1-480b-88e4-1dc72279f966@github.com>
 <NZkBpFAIaIFuQjlWr_Wn4duPcABod4RmoUzM7A-jx5w=.656f6a5c-1a16-4ea9-9ac8-f68cae7f1797@github.com>
Message-ID: <gdYTP8Z5vC-QCesh5gDRWSMaMjjqObio8aYHUaDnScA=.9372ecdd-2e09-417d-9d1a-21e3430eb2b6@github.com>

On Tue, 9 Aug 2022 14:20:13 GMT, Kevin Walls <kevinw at openjdk.org> 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: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>

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: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <t55pQRbvhOdoVQJwhw2ZE0-leDp1t-JleRoloUUM3lk=.77547312-50b5-4e83-aca3-ab0a81682bc6@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> 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: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <q3eKnCK-mTAP42I8K9ifRoP0RBS0nLNwsGoZpEt_e0A=.5da69e5f-4232-40e4-8f69-ccae924fcd3a@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

This pull request has now been integrated.

Changeset: 0def5316
Author:    Alisen Chung <achung at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
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: <V8EpP7b71dSCNft99LCQQJ_Gmk72HOR5p0U95PZp12o=.80db065c-a0da-4e2b-9cc1-bcc4ffb22c50@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <V8EpP7b71dSCNft99LCQQJ_Gmk72HOR5p0U95PZp12o=.80db065c-a0da-4e2b-9cc1-bcc4ffb22c50@github.com>
Message-ID: <bZLi9P_Bg533sEqYVp-1EL8jmbMcTYFiu0_baoxEK0E=.855fd787-753a-4ae9-b49c-1a4844e2b095@github.com>

On Tue, 9 Aug 2022 20:29:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
References: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
Message-ID: <x2l5NJ4dB6yRfSGryPbHf_LW3Q2G6jvwysxE2Gr1f8s=.36811dd0-a7a8-46d2-bf2e-59fc6ebd856e@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:

  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>
 <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
 <ad849200-655d-874d-ba0b-7c74b9e2e465@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 = <void value>, "thread=main", 
>>> java.lang.Object.<init>(), 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>
 <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
 <ad849200-655d-874d-ba0b-7c74b9e2e465@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 = <void value>, "thread=main", 
>>>> java.lang.Object.<init>(), 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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
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>
 <ece5b4e7-60ab-3d32-d176-4ec47d3bed2c@oracle.com>
 <ad849200-655d-874d-ba0b-7c74b9e2e465@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 = <void value>, "thread=main", 
>>>>> java.lang.Object.<init>(), 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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <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 <duke at openjdk.org> 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: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <p6IxQrP43QKmTZbmEcHTaaQwrF8xzY_U5B3Nq0apUxQ=.bdd0d08f-2901-4a0a-87fa-2cf9ac54c7ca@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> 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: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <3Mg1niwPI-4uyEH9ifLqN0ERzNGdNNcl7_w4_gfyfMw=.f42f8f15-1237-41d1-ba80-2a7cd9f72ead@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> 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: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <GkofIESgeAqIj_6Z6MfiS0oq4i2VSJ6xCBy5mMv4Tgs=.2686d713-51fe-49f8-b8a0-0a2ebde9d228@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> 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: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <M_aafH8niF-bUmCzlWHq869QvIb8q-aTXesvHrVPguM=.c83512ce-0980-4bd4-8799-a63a2a7d8e72@github.com>

> 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: <V8EpP7b71dSCNft99LCQQJ_Gmk72HOR5p0U95PZp12o=.80db065c-a0da-4e2b-9cc1-bcc4ffb22c50@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <V8EpP7b71dSCNft99LCQQJ_Gmk72HOR5p0U95PZp12o=.80db065c-a0da-4e2b-9cc1-bcc4ffb22c50@github.com>
Message-ID: <5DsPjhUwjM0F4aafgQp8xBxH_k2mFLBKcMoWZ3aMb44=.2d064dcd-6286-46b0-86a7-b7a61afe0ce8@github.com>

On Tue, 9 Aug 2022 20:29:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <M_aafH8niF-bUmCzlWHq869QvIb8q-aTXesvHrVPguM=.c83512ce-0980-4bd4-8799-a63a2a7d8e72@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
 <M_aafH8niF-bUmCzlWHq869QvIb8q-aTXesvHrVPguM=.c83512ce-0980-4bd4-8799-a63a2a7d8e72@github.com>
Message-ID: <b884Uhao-g1T47_zC7XeUbBCCDvmVfWru-trUp95eQw=.c6e5fa58-02bb-4c28-a3af-1b2b794eca15@github.com>

On Wed, 10 Aug 2022 18:50:51 GMT, Bill Huang <duke at openjdk.org> 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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
Message-ID: <BlfWaC7m9snrdCu8K5iDHHxDGs2FfLE72DfqxCpxM9Y=.ff43cf15-ea18-4925-b83d-6f27d3848aed@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/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: <b884Uhao-g1T47_zC7XeUbBCCDvmVfWru-trUp95eQw=.c6e5fa58-02bb-4c28-a3af-1b2b794eca15@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
 <M_aafH8niF-bUmCzlWHq869QvIb8q-aTXesvHrVPguM=.c83512ce-0980-4bd4-8799-a63a2a7d8e72@github.com>
 <b884Uhao-g1T47_zC7XeUbBCCDvmVfWru-trUp95eQw=.c6e5fa58-02bb-4c28-a3af-1b2b794eca15@github.com>
Message-ID: <0PK8yhJEINzYjG9vsCpb7ceOk779HGn1x8o2hVOmt4U=.6049910f-3447-4b5a-acde-c1086ff62b5e@github.com>

On Wed, 10 Aug 2022 21:09:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <BlfWaC7m9snrdCu8K5iDHHxDGs2FfLE72DfqxCpxM9Y=.ff43cf15-ea18-4925-b83d-6f27d3848aed@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
 <BlfWaC7m9snrdCu8K5iDHHxDGs2FfLE72DfqxCpxM9Y=.ff43cf15-ea18-4925-b83d-6f27d3848aed@github.com>
Message-ID: <JFdey0JXDUp09i6PwGcKebKns1rrxgn0gLZ4zDryQLo=.eff1d3ac-c0b9-4ef6-8d92-fd963489ad6d@github.com>

On Wed, 10 Aug 2022 21:17:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>

> 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: <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
 <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>
Message-ID: <dWV0R8zQjOsk0yJQlZSKWnkZoOzVCRQAzJ4vmVSM3h4=.1d4e3465-e6c3-4b59-b3ae-f25cbfca6a44@github.com>

On Wed, 10 Aug 2022 22:02:52 GMT, Bill Huang <duke at openjdk.org> 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: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
References: <kOkotUZubClu5xBnNrFRnCEriFlnMFBqqGrzUvrKibs=.e5658dcc-f11c-44b6-b9fa-9e8d010c864a@github.com>
Message-ID: <YiKfo_qoCU_-o0wG0oHYWiVgXCjoRLPy783W9c0VSQM=.5a827b72-5610-4c08-9fab-bb988b5e7432@github.com>

On Mon, 8 Aug 2022 19:52:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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 <lmesnik at openjdk.org>
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: <TK7rZc7iXn-497mHUr2xDpAwh2v1dQs10yMlkbgspjk=.95a9e6ed-27ee-4fdf-8adf-34de0b799712@github.com>
 <crz-ne87zO-hyLRMlhNsBq6fQCYWn7HdGgad_IcGBpk=.375b487f-6140-4ed6-955b-af5dbba50b2d@github.com>
 <1GxIcg5723Xpmw0AwwNNx_aD-joLaJbyZF2xkrKmBbA=.06dde6e6-64fb-4145-b20e-847598843f87@github.com>
Message-ID: <hN5WeGgAmuOJi9RIJMru_p7J1iGgEeDs9i_ZHNllT78=.8231c8ba-b291-4b65-93c0-829b15cae359@github.com>

On Wed, 3 Aug 2022 09:18:26 GMT, Alan Bateman <alanb at openjdk.org> 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: <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
 <L8PXppoVj_wThPFMGR6zl9h_vsjGy8J6rLkX7lfVZAo=.1c5c3129-3504-4e69-a277-294ed7d42e94@github.com>
Message-ID: <CeTgWRfl_dZCiwQWTlRv6l0uE6NmCEmRMRF9vsEEeaM=.133b8b41-a68a-4bba-936b-c1afbde11580@github.com>

On Wed, 10 Aug 2022 22:02:52 GMT, Bill Huang <duke at openjdk.org> 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: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>

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: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>
References: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>
Message-ID: <tDsmxM0i7TDUsE501WbVPMDEMsZb2_d1PaZb84pVJQI=.4b33399d-425a-44ee-a1b3-ea91f25f487e@github.com>

On Thu, 11 Aug 2022 00:06:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 85a60235
Author:    David Holmes <dholmes at openjdk.org>
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: <rd8S2oUSNoFAG-c2leFitW_qfCFwfOmpjKTD9pleVAc=.c99a6691-4ae2-4036-b950-f93182a05252@github.com>

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: <rd8S2oUSNoFAG-c2leFitW_qfCFwfOmpjKTD9pleVAc=.c99a6691-4ae2-4036-b950-f93182a05252@github.com>
References: <rd8S2oUSNoFAG-c2leFitW_qfCFwfOmpjKTD9pleVAc=.c99a6691-4ae2-4036-b950-f93182a05252@github.com>
Message-ID: <uVIuC7emz9YJLjXwHti5kJo54Tm0ihB-GA6zlbzfmpQ=.e2359b77-24b3-47a2-9e7f-488c7103c029@github.com>

On Thu, 11 Aug 2022 07:12:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
References: <TABgOEpw1zPKtnZkSXApmY1iI7XpaiTvt0G1lqNhUAk=.ba729d13-4680-406c-9835-d0aa02d59ffd@github.com>
Message-ID: <2lsSCwEjUh2Q6JFbJkcgOMCzo_Rt6BF1x8w-yhDalwg=.9949ffa6-854a-4e48-a1f8-8a4a76a398e0@github.com>

On Tue, 9 Aug 2022 21:14:39 GMT, Bill Huang <duke at openjdk.org> 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 <bill.w.huang at oracle.com>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
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: <rd8S2oUSNoFAG-c2leFitW_qfCFwfOmpjKTD9pleVAc=.c99a6691-4ae2-4036-b950-f93182a05252@github.com>
References: <rd8S2oUSNoFAG-c2leFitW_qfCFwfOmpjKTD9pleVAc=.c99a6691-4ae2-4036-b950-f93182a05252@github.com>
Message-ID: <qY5imvOE4SdmltW8HbkWJdMhDZxbfvoD7E0TUYBbb30=.123ce5ed-bb1c-4838-9b5d-6298e20233da@github.com>

On Thu, 11 Aug 2022 07:12:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>

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: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
Message-ID: <vf_VUZXrDqPYHkVXQspSXbrF4BzWO0d7R_XPZAL766E=.624e474c-d011-4713-bbf8-513fa2d13474@github.com>

On Thu, 11 Aug 2022 16:03:58 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
Message-ID: <V59YZrEfZxxUFufOBtmbbO_GvDOjEJ_5gneKzI8WbJc=.7a39a0bb-38ed-4845-98da-cafbcc2e1fd9@github.com>

> 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: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>

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: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>

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: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
References: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
Message-ID: <inktNUtV5pSxwFaZHfNL79xAD767i00NvtQIlPQ3JXU=.4fc6ebc8-4ac5-444c-9d34-a187b1928239@github.com>

On Thu, 11 Aug 2022 20:15:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
References: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
Message-ID: <GgwIXz4Gm7O2xLvxSj8ZI5IwooM7jqZn6cUVtuGUXPQ=.079ef15c-ae46-48b8-9de3-12a2d9c4ae0f@github.com>

On Thu, 11 Aug 2022 18:27:12 GMT, Kevin Walls <kevinw at openjdk.org> 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: <GgwIXz4Gm7O2xLvxSj8ZI5IwooM7jqZn6cUVtuGUXPQ=.079ef15c-ae46-48b8-9de3-12a2d9c4ae0f@github.com>
References: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
 <GgwIXz4Gm7O2xLvxSj8ZI5IwooM7jqZn6cUVtuGUXPQ=.079ef15c-ae46-48b8-9de3-12a2d9c4ae0f@github.com>
Message-ID: <ukWmdw2WjFkU7ULyCqsdxnNN9H6MpwkvtEvvu6ob5Jc=.574a943d-050a-4e25-b22f-d2d33cde1ee8@github.com>

On Thu, 11 Aug 2022 21:06:05 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>

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: <inktNUtV5pSxwFaZHfNL79xAD767i00NvtQIlPQ3JXU=.4fc6ebc8-4ac5-444c-9d34-a187b1928239@github.com>
References: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
 <inktNUtV5pSxwFaZHfNL79xAD767i00NvtQIlPQ3JXU=.4fc6ebc8-4ac5-444c-9d34-a187b1928239@github.com>
Message-ID: <W4-UOr2nALNq71BORgH7OyMuEcgY5KOv2tUqzVthuOY=.e344ec63-b4c1-4b91-9176-140fae649ebf@github.com>

On Thu, 11 Aug 2022 21:01:20 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <inktNUtV5pSxwFaZHfNL79xAD767i00NvtQIlPQ3JXU=.4fc6ebc8-4ac5-444c-9d34-a187b1928239@github.com>
References: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
 <inktNUtV5pSxwFaZHfNL79xAD767i00NvtQIlPQ3JXU=.4fc6ebc8-4ac5-444c-9d34-a187b1928239@github.com>
Message-ID: <6hppKWMn_ytWtM2txTOUUKOOt4aZ-eXPAUiwrMSW9jQ=.4f085fcb-ba7e-4aa8-af1f-844772f53725@github.com>

On Thu, 11 Aug 2022 21:01:20 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
 <inktNUtV5pSxwFaZHfNL79xAD767i00NvtQIlPQ3JXU=.4fc6ebc8-4ac5-444c-9d34-a187b1928239@github.com>
 <6hppKWMn_ytWtM2txTOUUKOOt4aZ-eXPAUiwrMSW9jQ=.4f085fcb-ba7e-4aa8-af1f-844772f53725@github.com>
Message-ID: <egi_U2wOcupvLbwvVa0rI4lGcSbviubkrUhGQB0ImZ8=.539bab92-ff08-4f51-91c8-7b59fc7bea8e@github.com>

On Thu, 11 Aug 2022 21:36:41 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <Wb8xmhMKE4EkMWDKiqT9RZhBHOg8kK0x651F-BOPKQ0=.f07db213-d07f-4753-9e17-a4c308a7fc1b@github.com>

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_<cpu\>.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: <rd8S2oUSNoFAG-c2leFitW_qfCFwfOmpjKTD9pleVAc=.c99a6691-4ae2-4036-b950-f93182a05252@github.com>
References: <rd8S2oUSNoFAG-c2leFitW_qfCFwfOmpjKTD9pleVAc=.c99a6691-4ae2-4036-b950-f93182a05252@github.com>
Message-ID: <RLXViJkmhbM00HJuMsvOWsUr1mz1aa0lbq0Igv4sk8Y=.b49edbc5-8841-473e-b692-b04890a95608@github.com>

On Thu, 11 Aug 2022 07:12:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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 <djelinski at openjdk.org>
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: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
References: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
Message-ID: <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>

> 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 <iklam at openjdk.org> wrote:

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.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: <fwawhxye_3D7mpQ2NgUB7bZ8b0gjW05f2DJDj86740Y=.a7dee5df-eef3-447b-8649-0fa42e752c40@github.com>

On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.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: <HxVtyVfQxeJJ5dG3jxyj0r1KfyBikvWgG7FhLS4tvM0=.53c5204b-dae8-48ae-8e3f-85e46129d944@github.com>

On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.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: <b2VVq8OvUN5lewXtuj7RgqdZ9Qa_GnDKJ-Kt5th1x-s=.e192ec43-4c32-41bb-8bc0-6cc4d4f51ed2@github.com>

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.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: <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>
References: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
 <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>
Message-ID: <m1vXxdK-AyBbEhGLxTOKwM1KEybrzk6qfE3wyAxXyq0=.d9f12801-a965-44e5-b42b-9856233e0ee7@github.com>

On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls <kevinw at openjdk.org> 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: <CAJAALpCASh2vVKVsC-vVj6wyTao72PmF52rMVv3dno2OWKdb_Q@mail.gmail.com>

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: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>

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: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <7O38TdppE3N6L3AVwmwskuzGAMYhslZEk6LNPRPvddk=.ee44fa2d-5624-42a4-a757-7c4b74874699@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
Message-ID: <Z5Nh4_th5JdryBuKpHTcBe8RAzs5kvPnONHdkwlCobc=.44d8ee2c-43ae-4c31-992d-b9f79cfb06f9@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 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: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <HLpZp-J-gPnYyisAFC2o37e6OI3JaYya9E8N9bOO8Uw=.92d03070-6dcc-4417-b253-8d30bcfe6186@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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: <V59YZrEfZxxUFufOBtmbbO_GvDOjEJ_5gneKzI8WbJc=.7a39a0bb-38ed-4845-98da-cafbcc2e1fd9@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <V59YZrEfZxxUFufOBtmbbO_GvDOjEJ_5gneKzI8WbJc=.7a39a0bb-38ed-4845-98da-cafbcc2e1fd9@github.com>
Message-ID: <k7hxVu5vy_goPx_M3jKW1sj1K6n9nHRXX98LaTMYf-g=.4c3b3576-bdea-45fc-a907-65cf8fd5eefc@github.com>

On Thu, 11 Aug 2022 16:45:54 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <z6Zu0EJkgkAEEo3SdyI3L9Ugrh0n5u_ePzYzp2GtXHw=.817d4c98-15b5-4ad0-8673-63c362735f5e@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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: <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>
References: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
 <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>
Message-ID: <RkyPk3haDaVsC5sUEoJktiMPIDsPIzIPLzWLCkfv5MI=.47dc0d5f-6fb2-41cb-b6a4-8d1e899ea500@github.com>

On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls <kevinw at openjdk.org> 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: <Wb8xmhMKE4EkMWDKiqT9RZhBHOg8kK0x651F-BOPKQ0=.f07db213-d07f-4753-9e17-a4c308a7fc1b@github.com>
References: <Wb8xmhMKE4EkMWDKiqT9RZhBHOg8kK0x651F-BOPKQ0=.f07db213-d07f-4753-9e17-a4c308a7fc1b@github.com>
Message-ID: <4mLOF33JCf-dylPUyy7SeZeFYmIOKcvQz9LKzCFAlJ4=.3a3703b5-3216-49a0-b2dc-de2ebe7f6b2c@github.com>

On Thu, 11 Aug 2022 20:14:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
Message-ID: <hTriiUGiOdX19F7kEtSKxqT_F4wMW3WMlFDQd3S1urE=.467382a1-a23f-424e-9dc1-631a17cef62f@github.com>

On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> 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: <CAJAALpCASh2vVKVsC-vVj6wyTao72PmF52rMVv3dno2OWKdb_Q@mail.gmail.com>
References: <CAJAALpCASh2vVKVsC-vVj6wyTao72PmF52rMVv3dno2OWKdb_Q@mail.gmail.com>
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: <CAJAALpCASh2vVKVsC-vVj6wyTao72PmF52rMVv3dno2OWKdb_Q@mail.gmail.com>
 <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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
Message-ID: <x14g8lbJ3cgFzh6a4hZfc0ueHeYQPxymrutIPuxho48=.4bd2829c-b02a-460b-a7cc-6e0931f71b28@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 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 <discuss-retn at openjdk.org> on behalf of Severin Gehwolf <sgehwolf at redhat.com>
Date: Wednesday, August 17, 2022 at 2:00 AM
To: "discuss at openjdk.org" <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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
Message-ID: <TDhyeA5fUlsgL8H8l-nVSoSDptqKD8S6b_XijJFiSl8=.ba404cc3-fb87-4569-a62a-9eb28e107f2c@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:

  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: <TDhyeA5fUlsgL8H8l-nVSoSDptqKD8S6b_XijJFiSl8=.ba404cc3-fb87-4569-a62a-9eb28e107f2c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <TDhyeA5fUlsgL8H8l-nVSoSDptqKD8S6b_XijJFiSl8=.ba404cc3-fb87-4569-a62a-9eb28e107f2c@github.com>
Message-ID: <dJLMThzCKPjvLMN38apZcIETd5lIGfb7kr6q34YK-c4=.75cc1f6b-2efb-4342-a508-65af41bb48ad@github.com>

On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> 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: <TDhyeA5fUlsgL8H8l-nVSoSDptqKD8S6b_XijJFiSl8=.ba404cc3-fb87-4569-a62a-9eb28e107f2c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <TDhyeA5fUlsgL8H8l-nVSoSDptqKD8S6b_XijJFiSl8=.ba404cc3-fb87-4569-a62a-9eb28e107f2c@github.com>
Message-ID: <T8VYtp7O7CboNhF4HfCJ5AswuF_F_7GrjeNFZTK-b2Y=.4d4fe550-a721-4a14-9ea8-501249cdecb0@github.com>

On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> 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: <T8VYtp7O7CboNhF4HfCJ5AswuF_F_7GrjeNFZTK-b2Y=.4d4fe550-a721-4a14-9ea8-501249cdecb0@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <TDhyeA5fUlsgL8H8l-nVSoSDptqKD8S6b_XijJFiSl8=.ba404cc3-fb87-4569-a62a-9eb28e107f2c@github.com>
 <T8VYtp7O7CboNhF4HfCJ5AswuF_F_7GrjeNFZTK-b2Y=.4d4fe550-a721-4a14-9ea8-501249cdecb0@github.com>
Message-ID: <HeZ_tk7UvNgi_y0doZkiMWaulJEvWqrFjhnrzfqciLE=.a0fcded5-26eb-482a-990b-725ed38094df@github.com>

On Thu, 18 Aug 2022 08:57:19 GMT, Dean Long <dlong at openjdk.org> 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: <ZcA4CeBYdneqmWEUWv4XnwuQzoritpYxZDpuEr9KLPk=.99fcfdd6-e6e4-49cd-b607-23e6eba787d0@github.com>

On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <ZcA4CeBYdneqmWEUWv4XnwuQzoritpYxZDpuEr9KLPk=.99fcfdd6-e6e4-49cd-b607-23e6eba787d0@github.com>
References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com>
 <ZcA4CeBYdneqmWEUWv4XnwuQzoritpYxZDpuEr9KLPk=.99fcfdd6-e6e4-49cd-b607-23e6eba787d0@github.com>
Message-ID: <8lDRYPoZ09b30Bkzj_bJ9rzZWgIDu1LAMHcpRW5M9v0=.dd68c09f-fb17-431e-8803-fe546f42622c@github.com>

On Thu, 18 Aug 2022 12:30:57 GMT, Alan Bateman <alanb at openjdk.org> 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>
 <ZcA4CeBYdneqmWEUWv4XnwuQzoritpYxZDpuEr9KLPk=.99fcfdd6-e6e4-49cd-b607-23e6eba787d0@github.com>
 <8lDRYPoZ09b30Bkzj_bJ9rzZWgIDu1LAMHcpRW5M9v0=.dd68c09f-fb17-431e-8803-fe546f42622c@github.com>
Message-ID: <MmdaD3JvhBtgaAGTcr5KktJS3Ti6AmNIgVY288SHueU=.9672774b-e39c-4d29-90cb-106c1d9f4212@github.com>

On Thu, 18 Aug 2022 12:42:48 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <HeZ_tk7UvNgi_y0doZkiMWaulJEvWqrFjhnrzfqciLE=.a0fcded5-26eb-482a-990b-725ed38094df@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <TDhyeA5fUlsgL8H8l-nVSoSDptqKD8S6b_XijJFiSl8=.ba404cc3-fb87-4569-a62a-9eb28e107f2c@github.com>
 <T8VYtp7O7CboNhF4HfCJ5AswuF_F_7GrjeNFZTK-b2Y=.4d4fe550-a721-4a14-9ea8-501249cdecb0@github.com>
 <HeZ_tk7UvNgi_y0doZkiMWaulJEvWqrFjhnrzfqciLE=.a0fcded5-26eb-482a-990b-725ed38094df@github.com>
Message-ID: <tpGScQBJnGiCww2RGAYQQcUl9Omkpb-h7iYi-FbhEq4=.aac57b71-0eef-484f-8485-f7187f2d9916@github.com>

On Thu, 18 Aug 2022 09:32:54 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> 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: <x7mTTS-BTVf_mTOk0VswaYclodr3dBpLG4ebIrkEhpY=.4c408a16-7126-4705-8d68-ce22191e4a25@github.com>

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.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: <tpGScQBJnGiCww2RGAYQQcUl9Omkpb-h7iYi-FbhEq4=.aac57b71-0eef-484f-8485-f7187f2d9916@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <TDhyeA5fUlsgL8H8l-nVSoSDptqKD8S6b_XijJFiSl8=.ba404cc3-fb87-4569-a62a-9eb28e107f2c@github.com>
 <T8VYtp7O7CboNhF4HfCJ5AswuF_F_7GrjeNFZTK-b2Y=.4d4fe550-a721-4a14-9ea8-501249cdecb0@github.com>
 <HeZ_tk7UvNgi_y0doZkiMWaulJEvWqrFjhnrzfqciLE=.a0fcded5-26eb-482a-990b-725ed38094df@github.com>
 <tpGScQBJnGiCww2RGAYQQcUl9Omkpb-h7iYi-FbhEq4=.aac57b71-0eef-484f-8485-f7187f2d9916@github.com>
Message-ID: <om9lWFAr3akpMOG6k6Jx2CKwz9xqVBLz_ZszPywWNbc=.12e0e497-0316-4873-a544-b99f2e36d191@github.com>

On Fri, 19 Aug 2022 01:17:14 GMT, Dean Long <dlong at openjdk.org> 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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
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: <GnWtnU30MGBSH0fPByJZVx9uRj8vYkiSY9adI4ozGfk=.d68013c2-717b-422d-a8f1-ff3cf3ce8555@github.com>

On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <JDYSCwmtQCai9-f-_vQZWQlgIGFuBe4BcvHHOVgkcB0=.3088d4cb-3b59-43f5-b836-fe7a4015a0c6@github.com>

On Fri, 12 Aug 2022 13:20:32 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <L2AqTj2Z5jlFM1J8XGA3tODvss9GwQ5wxe4HoYI7qtU=.e2aeb3cc-c0de-4f69-9073-f54e3e937db3@github.com>

On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.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 <iklam at openjdk.org>
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: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>

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: <Wb8xmhMKE4EkMWDKiqT9RZhBHOg8kK0x651F-BOPKQ0=.f07db213-d07f-4753-9e17-a4c308a7fc1b@github.com>
 <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 <cjplummer at openjdk.org> 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: <V59YZrEfZxxUFufOBtmbbO_GvDOjEJ_5gneKzI8WbJc=.7a39a0bb-38ed-4845-98da-cafbcc2e1fd9@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <V59YZrEfZxxUFufOBtmbbO_GvDOjEJ_5gneKzI8WbJc=.7a39a0bb-38ed-4845-98da-cafbcc2e1fd9@github.com>
Message-ID: <D8jUYOMpBSXKRl20BYMr3DPvVtCimjgrOEGZwn68mZM=.8ae205b6-9788-4259-9cbd-9a4cf463d157@github.com>

On Thu, 11 Aug 2022 16:45:54 GMT, Chris Plummer <cjplummer at openjdk.org> 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<StackFrame>, Iterator<StackFrame> 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: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <TrZ_D2g9H4v54x1t4KeoA-OTHI31DTVMf7aFU6sjq2o=.e1f500cc-a526-42a3-8496-166c1c6f687b@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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: <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>
References: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
 <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>
Message-ID: <hvx9oJMUlFX4Bf0q3nmB3SoNQscauGl-kzKn7qSofXM=.ff1853b2-8371-41ef-b515-4abaf063cd77@github.com>

On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls <kevinw at openjdk.org> 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: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <SEjLbNITp0dcxRVQ8zXuhxapMh9F2aS-kfGC1kVRLII=.8edb1b3a-be15-4a3c-9f8f-d01cca115657@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <Lru9gwGomh6rLr2cE368n4Z6RopDrctLbqorcYnvw-k=.e1e94fb2-34f4-4dc5-bc86-4106b816920f@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

This pull request has now been integrated.

Changeset: 37c0a136
Author:    Andrey Turbanov <aturbanov at openjdk.org>
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: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
References: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
Message-ID: <N_Sz1Cqc5pDRtklSsFjpufe4CACGThoa1HpeJzacLIk=.f69ba539-957b-420d-a2b9-c14dd24d0815@github.com>

On Thu, 11 Aug 2022 18:27:12 GMT, Kevin Walls <kevinw at openjdk.org> 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 <kevinw at openjdk.org>
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: <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>
References: <v8-dWk4-nAXmKjTAICcLB6ihbdsdlEgcUfY9wa5BkMk=.234ace37-1a38-48f1-8b63-35fb5bb34fb8@github.com>
 <i-zylsKw-iOod3732w9KCynVApvSaE8nXpzZH_OPvyI=.0048fc13-80b7-410f-9272-ed15c99fabf2@github.com>
Message-ID: <LbuaSnokMDXeKCJhn4ICh0SAHIXv-qFrNf_7ZSTarW0=.7df3da48-9c40-40f3-8e76-43813d2c79e2@github.com>

On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls <kevinw at openjdk.org> 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: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
References: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
Message-ID: <x-ioq74RdgkoAkUPK5GsyLI3hPjcI7_quZQ7H8gA2lw=.32acc26d-caf3-425c-a53e-fb0ac3e019fd@github.com>

On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel <hseigel at openjdk.org> 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: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
References: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
Message-ID: <2xa6alby12RtnUgyfrQxWnEG4156DgrJzvVVwwg779M=.541e9c79-388f-4233-b2d8-fa706bba5218@github.com>

On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel <hseigel at openjdk.org> 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: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
References: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
Message-ID: <pnDR-3Tu4ANbay6qGYewB3HOTbAweSaJRVdljcyAo-w=.8695cd90-0ce3-407f-995f-6b48a65b25bd@github.com>

On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel <hseigel at openjdk.org> 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: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
References: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
Message-ID: <vQnEKUHzd_mET-3TKQtheNee7eleexjegF8hpWNuoGg=.5276fa6b-32a1-45bc-a9f7-891b8c20df8f@github.com>

On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel <hseigel at openjdk.org> 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: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
References: <Zq2huavnWUXXyFsfA0xxUUiw3Eg_zqt4Yh60eJ61nLM=.584682af-ee88-45d8-9080-87bcad991262@github.com>
Message-ID: <EW6XhUGQWFJQgafAfMgxBz5cdu6wHy68qVHPqMFY2Ec=.c24a94cf-d19b-4046-89e2-9eef1f21d7da@github.com>

On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel <hseigel at openjdk.org> 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 <hseigel at openjdk.org>
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: <Wb8xmhMKE4EkMWDKiqT9RZhBHOg8kK0x651F-BOPKQ0=.f07db213-d07f-4753-9e17-a4c308a7fc1b@github.com>
References: <Wb8xmhMKE4EkMWDKiqT9RZhBHOg8kK0x651F-BOPKQ0=.f07db213-d07f-4753-9e17-a4c308a7fc1b@github.com>
Message-ID: <v2PmcJPBY0z30LlDkehyff0DdF8x3jjfxFSGYkKIZPw=.cdfb70f7-048a-4a26-b4b2-3ac3f806089a@github.com>

On Thu, 11 Aug 2022 20:14:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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 <dcubed at openjdk.org>
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: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
References: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
Message-ID: <-fFQHKwyaYq2C49OBjNsRgG-hHdWe1WFYw1SBKa1Y1Q=.79ec9ed2-62d2-4e47-92c7-5d9ce339ecfd@github.com>

On Thu, 11 Aug 2022 20:15:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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 <dcubed at openjdk.org>
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: <Wb8xmhMKE4EkMWDKiqT9RZhBHOg8kK0x651F-BOPKQ0=.f07db213-d07f-4753-9e17-a4c308a7fc1b@github.com>
References: <Wb8xmhMKE4EkMWDKiqT9RZhBHOg8kK0x651F-BOPKQ0=.f07db213-d07f-4753-9e17-a4c308a7fc1b@github.com>
Message-ID: <wl4BDA6gOFfMMrYp7OWTMGacAFxJCdYTEa5pDg-v8YQ=.6a0b0284-0330-4e83-a47a-a498b5c7f626@github.com>

On Thu, 11 Aug 2022 20:14:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
References: <hqA10lh6lc7Yvv4RxVL_bTgtoY6Aohdimc_N-bp1a7c=.71319764-8678-4bb6-9222-5b929c36047e@github.com>
Message-ID: <xxb2PAPDrhrXxT9aqynoGJ3my2svkscxJIDwVby-7jY=.3c642a5b-aa6b-4080-9304-6a1c851bedb9@github.com>

On Thu, 11 Aug 2022 20:15:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>

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: <tnXd7aHgxveRNYz8XrippXvXw4_vqWK04yiImahm75c=.7fd608fa-1dc2-455f-b687-33c28a577cc0@github.com>

On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>

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: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
References: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
Message-ID: <3l6qAT71ntWNAxZPuhAkUxGrdWS7XETq_71fiVChw9g=.db560545-1c3d-4f33-9e0c-9f015ba97fbd@github.com>

On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
References: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
Message-ID: <F8UTjXMQ_bWoB106CiwRWttGVYyJka5YDZck5RNX6Xc=.f517fd2e-f37f-4b44-8f44-72d2c62eedbe@github.com>

On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
References: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
Message-ID: <6gfGLU228_S7J7hqrdwMmiZjtLA5jChCjZwwwQr9xyY=.5e98cab9-a590-4bdd-95c3-af1208ee0547@github.com>

On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
Message-ID: <ZJ8U2ZS844jSAik9TKku6BT15QXyIoCTrH8dyVBfCxI=.36c7c8bf-aa43-4b45-8e6c-ea9fd7ce6e67@github.com>

> 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: <D8jUYOMpBSXKRl20BYMr3DPvVtCimjgrOEGZwn68mZM=.8ae205b6-9788-4259-9cbd-9a4cf463d157@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <V59YZrEfZxxUFufOBtmbbO_GvDOjEJ_5gneKzI8WbJc=.7a39a0bb-38ed-4845-98da-cafbcc2e1fd9@github.com>
 <D8jUYOMpBSXKRl20BYMr3DPvVtCimjgrOEGZwn68mZM=.8ae205b6-9788-4259-9cbd-9a4cf463d157@github.com>
Message-ID: <5U9Ck8L2VlAzmXM-yq25ILdiMI-TAQ_hxo17KkW1UBY=.3e61878b-2e8b-4e24-9177-fa7826c4e6fa@github.com>

On Fri, 19 Aug 2022 22:41:00 GMT, Alex Menkov <amenkov at openjdk.org> 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: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
References: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
Message-ID: <5weg4u1VQuKzp9i6cqSJLcS3Hf2rxjNcTot30X-xytY=.ea00954b-0147-425f-83db-9afe1bdd7708@github.com>

On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
References: <vXNsNhFUq5ZLVuqdU-ygqsA3Y1Al_iJzKzSkH1TGyHc=.17b72b9d-4c40-4ed1-bc59-d30cc238ed88@github.com>
Message-ID: <NPYImvQJ6G28VPbrfBIWiYUSqeXeW-L6N7XQHSfwqv0=.c3d659ba-4295-4c42-a5c4-6d1bfc3e7962@github.com>

On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken <mbaesken at openjdk.org> 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 <mbaesken at openjdk.org>
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: <mCboUEnhFmKJZRqHgvI6uktdD2HoqjELHyBfeUqUkXw=.0359548f-a15e-4904-9013-210827f237b5@github.com>

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: <ZJ8U2ZS844jSAik9TKku6BT15QXyIoCTrH8dyVBfCxI=.36c7c8bf-aa43-4b45-8e6c-ea9fd7ce6e67@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <ZJ8U2ZS844jSAik9TKku6BT15QXyIoCTrH8dyVBfCxI=.36c7c8bf-aa43-4b45-8e6c-ea9fd7ce6e67@github.com>
Message-ID: <q0EvB1aeJrLab-HQvjZ1ma4A0_RBqdQeFBGGtnGi4Lk=.e44d4519-6f88-4cc8-b69d-71fce246c625@github.com>

On Wed, 24 Aug 2022 05:08:40 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <V59YZrEfZxxUFufOBtmbbO_GvDOjEJ_5gneKzI8WbJc=.7a39a0bb-38ed-4845-98da-cafbcc2e1fd9@github.com>
 <D8jUYOMpBSXKRl20BYMr3DPvVtCimjgrOEGZwn68mZM=.8ae205b6-9788-4259-9cbd-9a4cf463d157@github.com>
 <5U9Ck8L2VlAzmXM-yq25ILdiMI-TAQ_hxo17KkW1UBY=.3e61878b-2e8b-4e24-9177-fa7826c4e6fa@github.com>
Message-ID: <hNNnFque_WK3wzDCBN67D9jFphW1aNf1xhYSDhTY03g=.5878b84c-1fc2-48a7-9838-d8138adba6b8@github.com>

On Wed, 24 Aug 2022 05:03:43 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <mCboUEnhFmKJZRqHgvI6uktdD2HoqjELHyBfeUqUkXw=.0359548f-a15e-4904-9013-210827f237b5@github.com>
References: <mCboUEnhFmKJZRqHgvI6uktdD2HoqjELHyBfeUqUkXw=.0359548f-a15e-4904-9013-210827f237b5@github.com>
Message-ID: <7y5EOBt873C0ZyAAvKQJkq39E8ir8SULO44CXZxkzx8=.52f8ed97-ad27-47d7-855e-cb4db7ae3ec1@github.com>

On Wed, 24 Aug 2022 18:57:13 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <mCboUEnhFmKJZRqHgvI6uktdD2HoqjELHyBfeUqUkXw=.0359548f-a15e-4904-9013-210827f237b5@github.com>
References: <mCboUEnhFmKJZRqHgvI6uktdD2HoqjELHyBfeUqUkXw=.0359548f-a15e-4904-9013-210827f237b5@github.com>
Message-ID: <Sos3QedqDQkxcs8wjAhdvwcE0WF73aKVvk1i8dYDFzU=.e0162fe9-bb18-49fd-a7e1-1f8f27935f83@github.com>

> 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: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
References: <QqirJHjU4EcC1ypgCdCKv38A7Cys1IqoATxKepQITgo=.645ef76c-56b2-4a57-86eb-ae532d7aef06@github.com>
Message-ID: <yU0OtWxjTwBPHWS6-F6vapliyDym2BWIfG3bPk_v1Xg=.a7b7b5d0-4dfc-438a-a30b-dcf5db6cec03@github.com>

On Mon, 23 May 2022 07:28:41 GMT, Yi Yang <yyang at openjdk.org> 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: <hNNnFque_WK3wzDCBN67D9jFphW1aNf1xhYSDhTY03g=.5878b84c-1fc2-48a7-9838-d8138adba6b8@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <V59YZrEfZxxUFufOBtmbbO_GvDOjEJ_5gneKzI8WbJc=.7a39a0bb-38ed-4845-98da-cafbcc2e1fd9@github.com>
 <D8jUYOMpBSXKRl20BYMr3DPvVtCimjgrOEGZwn68mZM=.8ae205b6-9788-4259-9cbd-9a4cf463d157@github.com>
 <5U9Ck8L2VlAzmXM-yq25ILdiMI-TAQ_hxo17KkW1UBY=.3e61878b-2e8b-4e24-9177-fa7826c4e6fa@github.com>
 <hNNnFque_WK3wzDCBN67D9jFphW1aNf1xhYSDhTY03g=.5878b84c-1fc2-48a7-9838-d8138adba6b8@github.com>
Message-ID: <MwlNK9Wa8AYbIm09k-gqdX7PSAjt5qkLgJ7IMepHtmY=.fe7802db-b93e-40fe-802f-1e2d4331bc0b@github.com>

On Wed, 24 Aug 2022 19:37:11 GMT, Alex Menkov <amenkov at openjdk.org> 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: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>

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: <Sos3QedqDQkxcs8wjAhdvwcE0WF73aKVvk1i8dYDFzU=.e0162fe9-bb18-49fd-a7e1-1f8f27935f83@github.com>
References: <mCboUEnhFmKJZRqHgvI6uktdD2HoqjELHyBfeUqUkXw=.0359548f-a15e-4904-9013-210827f237b5@github.com>
 <Sos3QedqDQkxcs8wjAhdvwcE0WF73aKVvk1i8dYDFzU=.e0162fe9-bb18-49fd-a7e1-1f8f27935f83@github.com>
Message-ID: <eNCazK2ieyFyC28bVYzQQ8Syk3X-qQVmywBG2cR0g_g=.a88f45dc-d3b9-4a7b-a95f-41ab705ef033@github.com>

On Wed, 24 Aug 2022 20:03:48 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>
References: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>
Message-ID: <DdIxbQnyCt2OeQJm5epyfbzf0uFGG_yAl_1WK4_fC3Q=.a773c1ad-81e0-4027-b13a-e68532f99112@github.com>

On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <ZJ8U2ZS844jSAik9TKku6BT15QXyIoCTrH8dyVBfCxI=.36c7c8bf-aa43-4b45-8e6c-ea9fd7ce6e67@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <ZJ8U2ZS844jSAik9TKku6BT15QXyIoCTrH8dyVBfCxI=.36c7c8bf-aa43-4b45-8e6c-ea9fd7ce6e67@github.com>
Message-ID: <_BV0F_eLC0wcpOz6SmpK6rR9Uk96B5yoSvyjNXvcuaU=.ac5959b4-7e5c-4293-b4d5-4b8fb8c667ad@github.com>

On Wed, 24 Aug 2022 05:08:40 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>
References: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>
Message-ID: <aIbt1DCh7od1kpCgW5oM_RACiNdAsrra6wc9tu9sG0A=.6253d3a7-7a7a-45b7-ac6a-1b9ae9e1322f@github.com>

On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
Message-ID: <w2RywYEzU1f4spITc20-TFlGpG_2o2isAZAbHhDmw6o=.fbb76765-be08-423a-911a-20d90709f54b@github.com>

> 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: <w2RywYEzU1f4spITc20-TFlGpG_2o2isAZAbHhDmw6o=.fbb76765-be08-423a-911a-20d90709f54b@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <w2RywYEzU1f4spITc20-TFlGpG_2o2isAZAbHhDmw6o=.fbb76765-be08-423a-911a-20d90709f54b@github.com>
Message-ID: <DV4oVMx-XrfKbyWIcKE3RttWpghEwFy2MiwVSe7bFs0=.96aaee5a-50ba-4444-94fa-d549c2314faf@github.com>

On Thu, 25 Aug 2022 15:15:38 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>
References: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>
Message-ID: <ugNn8vzMXuSYqI_UOv8NDw4eduLZZmWuRh4LyzXgozs=.53cd6a26-bc6c-4424-8226-35bfeed82821@github.com>

On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <w2RywYEzU1f4spITc20-TFlGpG_2o2isAZAbHhDmw6o=.fbb76765-be08-423a-911a-20d90709f54b@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <w2RywYEzU1f4spITc20-TFlGpG_2o2isAZAbHhDmw6o=.fbb76765-be08-423a-911a-20d90709f54b@github.com>
Message-ID: <aMZSfrFGa9ze99Auz1JNO5L0cH3S_hs94hgVRI7RDCs=.1a2c3cd5-493a-49ad-b0a3-83114b7b65d4@github.com>

On Thu, 25 Aug 2022 15:15:38 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
Message-ID: <j38Q9EIvuyitc1XuSbg6Ze8Gq9RQbSTh5Ea3FSEnFe0=.5d6cfc8c-3def-4b27-bff3-adedf6d17021@github.com>

> 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: <j38Q9EIvuyitc1XuSbg6Ze8Gq9RQbSTh5Ea3FSEnFe0=.5d6cfc8c-3def-4b27-bff3-adedf6d17021@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <j38Q9EIvuyitc1XuSbg6Ze8Gq9RQbSTh5Ea3FSEnFe0=.5d6cfc8c-3def-4b27-bff3-adedf6d17021@github.com>
Message-ID: <6--cO39SqaueJNBTW1HzkEXkgeWQsCnGUjp0jKxgIZM=.216fc65f-fa81-4a13-878c-90b1bd5b58cf@github.com>

On Thu, 25 Aug 2022 19:14:21 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <TZ9fgHangXcZltInDsp83szfjsMIuT4-rlB3DFzR92o=.cdcaab39-5cfd-46a5-aad7-59e56f45175c@github.com>

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: <j38Q9EIvuyitc1XuSbg6Ze8Gq9RQbSTh5Ea3FSEnFe0=.5d6cfc8c-3def-4b27-bff3-adedf6d17021@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <j38Q9EIvuyitc1XuSbg6Ze8Gq9RQbSTh5Ea3FSEnFe0=.5d6cfc8c-3def-4b27-bff3-adedf6d17021@github.com>
Message-ID: <oB96y1XUPmGVivG_xoLtSoVFqv2ID7JDDVM_7dnBtz4=.67a8cf5f-f54e-4ea6-a705-e64c3464c17a@github.com>

On Thu, 25 Aug 2022 19:14:21 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <j38Q9EIvuyitc1XuSbg6Ze8Gq9RQbSTh5Ea3FSEnFe0=.5d6cfc8c-3def-4b27-bff3-adedf6d17021@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
 <j38Q9EIvuyitc1XuSbg6Ze8Gq9RQbSTh5Ea3FSEnFe0=.5d6cfc8c-3def-4b27-bff3-adedf6d17021@github.com>
Message-ID: <qGQgC4lELoSVnpAbg8ZEAVEPxt0DLu4KUZ08dlR0HNQ=.d34a99f5-1325-4cab-8e5b-f249ce4d9ec2@github.com>

On Thu, 25 Aug 2022 19:14:21 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com>
Message-ID: <WgCg6UeWrxKdC2cL9nb7p8YgpEggwzxgPZzdEmIWrW8=.c6fafa7d-d1c9-407a-b2f4-301da2e43590@github.com>

On Fri, 19 Aug 2022 10:25:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> 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: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
References: <hwvqu1_Y82PKsjFdEpnJSQ8yohzYrkdbld809NVGYUo=.c2b8474e-786f-4438-bb5d-c77640807c28@github.com>
Message-ID: <DzIUhp4DlQb2I589V8R-b0S6vNFeQtiNwFsqJDHMBQ0=.9cb38222-4fed-417b-8778-1dcbacf73360@github.com>

On Thu, 11 Aug 2022 16:03:58 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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: <WgCg6UeWrxKdC2cL9nb7p8YgpEggwzxgPZzdEmIWrW8=.c6fafa7d-d1c9-407a-b2f4-301da2e43590@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com>
 <WgCg6UeWrxKdC2cL9nb7p8YgpEggwzxgPZzdEmIWrW8=.c6fafa7d-d1c9-407a-b2f4-301da2e43590@github.com>
Message-ID: <NJukAvROPuFhoagB_nW4w12fzix_ImyNMr2ONknJzQI=.2572cb09-ba40-41f5-a717-6efc178828bf@github.com>

On Thu, 25 Aug 2022 22:04:47 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>
References: <ZUEXGoAvgfLtMuf7Au2Eio1Q81kS_iYI6pqtcWrWFTE=.570fa32e-c8ff-4ae1-81f2-f356d0d3fe16@github.com>
Message-ID: <nduMatFk5p6OAHf-hZUMFVpXcqt8UIr5RZGF7U4dZw8=.427c9d2e-315a-4d4a-8d24-dfe5544cb241@github.com>

On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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: <mCboUEnhFmKJZRqHgvI6uktdD2HoqjELHyBfeUqUkXw=.0359548f-a15e-4904-9013-210827f237b5@github.com>
References: <mCboUEnhFmKJZRqHgvI6uktdD2HoqjELHyBfeUqUkXw=.0359548f-a15e-4904-9013-210827f237b5@github.com>
Message-ID: <x9ZI9J8tHwvuoe_eTscufZNYJ1EtUZJEF5jl47eelDM=.49995e77-9136-4830-a7c8-4e896f0d080f@github.com>

On Wed, 24 Aug 2022 18:57:13 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
Message-ID: <xVPnH0l7FaOqKYyY-xlhvkC5mJUVKMkUOj1gnhnw5Gg=.77ac62f6-0e60-4cf6-b4d7-748d150c9361@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 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: <NJukAvROPuFhoagB_nW4w12fzix_ImyNMr2ONknJzQI=.2572cb09-ba40-41f5-a717-6efc178828bf@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com>
 <WgCg6UeWrxKdC2cL9nb7p8YgpEggwzxgPZzdEmIWrW8=.c6fafa7d-d1c9-407a-b2f4-301da2e43590@github.com>
 <NJukAvROPuFhoagB_nW4w12fzix_ImyNMr2ONknJzQI=.2572cb09-ba40-41f5-a717-6efc178828bf@github.com>
Message-ID: <Rp7aJoZIOjjm2aeBwcBkNpKSihEV5mINBKdn4IB-kHY=.824aa30d-e5c5-4bd6-a30d-e6231bc1ad82@github.com>

On Thu, 25 Aug 2022 22:20:43 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>

> 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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@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.

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

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: <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com>
 <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
Message-ID: <9WSxalTKUe7L5hNTqGHMB57ja3Q2dMZVP3mUmZwMy2c=.0890a5cb-601f-45da-90da-ba4dc9fec21b@github.com>

On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
Message-ID: <rB8VVzCxSquSgkMJ7xMO4DCypmwjp8dXeyVjHPeZvHY=.5bb1f370-f262-44ea-b5f5-0cc319de4f89@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:

  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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
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: <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com>
 <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
Message-ID: <u5Q975-TcDPUgN5A6-u4Flo-nbg05kK18nNCjphq7BA=.2db9f233-2bd2-4341-8ea8-42ce55d475df@github.com>

On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>

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: <Rp7aJoZIOjjm2aeBwcBkNpKSihEV5mINBKdn4IB-kHY=.824aa30d-e5c5-4bd6-a30d-e6231bc1ad82@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
 <7afB6TviqSb7XR4rMLspDYFuBPSQi9Ya5RwkSGo9dSQ=.bf3acd8e-6a68-41cd-a378-2f845ecafec7@github.com>
 <WgCg6UeWrxKdC2cL9nb7p8YgpEggwzxgPZzdEmIWrW8=.c6fafa7d-d1c9-407a-b2f4-301da2e43590@github.com>
 <NJukAvROPuFhoagB_nW4w12fzix_ImyNMr2ONknJzQI=.2572cb09-ba40-41f5-a717-6efc178828bf@github.com>
 <Rp7aJoZIOjjm2aeBwcBkNpKSihEV5mINBKdn4IB-kHY=.824aa30d-e5c5-4bd6-a30d-e6231bc1ad82@github.com>
Message-ID: <vnN1S9z5Wr-zhrcXiiwMnXHot1TPgl4JwIUTh6jItOo=.3121ebbc-ecf0-48a6-a86f-4746e04f025d@github.com>

On Fri, 26 Aug 2022 09:25:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> 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: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
References: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
Message-ID: <vTusD4GhRJk3sJcfXZg2CXrYTfOe0K2ztAdsBtp576s=.1506a1c2-519e-41c9-a9f9-3eb87989eb01@github.com>

On Fri, 26 Aug 2022 20:13:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <vTusD4GhRJk3sJcfXZg2CXrYTfOe0K2ztAdsBtp576s=.1506a1c2-519e-41c9-a9f9-3eb87989eb01@github.com>
References: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
 <vTusD4GhRJk3sJcfXZg2CXrYTfOe0K2ztAdsBtp576s=.1506a1c2-519e-41c9-a9f9-3eb87989eb01@github.com>
Message-ID: <UV_4vpQPlBk4UAtnUGzO-i6v9_xASrip04V8xDSXYfY=.cd75a370-05a2-4d52-8d4a-c2938d869211@github.com>

On Fri, 26 Aug 2022 20:42:01 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
References: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
Message-ID: <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>

> 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: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
References: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
Message-ID: <GtF1BvyHs4v4JIvKHSKvHRbkJKNICesyleuTSO1eaQ0=.42ed0f86-bc98-41b8-bc20-4608e5446787@github.com>

On Thu, 11 Aug 2022 21:12:08 GMT, Bill Huang <duke at openjdk.org> 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: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
References: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
Message-ID: <vCxljgc7DetjbTPerv8PS5riL6J8iEZimuNGaVWiHkM=.5e694e06-8e7c-4aae-a4df-85b2a67c1f3a@github.com>

On Mon, 22 Aug 2022 22:51:50 GMT, Bill Huang <duke at openjdk.org> 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: <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>
References: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
 <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>
Message-ID: <eQp8eUrovphH0ftuRPBDXdbj0hmEFNzoHz3g5A_QohQ=.459e4796-ccb5-4446-9757-a74113f9d78b@github.com>

On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com>
 <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
Message-ID: <Fx0sUsiZOAiht4b3SZckjMSBkDKSQ-Rv7uMRggnzWXk=.302f0798-4fcb-4056-a4a2-6aa1b835191c@github.com>

On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <xFPbhMPw7-5NGhEJ_D1F6SOdE9feyN_DpYpIQDwUvRc=.1bfdc809-2606-4f62-8738-1bd9ed53b446@github.com>

On Mon, 22 Aug 2022 15:06:31 GMT, Daniel Skantz <duke at openjdk.org> 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: <Fx0sUsiZOAiht4b3SZckjMSBkDKSQ-Rv7uMRggnzWXk=.302f0798-4fcb-4056-a4a2-6aa1b835191c@github.com>
References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com>
 <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
 <Fx0sUsiZOAiht4b3SZckjMSBkDKSQ-Rv7uMRggnzWXk=.302f0798-4fcb-4056-a4a2-6aa1b835191c@github.com>
Message-ID: <1OvsMD6wHNVsnsBALSFO8hHO9iOsUP32WJ4rT4FUhqM=.e9330040-1f8c-4a33-98a9-e66783827f19@github.com>

On Sat, 27 Aug 2022 18:58:40 GMT, Alan Bateman <alanb at openjdk.org> 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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com>
Message-ID: <NBJzDpMYO0F5X9nqcfc5Z6JNCDif2yuP69QKS37gGAg=.b4dcc849-8179-4899-b929-c8b98b119746@github.com>

On Fri, 26 Aug 2022 17:07:54 GMT, Coleen Phillimore <coleenp at openjdk.org> 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<WeakHandle, WeakHandle, 1009, ResourceObj::C_HEAP, mtClass,

I am struggling to understand what the key and values types are in this hashtable ???

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.

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: <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
References: <1lp1sIKsQLiM8JP_uI2yMQRIRRt3NgU1PIiN1fq67uY=.c0ca6038-6549-43e5-9b97-75fbbbeae5ac@github.com>
 <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
Message-ID: <ka2cr0lkTtkTclal7I1h4_B12ymIShgGr6loe9Mzcgo=.0ce9e2a8-a55c-44ae-99f3-bcf591db3242@github.com>

On Fri, 26 Aug 2022 12:04:57 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
References: <y89Onoa5PBtF_mjunbnCbJ64S2QVa4yL_OXWlJwjHwE=.d7482bbb-5c4c-4105-84f6-80db333ec50c@github.com>
Message-ID: <TJYCDjO4tBDPKqokmBEinpaRDkTLZcNfs5sChD9kmg0=.2cd9f6e1-e438-4e97-912e-feef4779b0a3@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.
> 
> _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: <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>
References: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
 <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>
Message-ID: <nuitRPE2h-7AnfS9y0lyl2fN8jS0To5eSCqOPd_1Euo=.bd257d5d-255f-466b-8999-9e6f88fdfc77@github.com>

On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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>
 <f_krmBtV_od6KLD-zHz2aC9ukEpB1_t4z_d1arfFNqI=.61842728-ac3f-403b-ab49-0a2e6b849216@github.com>
 <Fx0sUsiZOAiht4b3SZckjMSBkDKSQ-Rv7uMRggnzWXk=.302f0798-4fcb-4056-a4a2-6aa1b835191c@github.com>
 <1OvsMD6wHNVsnsBALSFO8hHO9iOsUP32WJ4rT4FUhqM=.e9330040-1f8c-4a33-98a9-e66783827f19@github.com>
Message-ID: <ryhz48oT2xGW5ex4p30G0_bMC7h4xfUV3Zd2i8eM0cs=.31a84520-2a36-44ea-b7fb-f2585fcf81f5@github.com>

On Sun, 28 Aug 2022 22:42:14 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com>
Message-ID: <fo1l0PFyRn2OI7W0EObYuihekAwsD9NkXVCphafh738=.5e0f6f6a-9c05-47b8-94b9-5d008da0181b@github.com>

On Fri, 26 Aug 2022 17:07:54 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <NBJzDpMYO0F5X9nqcfc5Z6JNCDif2yuP69QKS37gGAg=.b4dcc849-8179-4899-b929-c8b98b119746@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com>
 <NBJzDpMYO0F5X9nqcfc5Z6JNCDif2yuP69QKS37gGAg=.b4dcc849-8179-4899-b929-c8b98b119746@github.com>
Message-ID: <N4Cfa4yjebJ6Cb0utoN7bC9zuDmscjp1wCF7nUk6AUA=.04524b4e-b235-4d68-a61d-fdc1e7c0940c@github.com>

On Mon, 29 Aug 2022 00:12:36 GMT, David Holmes <dholmes at openjdk.org> 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<WeakHandle, WeakHandle, 1009, ResourceObj::C_HEAP, mtClass,
> 
> 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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
Message-ID: <Y1s55iD9aPsuROsnTyjfGOuBWFcoYvWHtjEcz2ihJzg=.a4721419-20e2-4328-98b3-c07ce69d3970@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:

  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: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>

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: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>

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: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
References: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
Message-ID: <w725NYY_yRLD16yGELQpz3ZSH_Y4A-5KbdOYVIyi8cw=.94045839-c7bf-49d2-ad4f-e611a5bd5ea7@github.com>

On Thu, 11 Aug 2022 21:12:08 GMT, Bill Huang <duke at openjdk.org> 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: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>
References: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>
Message-ID: <l3w3aoM1HRUd923iN8k8MstLpvXmN4zI3-Y5zRnQhJw=.9d0c0d73-866b-4a88-8d51-d2962aa2eb25@github.com>

On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <w725NYY_yRLD16yGELQpz3ZSH_Y4A-5KbdOYVIyi8cw=.94045839-c7bf-49d2-ad4f-e611a5bd5ea7@github.com>
References: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
 <w725NYY_yRLD16yGELQpz3ZSH_Y4A-5KbdOYVIyi8cw=.94045839-c7bf-49d2-ad4f-e611a5bd5ea7@github.com>
Message-ID: <_JEvlPcMihkyNEH0Ltc7We7rnVjVnZNTrHVy_6n8vM4=.46a89164-0822-4f1a-8b28-989c19a43d1a@github.com>

On Mon, 29 Aug 2022 21:50:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
References: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
Message-ID: <xJCkEh-lYYHjoAO8iQYqNGgbq8KfhlJuie1zGfUtfwQ=.8c497c58-c17b-40a2-ba68-8bad77af026e@github.com>

On Mon, 22 Aug 2022 22:51:50 GMT, Bill Huang <duke at openjdk.org> 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<ObjectName> 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: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
References: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
Message-ID: <GZO0IZw02W9WFg7NFmlMpiuziquOjlkWQ0iZRA7U9lk=.503f760e-5076-4efe-b54b-975dbe6df4f7@github.com>

> 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: <xJCkEh-lYYHjoAO8iQYqNGgbq8KfhlJuie1zGfUtfwQ=.8c497c58-c17b-40a2-ba68-8bad77af026e@github.com>
References: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
 <xJCkEh-lYYHjoAO8iQYqNGgbq8KfhlJuie1zGfUtfwQ=.8c497c58-c17b-40a2-ba68-8bad77af026e@github.com>
Message-ID: <10yedZhGkPqW3RjSV49MNMOaz_-VH2OelDjAgm2KQs4=.8836d0a7-0607-40a5-ade6-80f32dfd7252@github.com>

On Mon, 29 Aug 2022 22:06:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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: <GZO0IZw02W9WFg7NFmlMpiuziquOjlkWQ0iZRA7U9lk=.503f760e-5076-4efe-b54b-975dbe6df4f7@github.com>
References: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
 <GZO0IZw02W9WFg7NFmlMpiuziquOjlkWQ0iZRA7U9lk=.503f760e-5076-4efe-b54b-975dbe6df4f7@github.com>
Message-ID: <QPF8GkoB4_IQeHY4hDpncXJYQLXL6v9tVdBC3RZi5U8=.157e9c8d-6c2c-4a3a-b200-96bff9c75cba@github.com>

On Mon, 29 Aug 2022 23:25:11 GMT, Bill Huang <duke at openjdk.org> 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: <xJCkEh-lYYHjoAO8iQYqNGgbq8KfhlJuie1zGfUtfwQ=.8c497c58-c17b-40a2-ba68-8bad77af026e@github.com>
References: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
 <xJCkEh-lYYHjoAO8iQYqNGgbq8KfhlJuie1zGfUtfwQ=.8c497c58-c17b-40a2-ba68-8bad77af026e@github.com>
Message-ID: <v6kFiLsybvHXxGiExnsG0avcdLyd-PVescplb_mo-Nw=.6b601cba-ee26-4fe5-a0a4-7edb377b4d30@github.com>

On Mon, 29 Aug 2022 22:11:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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<ObjectName> 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: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>
References: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>
Message-ID: <rrt-24BsXbqeY6w6Q6hV-ggH84HjnMxROjNJBQv9KcI=.5f7ce113-b73a-417c-a77c-22c87e2e1d5d@github.com>

On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
References: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
Message-ID: <v3-k9rYc9tdczx4FlAXHvrllBFobf199vrCzBBHXwWU=.a05d5041-39f5-4611-84d0-faa12e8024ab@github.com>

On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>
References: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
 <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>
Message-ID: <xzNt7Zl3toJ7K9cTRjZS7YUbqzPndLTCEHoPuRm6fdE=.b98c21a9-bef2-4759-bb79-42ea319bf57d@github.com>

On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>
References: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>
Message-ID: <_oekHMD4p6wJ60ieHGVuqsHJ5FCL9gZ-ZrlBO50jSKU=.bfa0454e-3b6a-4d38-b8fa-7686336b832e@github.com>

On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>
References: <J9MWA6rFi56KxTtiXngG0p_W-VK_drV4O6UoGEaT07A=.e93cbef7-d46d-4262-9cfa-f97229f90b1f@github.com>
Message-ID: <Hm_lo5oE00IfGiKy5gyq-erbxx5owSZBn539Tx0bo0k=.84bf6714-3ba0-42c9-94f3-c45be121d732@github.com>

On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
References: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
Message-ID: <xJPlrBOqd8W4KeHNkKqWwNffJJNpq-QXFkDxij1LDyE=.9fed412b-3771-42e9-881b-1e9df16c1da5@github.com>

On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>
References: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
 <Zm62IKtXlGIm07k0nn91OU7ectI78iUuhmHrNkQVD7o=.f4c888c1-c104-4a17-8a6e-621f4d2c420b@github.com>
Message-ID: <iP-lOEYft8QyqOxtbAIiVODhsFbQLtG-tN-HqUYt04o=.4eb821b0-0ca6-4ac0-9630-b112dd1a5e38@github.com>

On Fri, 26 Aug 2022 21:33:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <N4Cfa4yjebJ6Cb0utoN7bC9zuDmscjp1wCF7nUk6AUA=.04524b4e-b235-4d68-a61d-fdc1e7c0940c@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com>
 <NBJzDpMYO0F5X9nqcfc5Z6JNCDif2yuP69QKS37gGAg=.b4dcc849-8179-4899-b929-c8b98b119746@github.com>
 <N4Cfa4yjebJ6Cb0utoN7bC9zuDmscjp1wCF7nUk6AUA=.04524b4e-b235-4d68-a61d-fdc1e7c0940c@github.com>
Message-ID: <Jf2jJuqnO3hJ4isKpxuQs8GF2Vb0zISXmNXry2swAIY=.dc6c3803-d587-40e5-a434-6036d599cb70@github.com>

On Mon, 29 Aug 2022 12:10:48 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
References: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
Message-ID: <NN-yRPQ5Gpde-Sqt9iEnBPoIaCkIqEI_b0o-AzJf070=.37b7e634-b5df-41c7-9b76-0191b23dbc44@github.com>

> 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: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
References: <cEhrQmN4N6nrUi_zf1_Xunp2QvvOOWMWqKn_whSWbFk=.b07e30f6-fd27-4221-9aa0-c58eddb23152@github.com>
Message-ID: <GebfhcBx1L6KWvHLEfePVGDWLsOUFAcof0pyjnZdA4k=.6ab41204-92de-4c85-82b9-d98b2bed82d2@github.com>

On Fri, 26 Aug 2022 20:13:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 <sspitsyn at openjdk.org>
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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
Message-ID: <O1_X2hH2Wop9Z13eMUPGIMMK8NdjD2i-pW9W1E7GfXg=.ddb8486d-4ffe-419b-9c72-9ff384bca701@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:

  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: <Y1s55iD9aPsuROsnTyjfGOuBWFcoYvWHtjEcz2ihJzg=.a4721419-20e2-4328-98b3-c07ce69d3970@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <Y1s55iD9aPsuROsnTyjfGOuBWFcoYvWHtjEcz2ihJzg=.a4721419-20e2-4328-98b3-c07ce69d3970@github.com>
Message-ID: <DvS_1havtQzbHSBLfChTOhFQFK0TpUNPBfXJSohXmAw=.e82a91fb-036b-40f0-adfb-cdcc33cdf97e@github.com>

On Mon, 29 Aug 2022 12:24:33 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
Message-ID: <ZASp_RBXgOtKhiobjx5yccOQrKra275vG547UbOXThE=.f79430c6-34cf-418d-a425-16950397686a@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:

  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: <O1_X2hH2Wop9Z13eMUPGIMMK8NdjD2i-pW9W1E7GfXg=.ddb8486d-4ffe-419b-9c72-9ff384bca701@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <O1_X2hH2Wop9Z13eMUPGIMMK8NdjD2i-pW9W1E7GfXg=.ddb8486d-4ffe-419b-9c72-9ff384bca701@github.com>
Message-ID: <70cl_bIxCFd16WL9j-O__wWS6MHJQuVR8fwe7vVDptY=.a8cbb465-095f-4170-b4fb-e26f502e33a6@github.com>

On Tue, 30 Aug 2022 19:31:00 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <DvS_1havtQzbHSBLfChTOhFQFK0TpUNPBfXJSohXmAw=.e82a91fb-036b-40f0-adfb-cdcc33cdf97e@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <Y1s55iD9aPsuROsnTyjfGOuBWFcoYvWHtjEcz2ihJzg=.a4721419-20e2-4328-98b3-c07ce69d3970@github.com>
 <DvS_1havtQzbHSBLfChTOhFQFK0TpUNPBfXJSohXmAw=.e82a91fb-036b-40f0-adfb-cdcc33cdf97e@github.com>
Message-ID: <dDfog8Sh74PzTmw5q7vW95p6_2HgoWcXfaa9XTQ3JII=.8abf381f-052e-4d5f-b96b-1956e01510be@github.com>

On Tue, 30 Aug 2022 18:20:26 GMT, Ioi Lam <iklam at openjdk.org> 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: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
References: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
Message-ID: <tiDU5joQllXhUqGKGfKGciveD9pBaSxaefLAIms9qSQ=.37e8e57b-da39-41c2-81f3-25f652e10276@github.com>

On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <NN-yRPQ5Gpde-Sqt9iEnBPoIaCkIqEI_b0o-AzJf070=.37b7e634-b5df-41c7-9b76-0191b23dbc44@github.com>
References: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
 <NN-yRPQ5Gpde-Sqt9iEnBPoIaCkIqEI_b0o-AzJf070=.37b7e634-b5df-41c7-9b76-0191b23dbc44@github.com>
Message-ID: <-zD4cslKX5ax8Fy3zluU6-Frh0pWfON8aiKesIA3JXA=.09d79b29-6c5c-4841-96d0-0cfec72b3975@github.com>

On Tue, 30 Aug 2022 18:17:28 GMT, Bill Huang <duke at openjdk.org> 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: <GZO0IZw02W9WFg7NFmlMpiuziquOjlkWQ0iZRA7U9lk=.503f760e-5076-4efe-b54b-975dbe6df4f7@github.com>
References: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
 <GZO0IZw02W9WFg7NFmlMpiuziquOjlkWQ0iZRA7U9lk=.503f760e-5076-4efe-b54b-975dbe6df4f7@github.com>
Message-ID: <ieO65aYv3GkpiQSNUjcPDikyvRw0dsXqiGOPSt8vl1k=.43fabec6-9585-4400-af4c-f5fc7ff80f20@github.com>

On Mon, 29 Aug 2022 23:25:11 GMT, Bill Huang <duke at openjdk.org> 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: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
References: <oLih4RYc9y9CGnpxwFusDoEa0VK-jLSEwqk8UezYeUk=.f3f29ba2-d013-426a-951d-c6228040e33a@github.com>
Message-ID: <Ke_HVbS3pq8ZdFNBLdKcOzJwahbqXdiDlwPulRy4oOo=.54973c3d-dfe0-4b8c-a3e7-8b847e381bb2@github.com>

> 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: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
References: <RB-tvt8egD-K9AyLkp4jFxwtF-XmSywn2QNlT4NBg_U=.dd4b37a7-0386-4028-bbd6-036b90dfbbcc@github.com>
Message-ID: <R4dDXbnxXyTifsECNupA7PyrytyqeIacqRxIYkW2VRQ=.80006192-779b-4d60-b00b-80f5d3c1eca4@github.com>

> 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: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
References: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
Message-ID: <bR8tj1sXIoShSexnU-S14a7Y1WmUbIaKQrbTCqoJCs4=.d8b0f698-dfca-4bc2-9fc6-fd46d67035f9@github.com>

> 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: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
References: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
Message-ID: <_qWP2tHLOf8toK1e-eZzGH5EgieTtXep07of8B0625I=.168f6885-5ade-4947-9301-405aa840e996@github.com>

On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <kpUXZb7LrhUJ9Mqtjus1VKc8CX8t2sKXgImJoZe4ti8=.74814ca5-2a7e-4ac7-b10e-f7996cecf920@github.com>

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: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
References: <mvvc_hCkDap3mK_AEl3Y8VIJ2-ovU7vWCeaLMP_3kss=.5677869a-8ff7-4815-8255-c23094bd419b@github.com>
Message-ID: <JYXWQRJ9herdkKUQIRQLrmUgJ1lM-q1JHYTdLdNxx6w=.2c308193-fd46-4801-9866-c7a681fa475c@github.com>

On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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: <TZ9fgHangXcZltInDsp83szfjsMIuT4-rlB3DFzR92o=.cdcaab39-5cfd-46a5-aad7-59e56f45175c@github.com>
References: <TZ9fgHangXcZltInDsp83szfjsMIuT4-rlB3DFzR92o=.cdcaab39-5cfd-46a5-aad7-59e56f45175c@github.com>
Message-ID: <RcJFfcvtre_AoPSR1onNXhUcm_Jea7UtDEwrMALyc2M=.388aa013-8fa5-47e0-81c9-97e960fdf267@github.com>

On Thu, 25 Aug 2022 21:16:22 GMT, Alex Menkov <amenkov at openjdk.org> 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: <Jf2jJuqnO3hJ4isKpxuQs8GF2Vb0zISXmNXry2swAIY=.dc6c3803-d587-40e5-a434-6036d599cb70@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com>
 <NBJzDpMYO0F5X9nqcfc5Z6JNCDif2yuP69QKS37gGAg=.b4dcc849-8179-4899-b929-c8b98b119746@github.com>
 <N4Cfa4yjebJ6Cb0utoN7bC9zuDmscjp1wCF7nUk6AUA=.04524b4e-b235-4d68-a61d-fdc1e7c0940c@github.com>
 <Jf2jJuqnO3hJ4isKpxuQs8GF2Vb0zISXmNXry2swAIY=.dc6c3803-d587-40e5-a434-6036d599cb70@github.com>
Message-ID: <tZLxflbA3Rmm8qTLkrkwB4HuygE6DQlLtAt_-iNKpRw=.fb2e1162-8dfd-49f9-af8d-058558cd543a@github.com>

On Tue, 30 Aug 2022 18:13:21 GMT, Ioi Lam <iklam at openjdk.org> 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: <N4Cfa4yjebJ6Cb0utoN7bC9zuDmscjp1wCF7nUk6AUA=.04524b4e-b235-4d68-a61d-fdc1e7c0940c@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com>
 <NBJzDpMYO0F5X9nqcfc5Z6JNCDif2yuP69QKS37gGAg=.b4dcc849-8179-4899-b929-c8b98b119746@github.com>
 <N4Cfa4yjebJ6Cb0utoN7bC9zuDmscjp1wCF7nUk6AUA=.04524b4e-b235-4d68-a61d-fdc1e7c0940c@github.com>
Message-ID: <pRCe0_LtR5ZzJBGfL_Jy0fx3negorFJzFSGDpMVE9NM=.66eebc5e-0e4b-43f5-89c2-64e5c060257a@github.com>

On Mon, 29 Aug 2022 12:11:03 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <dDfog8Sh74PzTmw5q7vW95p6_2HgoWcXfaa9XTQ3JII=.8abf381f-052e-4d5f-b96b-1956e01510be@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <Y1s55iD9aPsuROsnTyjfGOuBWFcoYvWHtjEcz2ihJzg=.a4721419-20e2-4328-98b3-c07ce69d3970@github.com>
 <DvS_1havtQzbHSBLfChTOhFQFK0TpUNPBfXJSohXmAw=.e82a91fb-036b-40f0-adfb-cdcc33cdf97e@github.com>
 <dDfog8Sh74PzTmw5q7vW95p6_2HgoWcXfaa9XTQ3JII=.8abf381f-052e-4d5f-b96b-1956e01510be@github.com>
Message-ID: <DQL3mxz7YOk_9XHWFKp_oYiDUSwx4CFez5l3a6ssoN0=.16b0ffd9-85c1-4639-b94f-b103ae3ccc3c@github.com>

On Tue, 30 Aug 2022 20:11:51 GMT, Coleen Phillimore <coleenp at openjdk.org> 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: <MNiXDIaP8NL4hBouqmUZqzX4ZFXzPRUagGPWE8snc4w=.c8d78829-9965-43c2-9e73-220053aeb173@github.com>

On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <kpUXZb7LrhUJ9Mqtjus1VKc8CX8t2sKXgImJoZe4ti8=.74814ca5-2a7e-4ac7-b10e-f7996cecf920@github.com>
References: <kpUXZb7LrhUJ9Mqtjus1VKc8CX8t2sKXgImJoZe4ti8=.74814ca5-2a7e-4ac7-b10e-f7996cecf920@github.com>
Message-ID: <TtYyO05ZVoKdrd4QZkTg_nV1S717X7RSpunPsxjaNYk=.8872635d-dbec-44eb-89b7-5cb466da149f@github.com>

On Tue, 30 Aug 2022 23:04:18 GMT, Chris Plummer <cjplummer at openjdk.org> 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: <J0EfFZ6y2qY0Fj2HFKcAMsSIRCeqE-h8osBvJh4xY8c=.d6104df5-62ab-4dd1-82d7-f5a2b003e591@github.com>

On Mon, 22 Aug 2022 15:06:31 GMT, Daniel Skantz <duke at openjdk.org> 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: <DQL3mxz7YOk_9XHWFKp_oYiDUSwx4CFez5l3a6ssoN0=.16b0ffd9-85c1-4639-b94f-b103ae3ccc3c@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <Y1s55iD9aPsuROsnTyjfGOuBWFcoYvWHtjEcz2ihJzg=.a4721419-20e2-4328-98b3-c07ce69d3970@github.com>
 <DvS_1havtQzbHSBLfChTOhFQFK0TpUNPBfXJSohXmAw=.e82a91fb-036b-40f0-adfb-cdcc33cdf97e@github.com>
 <dDfog8Sh74PzTmw5q7vW95p6_2HgoWcXfaa9XTQ3JII=.8abf381f-052e-4d5f-b96b-1956e01510be@github.com>
 <DQL3mxz7YOk_9XHWFKp_oYiDUSwx4CFez5l3a6ssoN0=.16b0ffd9-85c1-4639-b94f-b103ae3ccc3c@github.com>
Message-ID: <uixr_PB9Qu315JtziaxN1MZgNw4_P1gaO6Mi4FBl0aM=.375e73e1-dc47-4a7f-8461-e15b6d2b8b54@github.com>

On Wed, 31 Aug 2022 05:15:22 GMT, David Holmes <dholmes at openjdk.org> 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: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
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: <pRCe0_LtR5ZzJBGfL_Jy0fx3negorFJzFSGDpMVE9NM=.66eebc5e-0e4b-43f5-89c2-64e5c060257a@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com>
 <NBJzDpMYO0F5X9nqcfc5Z6JNCDif2yuP69QKS37gGAg=.b4dcc849-8179-4899-b929-c8b98b119746@github.com>
 <N4Cfa4yjebJ6Cb0utoN7bC9zuDmscjp1wCF7nUk6AUA=.04524b4e-b235-4d68-a61d-fdc1e7c0940c@github.com>
 <pRCe0_LtR5ZzJBGfL_Jy0fx3negorFJzFSGDpMVE9NM=.66eebc5e-0e4b-43f5-89c2-64e5c060257a@github.com>
Message-ID: <Etzq0Y_U9M5uF4SFxNwYiIAx_f-exkGVctIQO_qUdGs=.44b1aabe-b318-4c23-9052-0c59f28fcaad@github.com>

On Wed, 31 Aug 2022 05:13:17 GMT, David Holmes <dholmes at openjdk.org> 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: <tZLxflbA3Rmm8qTLkrkwB4HuygE6DQlLtAt_-iNKpRw=.fb2e1162-8dfd-49f9-af8d-058558cd543a@github.com>
References: <t8wS6vkXOFIduZ788CaHZoq6Yo3eMO37RF_nGbtL904=.138c89d7-304b-48d4-8f34-13bb79db5a80@github.com>
 <1UreGbOaKcczy262kOg7LeDPTcooTdS1Xc-gAQSiltk=.fb799ba3-ebfa-4de1-8ad4-33c2a3b966d9@github.com>
 <NBJzDpMYO0F5X9nqcfc5Z6JNCDif2yuP69QKS37gGAg=.b4dcc849-8179-4899-b929-c8b98b119746@github.com>
 <N4Cfa4yjebJ6Cb0utoN7bC9zuDmscjp1wCF7nUk6AUA=.04524b4e-b235-4d68-a61d-fdc1e7c0940c@github.com>
 <Jf2jJuqnO3hJ4isKpxuQs8GF2Vb0zISXmNXry2swAIY=.dc6c3803-d587-40e5-a434-6036d599cb70@github.com>
 <tZLxflbA3Rmm8qTLkrkwB4HuygE6DQlLtAt_-iNKpRw=.fb2e1162-8dfd-49f9-af8d-058558cd543a@github.com>
Message-ID: <HqmqlGbOBNPCk0yQIzy-iWuCy2TcGvq0yP58zktnnek=.9a375e61-0b2a-467f-9d44-47c602e69f5b@github.com>

On Wed, 31 Aug 2022 05:11:33 GMT, David Holmes <dholmes at openjdk.org> 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: <TZ9fgHangXcZltInDsp83szfjsMIuT4-rlB3DFzR92o=.cdcaab39-5cfd-46a5-aad7-59e56f45175c@github.com>
References: <TZ9fgHangXcZltInDsp83szfjsMIuT4-rlB3DFzR92o=.cdcaab39-5cfd-46a5-aad7-59e56f45175c@github.com>
Message-ID: <hrZWS92rz3U6-Pg8wfi2H3WNVxTsu9W7MSKFSSH0XTY=.f96294b4-2f2d-40f9-b813-f170d2ed7b22@github.com>

> 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: <RcJFfcvtre_AoPSR1onNXhUcm_Jea7UtDEwrMALyc2M=.388aa013-8fa5-47e0-81c9-97e960fdf267@github.com>
References: <TZ9fgHangXcZltInDsp83szfjsMIuT4-rlB3DFzR92o=.cdcaab39-5cfd-46a5-aad7-59e56f45175c@github.com>
 <RcJFfcvtre_AoPSR1onNXhUcm_Jea7UtDEwrMALyc2M=.388aa013-8fa5-47e0-81c9-97e960fdf267@github.com>
Message-ID: <CQxbDrB-9DipXOxzPb0lAgSoimOpo-ItS8lQV_QrCrA=.266f00bb-6c50-4713-a375-00f012b23baf@github.com>

On Wed, 31 Aug 2022 00:01:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <eZqvV9ZxHHh6mUCawcFt6FJpVIEl5jkXwh3_yogQJhQ=.ec70eb35-d31e-4d7e-b3a1-45adcf5e9e67@github.com>

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