From alanb at openjdk.org  Sat Feb  1 08:16:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 1 Feb 2025 08:16:53 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com>

On Fri, 31 Jan 2025 23:23:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool?

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2628846029

From coleenp at openjdk.org  Mon Feb  3 17:49:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:19 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
Message-ID: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>

The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.

There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.

Tested with tier1-8.

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

Commit messages:
 - Removed @Stable.
 - Fix JFR bug.
 - 8345678: Make Class.getModifiers() non-native.

Changes: https://git.openjdk.org/jdk/pull/22652/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346567
  Stats: 218 lines in 34 files changed: 57 ins; 139 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From liach at openjdk.org  Mon Feb  3 17:49:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

The change to java.lang.Class looks good.

Looking at #23396, we might need to filter this field too.

src/hotspot/share/classfile/javaClasses.cpp line 1504:

> 1502:   macro(_reflectionData_offset,      k, "reflectionData",      java_lang_ref_SoftReference_signature, false); \
> 1503:   macro(_signers_offset,             k, "signers",             object_array_signature, false); \
> 1504:   macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false)

Do we need a trailing semicolon here?

src/java.base/share/classes/java/lang/Class.java line 1315:

> 1313: 
> 1314:     // Set by the JVM when creating the instance of this java.lang.Class
> 1315:     private transient int modifiers;

If this is set by the JVM, can this be marked `final` so JIT compiler can trust this field? Also preferable if we can move this together with components/signers/classData fields.

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

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2490110846
PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2631658029
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876630297
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876627105

From coleenp at openjdk.org  Mon Feb  3 17:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <o2U4UlgxQKxF1RdTU6HARYpBGMYDRk1B3ZHeLCP7ZiQ=.67875d38-2a85-4fd9-a181-e6d765ab629c@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

> Looking at https://github.com/openjdk/jdk/pull/23396, we might need to filter this field too.

Yes, I agree.  This patch is a follow on to that one, so I'll add it to the same places when that one is merged in here.

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2631661716

From coleenp at openjdk.org  Mon Feb  3 17:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>
Message-ID: <e8V5_QLgWMgWjewNHqzQ9lk-HNa3RylbwnSE01ZHWMA=.781eb5c8-9a25-4670-8ba4-bbfe8e4b262c@github.com>

On Mon, 9 Dec 2024 19:46:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1504:
> 
>> 1502:   macro(_reflectionData_offset,      k, "reflectionData",      java_lang_ref_SoftReference_signature, false); \
>> 1503:   macro(_signers_offset,             k, "signers",             object_array_signature, false); \
>> 1504:   macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false)
> 
> Do we need a trailing semicolon here?

yes. it is needed.

> src/java.base/share/classes/java/lang/Class.java line 1315:
> 
>> 1313: 
>> 1314:     // Set by the JVM when creating the instance of this java.lang.Class
>> 1315:     private transient int modifiers;
> 
> If this is set by the JVM, can this be marked `final` so JIT compiler can trust this field? Also preferable if we can move this together with components/signers/classData fields.

The JVM rearranges these fields so that's why I put it near the caller.  Let me check if final compiles.

Edit: it looks better with the other fields though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876712191
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876713323

From duke at openjdk.org  Mon Feb  3 17:49:20 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <e8V5_QLgWMgWjewNHqzQ9lk-HNa3RylbwnSE01ZHWMA=.781eb5c8-9a25-4670-8ba4-bbfe8e4b262c@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>
 <e8V5_QLgWMgWjewNHqzQ9lk-HNa3RylbwnSE01ZHWMA=.781eb5c8-9a25-4670-8ba4-bbfe8e4b262c@github.com>
Message-ID: <fah136x1eL92esnncQ2l8JVUMhkwg25xpjmZhE-Rkbk=.ce4ed4dd-3f56-4ac7-83ec-ebed54ee74a7@github.com>

On Mon, 9 Dec 2024 20:27:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1504:
>> 
>>> 1502:   macro(_reflectionData_offset,      k, "reflectionData",      java_lang_ref_SoftReference_signature, false); \
>>> 1503:   macro(_signers_offset,             k, "signers",             object_array_signature, false); \
>>> 1504:   macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false)
>> 
>> Do we need a trailing semicolon here?
>
> yes. it is needed.

This is?**C++**, so?yes.
Suggestion:

  macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1876794006

From coleenp at openjdk.org  Mon Feb  3 17:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <fah136x1eL92esnncQ2l8JVUMhkwg25xpjmZhE-Rkbk=.ce4ed4dd-3f56-4ac7-83ec-ebed54ee74a7@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <1kHVpYCOExfkn8UHTZNZT6zwjRj3MCXJD2LVcY0NTrg=.0644323b-5f40-4441-8c19-763105aaf08d@github.com>
 <e8V5_QLgWMgWjewNHqzQ9lk-HNa3RylbwnSE01ZHWMA=.781eb5c8-9a25-4670-8ba4-bbfe8e4b262c@github.com>
 <fah136x1eL92esnncQ2l8JVUMhkwg25xpjmZhE-Rkbk=.ce4ed4dd-3f56-4ac7-83ec-ebed54ee74a7@github.com>
Message-ID: <44DPWzTGxPDoyWwZFbAxE74-KrXChIvfusVws1N-uN0=.f346731b-c61e-468f-9f58-4dc6e2df35d2@github.com>

On Mon, 9 Dec 2024 21:35:42 GMT, ExE Boss <duke at openjdk.org> wrote:

>> yes. it is needed.
>
> This is?**C++**, so?yes.
> Suggestion:
> 
>   macro(_modifiers_offset,           k, vmSymbols::modifiers_name(), int_signature,    false);

I see, there's a trailing semi somewhere in the expansion of this macro so it compiles, but I added one in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1878263513

From heidinga at openjdk.org  Mon Feb  3 17:49:20 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <5bMxhTRPqj-dMhr3FoSrym2ttWuzjWwtXAEcQHbF9Vg=.859ae29f-2530-4130-b108-d47c100ac19f@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

src/java.base/share/classes/java/lang/Class.java line 244:

> 242:         classLoader = loader;
> 243:         componentType = arrayComponentType;
> 244:         modifiers = 0;

The comment above about assigning a parameter to the field to prevent the JIT from assuming an incorrect default also should apply to the new `modifiers` field.  I think the constructor, which is never called, should also pass in a `dummyModifiers` value rather than using 0 directly

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880689835

From coleenp at openjdk.org  Mon Feb  3 17:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <5bMxhTRPqj-dMhr3FoSrym2ttWuzjWwtXAEcQHbF9Vg=.859ae29f-2530-4130-b108-d47c100ac19f@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <5bMxhTRPqj-dMhr3FoSrym2ttWuzjWwtXAEcQHbF9Vg=.859ae29f-2530-4130-b108-d47c100ac19f@github.com>
Message-ID: <FqVaeVj-Bz008BPwuDXr4GUgrQg2T3-glsXYm-yZy8E=.3c3f5d89-90fc-4c4b-9d03-0d66cfdfbde2@github.com>

On Wed, 11 Dec 2024 18:15:57 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> src/java.base/share/classes/java/lang/Class.java line 244:
> 
>> 242:         classLoader = loader;
>> 243:         componentType = arrayComponentType;
>> 244:         modifiers = 0;
> 
> The comment above about assigning a parameter to the field to prevent the JIT from assuming an incorrect default also should apply to the new `modifiers` field.  I think the constructor, which is never called, should also pass in a `dummyModifiers` value rather than using 0 directly

Yes, definitely, didn't see that this is the right way to do this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1887157349

From duke at openjdk.org  Mon Feb  3 17:49:21 2025
From: duke at openjdk.org (ExE Boss)
Date: Mon, 3 Feb 2025 17:49:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <-GEiPPAhFzy-uaUwIACYA7fZVCT3wkuVd-gtf9rrlnw=.de130f97-59bd-4581-a568-05d6238cf90a@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

src/java.base/share/classes/java/lang/Class.java line 1005:

> 1003:     private transient Object[] signers; // Read by VM, mutable
> 1004: 
> 1005:     @Stable

The?`modifiers`?field doesn?t?need to?be?`@Stable`:
Suggestion:

test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 65:

> 63:      */
> 64:     @Benchmark
> 65:     public int getModifiers() throws NoSuchMethodException {

The?only `Throwable`s that?can be?thrown by?calling `Class::getModifiers()` are?`Error`s (e.g.:?`StackOverflowError`) and?`RuntimeException`s (e.g.:?`NullPointerException`):
Suggestion:

    public int getModifiers() {

test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 71:

> 69:     Clazz[] clazzArray = new Clazz[1];
> 70:     @Benchmark
> 71:     public int getAppArrayModifiers() throws NoSuchMethodException {

Suggestion:

    public int getAppArrayModifiers() {

test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 81:

> 79:      */
> 80:     @Benchmark
> 81:     public int getArrayModifiers() throws NoSuchMethodException {

Suggestion:

    public int getArrayModifiers() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1888757754
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1888760732
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1888760967
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1888761412

From coleenp at openjdk.org  Mon Feb  3 17:49:21 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <-GEiPPAhFzy-uaUwIACYA7fZVCT3wkuVd-gtf9rrlnw=.de130f97-59bd-4581-a568-05d6238cf90a@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <-GEiPPAhFzy-uaUwIACYA7fZVCT3wkuVd-gtf9rrlnw=.de130f97-59bd-4581-a568-05d6238cf90a@github.com>
Message-ID: <f7t75uKmpCaoI-b5hUxSL2-6XRUyO7oXu4uXuqYQOgA=.f7fecd55-39f7-4b74-8aa1-723c58385121@github.com>

On Tue, 17 Dec 2024 15:54:48 GMT, ExE Boss <duke at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> src/java.base/share/classes/java/lang/Class.java line 1005:
> 
>> 1003:     private transient Object[] signers; // Read by VM, mutable
>> 1004: 
>> 1005:     @Stable
> 
> The?`modifiers`?field doesn?t?need to?be?`@Stable`:
> Suggestion:

I now don't know whether we want @Stable here or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1890866329

From vklang at openjdk.org  Mon Feb  3 17:49:21 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 3 Feb 2025 17:49:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

src/java.base/share/classes/java/lang/Class.java line 1006:

> 1004:     private final transient int modifiers;  // Set by the VM
> 1005: 
> 1006:     // package-private

@coleenp Could this field be @Stable, or does that only apply to `putfield`s?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1879797327

From liach at openjdk.org  Mon Feb  3 17:49:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Feb 2025 17:49:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
Message-ID: <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>

On Wed, 11 Dec 2024 10:24:03 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> src/java.base/share/classes/java/lang/Class.java line 1006:
> 
>> 1004:     private final transient int modifiers;  // Set by the VM
>> 1005: 
>> 1006:     // package-private
> 
> @coleenp Could this field be @Stable, or does that only apply to `putfield`s?

I don't think this needs to be stable - finals in java.lang is trusted by the JIT compiler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880350790

From vklang at openjdk.org  Mon Feb  3 17:49:24 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 3 Feb 2025 17:49:24 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
Message-ID: <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>

On Wed, 11 Dec 2024 14:52:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1006:
>> 
>>> 1004:     private final transient int modifiers;  // Set by the VM
>>> 1005: 
>>> 1006:     // package-private
>> 
>> @coleenp Could this field be @Stable, or does that only apply to `putfield`s?
>
> I don't think this needs to be stable - finals in java.lang is trusted by the JIT compiler.

Yeah, I was just thinking whether something set from inside the VM which is marked @Stable is constant-folded :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880374750

From coleenp at openjdk.org  Mon Feb  3 17:49:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Feb 2025 17:49:24 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
Message-ID: <f05_My76F3A49SVKFI7chP2uMOn3nochpfYWbTxCwAw=.3fb9cf96-b0c1-47c7-9769-90d5b55be072@github.com>

On Wed, 11 Dec 2024 15:06:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> I don't think this needs to be stable - finals in java.lang is trusted by the JIT compiler.
>
> Yeah, I was just thinking whether something set from inside the VM which is marked @Stable is constant-folded :)

I don't think @Stable would hurt but final should provide the same guarantee.  It's set internally by the VM so there's no late setting. I don't know if this field implementation can constant fold in the case of Arrays which are (JVM_ACC_ABSTRACT | JVM_ACC_FINAL | JVM_ACC_PUBLIC).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880663099

From heidinga at openjdk.org  Mon Feb  3 17:49:25 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 3 Feb 2025 17:49:25 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
Message-ID: <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>

On Wed, 11 Dec 2024 15:06:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> I don't think this needs to be stable - finals in java.lang is trusted by the JIT compiler.
>
> Yeah, I was just thinking whether something set from inside the VM which is marked @Stable is constant-folded :)

@viktorklang-ora `@Stable` is not about how the field was set, but about the JIT observing a  non-default value at compile time.  If it observes a non-default value, it can treat it as a compile time constant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1880692608

From vklang at openjdk.org  Mon Feb  3 17:49:25 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 3 Feb 2025 17:49:25 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
 <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
Message-ID: <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>

On Wed, 11 Dec 2024 18:17:43 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Yeah, I was just thinking whether something set from inside the VM which is marked @Stable is constant-folded :)
>
> @viktorklang-ora `@Stable` is not about how the field was set, but about the JIT observing a  non-default value at compile time.  If it observes a non-default value, it can treat it as a compile time constant.

@DanHeidinga Great explanation, thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1881782322

From amenkov at openjdk.org  Mon Feb  3 20:12:15 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 3 Feb 2025 20:12:15 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com>
Message-ID: <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com>

On Sat, 1 Feb 2025 08:14:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool?

I don't see much need in the functionality now (streaming output is useful for commands which produce lengthy output or take long time to execute), but we can add it if desired - need to wrap native writer to OutputStream and use the stream by java handlers (instead of byte buffer) to write command output.

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2631965659

From alanb at openjdk.org  Tue Feb  4 06:09:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 06:09:10 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com>
 <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com>
Message-ID: <Am9flkW7729jh2at_TatoI5flPbusHyHCBXfQl-nNlg=.f2de9ed0-cdf6-4045-a5b4-11bec8481709@github.com>

On Mon, 3 Feb 2025 20:09:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> > Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool?
> 
> I don't see much need in the functionality now (streaming output is useful for commands which produce lengthy output or take long time to execute), but we can add it if desired - need to wrap native writer to OutputStream and use the stream by java handlers (instead of byte buffer) to write command output.

Thread.dump_to_file is an example that needs this. There will be many more in the future. So while not for this PR we should we thinking about a follow-up to put in the infrastructure to support this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2632961617

From stuefe at openjdk.org  Tue Feb  4 07:04:13 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 4 Feb 2025 07:04:13 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com>
 <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com>
Message-ID: <B7mLds2Qzj0rUdJHTXdMRz7Z-_Y7L-9qtWN14Qk2W1o=.3c48d151-50fb-4e6a-8f46-99da457e2ad4@github.com>

On Mon, 3 Feb 2025 20:09:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool?
>
>> Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool?
> 
> I don't see much need in the functionality now (streaming output is useful for commands which produce lengthy output or take long time to execute), but we can add it if desired - need to wrap native writer to OutputStream and use the stream by java handlers (instead of byte buffer) to write command output.

@alexmenkov Oh, this is great, many thanks for doing this work! Good explanations too. I had a cursory view over the changes. Will do a more thorough review, and play around with this, when I am back home. 

With streaming, what is the expected behavior if a command takes too long? Jcmd stops with timeout, and the hotspot JVM then discards the results? 

Unless the tests are easy to fix, I don't see any problem with just running them in old buffered mode.

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2633044064

From tschatzl at openjdk.org  Tue Feb  4 09:50:16 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 4 Feb 2025 09:50:16 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME
In-Reply-To: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
Message-ID: <JHcmIBxa_n1j4u8krC97bj6-yusqKOqqr9-wvEOIdIQ=.1ff7acb0-9c2c-40e6-af87-04ae598c9731@github.com>

On Thu, 30 Jan 2025 12:12:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
> 
> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
> 
> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
> 
> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
> 
> Test: tier1-8

* Idk if GCLocker JFR events need to be available in metadata.xml if the VM does not actually ever send it. I think it does not.
Maybe it is used to decode from old recordings, may be worth asking e.g. @egahlin .
* the bot shows a failure that this PR's CR number shows up in the problemlist, that line needs to be deleted as well. Further it would be interesting to see how many retries there are in the allocation loop with these jnilock* stress test.
* another issue, probably todo is that while Parallel GC has the emergency bailout via GC Overhead limit after excessive retries, Serial does not. Which means that it might retry for a long time, which isn't good (while it did earlier if the number of retries due to gclocker exceed that threshold)

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 323:

> 321:     }
> 322: 
> 323:     if (result == nullptr) {

pre-existing: is it actually possible that `result` is not `nullptr` here? The code above always returns with a non-null result.
Maybe assert this instead.

src/hotspot/share/gc/shared/gcLocker.cpp line 86:

> 84: void GCLocker::block() {
> 85:   assert(_lock->is_locked(), "precondition");
> 86:   assert(Atomic::load(&_is_gc_request_pending) == false, "precondition");

Suggestion:

  assert(!Atomic::load(&_is_gc_request_pending), "precondition");

src/hotspot/share/gc/shared/gcLocker.cpp line 106:

> 104: 
> 105: #ifdef ASSERT
> 106:   // Matching the storestore in GCLocker::exit

Suggestion:

  // Matching the storestore in GCLocker::exit.

src/hotspot/share/gc/shared/gcLocker.cpp line 114:

> 112: void GCLocker::unblock() {
> 113:   assert(_lock->is_locked(), "precondition");
> 114:   assert(Atomic::load(&_is_gc_request_pending) == true, "precondition");

Suggestion:

  assert(Atomic::load(&_is_gc_request_pending), "precondition");

src/hotspot/share/gc/shared/gcLocker.hpp line 31:

> 29: #include "memory/allStatic.hpp"
> 30: #include "runtime/mutex.hpp"
> 31: 

Documentation how GCLocker works/is supposed to work is missing here. It's not exactly trivial.

src/hotspot/share/gc/shared/gcLocker.hpp line 33:

> 31: 
> 32: class GCLocker: public AllStatic {
> 33:   static Monitor* _lock;

Not sure if having this copy/reference to `Heap_lock` makes the code more clear than referencing `Heap_lock` directly. It needs to be `Heap_lock` anyway.

src/hotspot/share/gc/shared/gcLocker.hpp line 37:

> 35: 
> 36: #ifdef ASSERT
> 37:   static uint64_t _debug_count;

Maybe the variable could be named something less generic, indicating what it is counting. Or add a comment.

src/hotspot/share/gc/shared/gcLocker.inline.hpp line 40:

> 38:     if (Atomic::load(&_is_gc_request_pending)) {
> 39:       thread->exit_critical();
> 40:       // slow-path

Suggestion:



Not sure what this `slow-path` comment helps with. Maybe it is describing the next method (but it is named very similarly), or this is an attempt to describe the true-block of the if.
In the latter case, it would maybe be better to put this comment at the start of the true-block of the if, and say something more descriptive like `// Another thread is requesting gc, enter slow path.`

Not sure, feel free to ignore, it's just that to me the comment should either be removed or put upwards a line.

src/hotspot/share/gc/shared/gcLocker.inline.hpp line 56:

> 54:   if (thread->in_last_critical()) {
> 55:     Atomic::add(&_debug_count, (uint64_t)-1);
> 56:     // Matching the loadload in GCLocker::block

Suggestion:

    // Matching the loadload in GCLocker::block.

src/hotspot/share/gc/shared/gcTraceSend.cpp line 364:

> 362: #if INCLUDE_JFR
> 363: 
> 364: #endif

Please remove this empty `#if/#endif` block.

src/hotspot/share/gc/shared/gc_globals.hpp line 162:

> 160:           "blocked by the GC locker")                                       \
> 161:           range(0, max_uintx)                                               \
> 162:                                                                             \

This removal should warrant a release note; while it's a diagnostic option and we can remove at a whim, it is in use to workaround issues.

src/hotspot/share/prims/whitebox.cpp line 48:

> 46: #include "gc/shared/concurrentGCBreakpoints.hpp"
> 47: #include "gc/shared/gcConfig.hpp"
> 48: #include "gc/shared/gcLocker.hpp"

Suggestion:


The file does not seem to use the `GCLocker` class anymore, please remove this line as well.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2592106484
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940732531
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940775211
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940813063
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940779840
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940770235
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940769765
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940796501
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940793704
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940812598
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940746077
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940748992
PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1940752118

From jsjolen at openjdk.org  Tue Feb  4 12:39:14 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Feb 2025 12:39:14 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>

On Fri, 31 Jan 2025 23:23:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

Hi Alex,

Thank you for this. It's very good to have this feature. I'm still reading the code, but I'm submitting these comments as a first round.

I didn't really understand what makes this streaming. The old protocol first sent out the result, and then the data, has this changed?

Thanks,
Johan

src/hotspot/share/services/attachListener.cpp line 53:

> 51: 
> 52: // Stream for printing attach operation results.
> 53: // Supports buffered and streaming output for commands which can produce lenghtly reply.

"lengthy"

src/hotspot/share/services/attachListener.cpp line 56:

> 54: //
> 55: // To support streaming output platform implementation need to implement AttachOperation::get_reply_writer() method
> 56: // and ctor allow_streaming argument should be set to true.

Strange mix of "need" and "should".

Can we split this into multiple sentences? Here's a suggestion, though I'm not sure if it's 100% correct :-).


An output platform implementation supports streaming if it implements AttachOperation::get_reply_writer().
Streaming is enabled if the allow_streaming in the constructor is set to true.

src/hotspot/share/services/attachListener.cpp line 139:

> 137:       }
> 138:     } else {
> 139:       /* TODO: handle buffer overflow

Important `TODO` :-).

src/hotspot/share/services/diagnosticFramework.cpp line 389:

> 387:   int count = 0;
> 388:   while (iter.has_next()) {
> 389:     if(_source == DCmd_Source_MBean && count > 0) {

Pre-existing style: Space between `if` and condition missing.

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

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2592338074
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1940877174
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1940882015
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1940886089
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1940875712

From alanb at openjdk.org  Tue Feb  4 13:39:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 13:39:14 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <LmtPYlKPNV3CPRskziXNOotqOzQSuugz1KgkSYZkBx0=.9c87d177-b3e5-4bc4-8ce2-133ecd47dc9b@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

src/hotspot/share/oops/arrayKlass.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved.

arrayKlass.hpp isn't changed, is this left over from a previous iteration?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1941185550

From alanb at openjdk.org  Tue Feb  4 14:00:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Feb 2025 14:00:13 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <Dfl0TA0afI1TwGuimErvPiKq5aj1ZoKAtRR2D3h1RKU=.9026a36e-34cf-4081-852c-da921d0de1e2@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Good cleanup.

src/java.base/share/classes/java/lang/Class.java line 244:

> 242:         classLoader = loader;
> 243:         componentType = arrayComponentType;
> 244:         modifiers = dummyModifiers;

I realize this ctor isn't used but "dummyModifiers" looks very strange as parameter name when compared to the others, renaming it to something like "mods" would make it less confusing for anyone reading through this code.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2592938860
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1941220263

From coleenp at openjdk.org  Tue Feb  4 14:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Feb 2025 14:43:51 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright and param name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/8854fcc6..ff693418

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Tue Feb  4 14:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Feb 2025 14:43:51 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <btZ1sRHlMDoKSoiu3JP2F6yQQ5RoyrjtqZ6U3x4SlPU=.24565830-b88c-4dea-9fd3-54ec09b5b1eb@github.com>

On Tue, 4 Feb 2025 14:40:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

Thank you for your comments, Alan.

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

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2593075666

From coleenp at openjdk.org  Tue Feb  4 14:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Feb 2025 14:43:51 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <LmtPYlKPNV3CPRskziXNOotqOzQSuugz1KgkSYZkBx0=.9c87d177-b3e5-4bc4-8ce2-133ecd47dc9b@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <LmtPYlKPNV3CPRskziXNOotqOzQSuugz1KgkSYZkBx0=.9c87d177-b3e5-4bc4-8ce2-133ecd47dc9b@github.com>
Message-ID: <JckEJXVxVdnyG0Y0fxLjskXIpeCZlGgxyxklrGA9tqE=.81e6ea77-c462-4b65-9b2c-6fd18d29f471@github.com>

On Tue, 4 Feb 2025 13:36:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright and param name
>
> src/hotspot/share/oops/arrayKlass.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> arrayKlass.hpp isn't changed, is this left over from a previous iteration?

yes, it was something that my copyright script thought I changed from merging some previous changes.

> src/java.base/share/classes/java/lang/Class.java line 244:
> 
>> 242:         classLoader = loader;
>> 243:         componentType = arrayComponentType;
>> 244:         modifiers = dummyModifiers;
> 
> I realize this ctor isn't used but "dummyModifiers" looks very strange as parameter name when compared to the others, renaming it to something like "mods" would make it less confusing for anyone reading through this code.

I changed it to mods.  Thanks for the suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1941301152
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1941302820

From egahlin at openjdk.org  Tue Feb  4 16:56:17 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 4 Feb 2025 16:56:17 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME
In-Reply-To: <JHcmIBxa_n1j4u8krC97bj6-yusqKOqqr9-wvEOIdIQ=.1ff7acb0-9c2c-40e6-af87-04ae598c9731@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <JHcmIBxa_n1j4u8krC97bj6-yusqKOqqr9-wvEOIdIQ=.1ff7acb0-9c2c-40e6-af87-04ae598c9731@github.com>
Message-ID: <dcOB9eTCvsFL8hBCIF1nbtelmpDMEesWyQltdY8e3ZU=.295bbab3-bed4-49cb-861b-abdc69211ec8@github.com>

On Tue, 4 Feb 2025 09:47:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> * Idk if GCLocker JFR events need to be available in metadata.xml if the VM does not actually ever send it. I think it does not.
>   Maybe it is used to decode from old recordings, may be worth asking e.g. @egahlin .

If the event is not used and the metric is not interesting to have anymore, remove it from metadata.xml, default.jfc, profile.jfc, EventNames.java and delete the TestGCLockerEvent.java file.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2634538626

From amenkov at openjdk.org  Tue Feb  4 19:51:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 4 Feb 2025 19:51:26 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <Am9flkW7729jh2at_TatoI5flPbusHyHCBXfQl-nNlg=.f2de9ed0-cdf6-4045-a5b4-11bec8481709@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com>
 <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com>
 <Am9flkW7729jh2at_TatoI5flPbusHyHCBXfQl-nNlg=.f2de9ed0-cdf6-4045-a5b4-11bec8481709@github.com>
Message-ID: <6alqVi_g6MPcYJ2ikBumixTicMK3IpoSVmpFLM9AMiI=.a0b9137f-5f15-4e81-b1fd-c2c79c90915e@github.com>

On Tue, 4 Feb 2025 06:06:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > Do you expect there will be follow up work at some point for the commands that upcall to Java and produce a byte[] to return to the tool?
> > 
> > 
> > I don't see much need in the functionality now (streaming output is useful for commands which produce lengthy output or take long time to execute), but we can add it if desired - need to wrap native writer to OutputStream and use the stream by java handlers (instead of byte buffer) to write command output.
> 
> Thread.dump_to_file is an example that needs this. There will be many more in the future. So while not for this PR we should we thinking about a follow-up to put in the infrastructure to support this.

We have [JDK-8336723](https://bugs.openjdk.org/browse/JDK-8336723) to implement streaming output for commands implemented in java. This PR is lower level and provides functionality required for JDK-8336723

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2634917509

From amenkov at openjdk.org  Tue Feb  4 20:07:09 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 4 Feb 2025 20:07:09 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <B7mLds2Qzj0rUdJHTXdMRz7Z-_Y7L-9qtWN14Qk2W1o=.3c48d151-50fb-4e6a-8f46-99da457e2ad4@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4E3bp3iIhzF5kPXQghh7jam-g4n5ZVg2weGcdSKC2wU=.dd621da8-8e42-4cf5-89f0-e146ab34ffe1@github.com>
 <3jC5HEOCqpjqYRUaNNJTbGVHUy3SAgzyMoZYt1aXuI4=.3f7d58d8-0534-48f2-a967-bb0de55f806d@github.com>
 <B7mLds2Qzj0rUdJHTXdMRz7Z-_Y7L-9qtWN14Qk2W1o=.3c48d151-50fb-4e6a-8f46-99da457e2ad4@github.com>
Message-ID: <1_BKSEInasVApGdnYKQqc354hLaqfv0hWdhJ8JXsnak=.93b1ab2e-ceb4-4dd2-8d38-8f7cfdc45cb4@github.com>

On Tue, 4 Feb 2025 07:01:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> With streaming, what is the expected behavior if a command takes too long? Jcmd stops with timeout, and the hotspot JVM then discards the results?

When a tool is run interactively (I mean not as part of a testing) there is no timeouts - the tools forward any output from the target VM to stdout until communication channel (socket/pipe) is closed.
With streaming the tool just prints command output earlier.
If jcmd is killed while the command is in progress, the VM completes the command anyway (we don't have a way to stop it), results are discarded.

> Unless the tests are easy to fix, I don't see any problem with just running them in old buffered mode.

Yes, this is the plan for the next step - fix the tests of disable streaming output.

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2634946997

From amenkov at openjdk.org  Tue Feb  4 20:15:10 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 4 Feb 2025 20:15:10 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
Message-ID: <IEjlHXE81cJ1pFA2Js5uNs-Jis834z1Ve-9m_NPKzF8=.77d96896-4951-452e-9965-9699ad8297b4@github.com>

On Tue, 4 Feb 2025 12:36:06 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> I didn't really understand what makes this streaming. The old protocol first sent out the result, and then the data, has this changed?

The protocol works as before.
All command handlers are updated to set the result code earlier (after argument parsing, but before command execution).
After the result code is set, it's sent to the tool and the rest of output (data) are send directly to the tool without buffering.

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2634963089

From amenkov at openjdk.org  Tue Feb  4 20:26:17 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 4 Feb 2025 20:26:17 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
Message-ID: <enrXXa7riPRBAadgRnhiIkygHK2D0EYKXjyVtr_sb6M=.3fcc000d-10bf-47d6-9108-3c65cc176613@github.com>

On Tue, 4 Feb 2025 10:16:45 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> The fix implements streaming output support for attach protocol.
>> See JBS issue for evaluation, summary of the changes in the 1st comment.
>> Testing: tier1..4,hs-tier5-svc
>
> src/hotspot/share/services/attachListener.cpp line 139:
> 
>> 137:       }
>> 138:     } else {
>> 139:       /* TODO: handle buffer overflow
> 
> Important `TODO` :-).

This is for [JDK-8319307](https://bugs.openjdk.org/browse/JDK-8319307)
@tstuefe Do you want to keep this comment to work on JDK-8319307?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1941840271

From dlong at openjdk.org  Wed Feb  5 01:13:20 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 01:13:20 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:

> 71:     public int getAppArrayModifiers() {
> 72:         return clazzArray.getClass().getModifiers();
> 73:     }

I'm guessing this is the benchmark that shows an extra load.  How about adding a benchmark that makes the Clazz[] final or @Stable, and see if that makes the extra load go away?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1942114565

From cjplummer at openjdk.org  Wed Feb  5 04:31:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Feb 2025 04:31:48 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA
Message-ID: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>

Cleanup SA JavaThread support. Details in first comment:

Testing:
- Tier1
- Tier2 svc
- Tier3
- Tier5 svc
- Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.

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

Commit messages:
 - fix whitespace
 - Cleanup JavaThread support

Changes: https://git.openjdk.org/jdk/pull/23456/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23456&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348347
  Stats: 429 lines in 16 files changed: 61 ins; 330 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/23456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23456/head:pull/23456

PR: https://git.openjdk.org/jdk/pull/23456

From cjplummer at openjdk.org  Wed Feb  5 04:31:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Feb 2025 04:31:48 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA
In-Reply-To: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
Message-ID: <89_KTy7foMJWrCexiSryVUVHjJgn026fU-zqvsHIzP4=.d7a77a1d-1834-4d05-8998-8b9ce6d4f674@github.com>

On Wed, 5 Feb 2025 04:18:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Cleanup SA JavaThread support. Details in first comment:
> 
> Testing:
> - Tier1
> - Tier2 svc
> - Tier3
> - Tier5 svc
> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.

This PR addresses some errors and inconsistencies w.r.t. how SA handles the visibility of JavaThreads and their subclasses. There is some historic bit rot here that has resulted from old assumptions no longer being true.

In SA, Thread.isJavaThread() returned false for any JavaThread subclass. In hotspot it returns true for subclasses. The reason given in SA comments was essentially that JavaThread subclasses don't execute java code and will fail (with exceptions) if you try to get their java stack trace. Neither of those assumptions are true. There are JavaThread subclasses that execute java code (AttachListenerThread, NotificationThread, JvmtiAgentThread, and sometimes CompilerThread), and even those that don't won't cause SA any grief if you try to walk their stacks. You simply will not get any frames to walk. Thus in output like for jstack, you just see something like following, which is fine:


"Attach Listener" #19 daemon prio=5 tid=0x00007f0ab41f3d40 nid=18753 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked


Hotspot has the concept of a JavaThread subclass being "hidden". Being hidden has many purposes in hostpot, most of which don't apply to SA. For example, JVMTI won't allow hidden threads to be suspended or resumed, or generate THREAD_START/END events for them. However, hotspot does omit hidden threads from stack dumps, so SA should do the same. All the thread types that normally never execute java code are considered hidden. This would include the following thread types: StringDedupThread, DeoptimizeObjectsALotThread, ServiceThread, MonitorDeflationThread and usually CompilerThread, unless it is executing a JVMCI compiler written in java.

I eventually realized that SA's isJavaThread() was not needed, and only isHiddenFromExternalView() is needed. So isJavaThread() is removed, which is good because of its confusing name. Also, some of the JavaThread subclasses needed to be fixed to return the correct value for isHiddenFromExternalView(), so that is a large part of what this PR does, but there is also a lot of other cleanup. Here's a breakdown of the changes:

- Remove isJavaThread(). Use isHiddenFromExternalView() when needed.
- Remove almost all JavaThread subclasses. They aren't needed because for the most part the only purpose of the subclass would be to override isHiddenFromExternalView() to return false. So instead of a bunch of JavaThread subclasses I added HiddenJavaThread to cover all the subclass types that are hidden. CompilerThread had to remain since it is the one subclass with some special SA functionality.
- Make needed adjustments to isHiddenFromExternalView()
- Get rid of a bunch of isXXXThread() apis. For the most part they were never called, and the one place where there was a valid call was actually suppose to be calling isHiddenFromExternalView().
- Cleanup comments regarding isJavaThread() and it being unsafe to try to access frames of threads that are not "java threads".
- In PointerLocation, which is used for findpc support, the logic for handling a pointer to a JNI handle was skipping providing thread details if the thread was a JavaThread subclass. There is no reason for this, so the isJavaThread() check is removed. Also removed the need for the JavaThread cast by changing handleThread from Thread to JavaThread.
- In StackTrace, which is used by jstack, isJavaThread() was used to filter out threads. This meant filtering out some java threads that were actually executing java. This check is replaced with !isHiddenFromExternalView().
- For SA heap dumping, it used to do two checks. The first was to exclude hidden threads. If not hidden then the 2nd was to exclude non-JavaThreads, which meant excluding all the JavaThread subclasses, even those that do execute java code. This was fixed by removing the isJavaThread() check. This check was being done in ThreadStackTrace.dumpStack(), which is only used when dumping the heap. I think it was a guard to protect against calling thread.getLastJavaVFrameDbg() on a native thread, which apparently in early SA days was not safe. Also in early SA days none of the JavaThread subclasses executed java, so skipping them was fine, but that is no longer the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/23456#issuecomment-2635673154

From dholmes at openjdk.org  Wed Feb  5 05:07:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Feb 2025 05:07:14 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA
In-Reply-To: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
Message-ID: <UHizLUrcjyOWhi6jBAqRnGPwRTalk-PMuhcaUmCpfew=.5b029365-c4e0-4567-b614-54d4fffdb698@github.com>

On Wed, 5 Feb 2025 04:18:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Cleanup SA JavaThread support. Details in first comment:
> 
> Testing:
> - Tier1
> - Tier2 svc
> - Tier3
> - Tier5 svc
> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.

FWIW this cleanup looks good to me and makes a lot of sense. I guess there will be a change in behaviour in that some previously excluded threads will now appear in the stack dump. But that shouldn't affect any real code as nothing should presume to know the set of threads anyway.

I will leave it to other serviceability folk to click the actual Approve button, but thanks again for this cleanup!

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 36:

> 34: import sun.jvm.hotspot.utilities.Observer;
> 35: 
> 36: /** This class is no longer abstract. Platform dependent functionality is now implmented

Suggestion:

/** Platform dependent functionality is now implemented

"no longer" very quickly loses context if you don't know when it was abstract, or why.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 161:

> 159:         virtualConstructor.addMapping("JvmtiAgentThread", JavaThread.class);
> 160:         virtualConstructor.addMapping("NotificationThread", JavaThread.class);
> 161:         virtualConstructor.addMapping("AttachListenerThread", JavaThread.class);

It still seems a shame that we have to enumerate all the thread sybtypes.

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

PR Review: https://git.openjdk.org/jdk/pull/23456#pullrequestreview-2594628871
PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1942248757
PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1942249801

From cjplummer at openjdk.org  Wed Feb  5 06:11:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 5 Feb 2025 06:11:14 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA
In-Reply-To: <UHizLUrcjyOWhi6jBAqRnGPwRTalk-PMuhcaUmCpfew=.5b029365-c4e0-4567-b614-54d4fffdb698@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <UHizLUrcjyOWhi6jBAqRnGPwRTalk-PMuhcaUmCpfew=.5b029365-c4e0-4567-b614-54d4fffdb698@github.com>
Message-ID: <FOPLB5wfl8kb6UZDKwzYa_vS94G7z6XpUzQhPlw6nsE=.de746861-f5d8-4a36-b832-93998b3c478a@github.com>

On Wed, 5 Feb 2025 05:00:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Cleanup SA JavaThread support. Details in first comment:
>> 
>> Testing:
>> - Tier1
>> - Tier2 svc
>> - Tier3
>> - Tier5 svc
>> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 36:
> 
>> 34: import sun.jvm.hotspot.utilities.Observer;
>> 35: 
>> 36: /** This class is no longer abstract. Platform dependent functionality is now implmented
> 
> Suggestion:
> 
> /** Platform dependent functionality is now implemented
> 
> "no longer" very quickly loses context if you don't know when it was abstract, or why.

Ok. I can probably just remove the comment. I guess I worded it the way I did to help the reviewer understand (as opposed to a comment just disappearing).

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 161:
> 
>> 159:         virtualConstructor.addMapping("JvmtiAgentThread", JavaThread.class);
>> 160:         virtualConstructor.addMapping("NotificationThread", JavaThread.class);
>> 161:         virtualConstructor.addMapping("AttachListenerThread", JavaThread.class);
> 
> It still seems a shame that we have to enumerate all the thread sybtypes.

In order the create a mirror instance, SA needs to map the hotspot type to the SA type that implements the mirror. We have the same issue with CodeBlob subtypes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1942292903
PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1942294672

From stuefe at openjdk.org  Wed Feb  5 07:27:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 5 Feb 2025 07:27:10 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <enrXXa7riPRBAadgRnhiIkygHK2D0EYKXjyVtr_sb6M=.3fcc000d-10bf-47d6-9108-3c65cc176613@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
 <enrXXa7riPRBAadgRnhiIkygHK2D0EYKXjyVtr_sb6M=.3fcc000d-10bf-47d6-9108-3c65cc176613@github.com>
Message-ID: <UCRtDbHSoHl32c6SaNEEQ9Qr9JJI0W_mcNuXu3AVdcE=.c8995b19-935b-49c4-982f-704ffecfe244@github.com>

On Tue, 4 Feb 2025 20:23:57 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/services/attachListener.cpp line 139:
>> 
>>> 137:       }
>>> 138:     } else {
>>> 139:       /* TODO: handle buffer overflow
>> 
>> Important `TODO` :-).
>
> This is for [JDK-8319307](https://bugs.openjdk.org/browse/JDK-8319307)
> @tstuefe Do you want to keep this comment to work on JDK-8319307?

You can remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1942361508

From amitkumar at openjdk.org  Wed Feb  5 14:07:28 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 5 Feb 2025 14:07:28 GMT
Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass
 [v3]
In-Reply-To: <NwOLYF3kR2b4HOZf6RxCQWq8F6ucWRIfi2ArqUiwKcI=.a0e56be6-9070-4a7d-95c1-6c51b7d4ef8a@github.com>
References: <pxpFAGJcpI2NQjude2t70BPMmIl6rT3s3JUoi-MV3WQ=.eddb6a6f-6ee3-4592-a1ee-74c6200fad31@github.com>
 <il4KXlFgg1WhYmKowy3o_WOv6JJm1WY_Jek3_fs_rbA=.bf263451-182d-4cd9-8a37-371974c1dc2d@github.com>
 <NwOLYF3kR2b4HOZf6RxCQWq8F6ucWRIfi2ArqUiwKcI=.a0e56be6-9070-4a7d-95c1-6c51b7d4ef8a@github.com>
Message-ID: <Q68prEVwcDw3SdnPdJBLiFhULf6LFr57IqYUAOAOECk=.379be364-3a3c-43fc-88f8-096a99c3f1cf@github.com>

On Thu, 21 Nov 2024 12:13:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification.
>
> Thanks David and Johan for the reviews.

Hi @coleenp, 

I am repeating the message from Theresa, since she is part of OpenJ9 and can't accept  OpenJDK Terms: 


`serviceability/jvmti/RedefineClasses/RedefineVerifyError.java` I believe the correct behavior should be throwing a ClassFormatException since the generated class is not well formed.

According to the JVM specification in section 4.7.3 The Code Attribute:

If the method is either native or abstract, and is not a class or interface
initialization method, then its method_info structure must not have a Code attribute
in its attributes table. Otherwise, its method_info structure must have exactly
one Code attribute in its attributes table.
also
The value of code_length must be greater than zero

Can you clarify why VerifyError is expected to be caught here?

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

PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2636942548

From ayang at openjdk.org  Wed Feb  5 14:41:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 5 Feb 2025 14:41:39 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
Message-ID: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>

> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
> 
> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
> 
> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
> 
> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
> 
> Test: tier1-8

Albert Mingkun Yang 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 gclocker
 - review
 - Merge branch 'master' into gclocker
 - gclocker

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23367/files
  - new: https://git.openjdk.org/jdk/pull/23367/files/6283a19c..1b6f908b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=00-01

  Stats: 20456 lines in 569 files changed: 9369 ins; 6708 del; 4379 mod
  Patch: https://git.openjdk.org/jdk/pull/23367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23367/head:pull/23367

PR: https://git.openjdk.org/jdk/pull/23367

From ayang at openjdk.org  Wed Feb  5 14:41:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 5 Feb 2025 14:41:39 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
Message-ID: <82w1_VjrsxtrpA7921QmHsA0kh9_J0kBtOCxp6sL7F4=.0b0d0698-b3d2-43a0-85b4-6b7e530e3a7a@github.com>

On Wed, 5 Feb 2025 14:38:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

> Further it would be interesting to see how many retries there are in the allocation loop with these jnilock* stress test.

I added `QueuedAllocationWarningCount=1` to `test/hotspot/jtreg/vmTestbase/nsk/stress/jni/gclocker/gcl001.java` and saw retry never exceeds 10 for Serial/Parallel.

> Which means that it might retry for a long time

That occurs only when another java thread successfully triggers a gc, advancing the gc-counter, i.e. there is some system-wide progress. Per-thread progress is hard to guarantee, IMO.

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

PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2595944041

From ayang at openjdk.org  Wed Feb  5 14:41:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 5 Feb 2025 14:41:39 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <JHcmIBxa_n1j4u8krC97bj6-yusqKOqqr9-wvEOIdIQ=.1ff7acb0-9c2c-40e6-af87-04ae598c9731@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <JHcmIBxa_n1j4u8krC97bj6-yusqKOqqr9-wvEOIdIQ=.1ff7acb0-9c2c-40e6-af87-04ae598c9731@github.com>
Message-ID: <iYbfly0fFxY9m8uFrQMe11CDGkgLcdb5F6mDZqiTRdA=.eb0e9cdc-0daa-48f6-8a03-dd922ae954be@github.com>

On Tue, 4 Feb 2025 09:05:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Albert Mingkun Yang 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 gclocker
>>  - review
>>  - Merge branch 'master' into gclocker
>>  - gclocker
>
> src/hotspot/share/gc/shared/gcLocker.hpp line 33:
> 
>> 31: 
>> 32: class GCLocker: public AllStatic {
>> 33:   static Monitor* _lock;
> 
> Not sure if having this copy/reference to `Heap_lock` makes the code more clear than referencing `Heap_lock` directly. It needs to be `Heap_lock` anyway.

`GCLocker` itself doesn't mandates that the lock must be `Heap_lock`; it's the interaction with rest of VM that shows that `Heap_lock` is a good candidate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1943040719

From dfuchs at openjdk.org  Wed Feb  5 15:54:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Feb 2025 15:54:16 GMT
Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean,
 its implementation, and accessor method for removal
In-Reply-To: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
References: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
Message-ID: <-8DxvKP7B4LKHHSptr4dIoSs0npdXvTjxRsCuMpTWqs=.f0105578-7d55-4e2d-a0e3-e3183823ca66@github.com>

On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.
> 
> These deprecations should be uprated to state they are for future removal.
> 
> java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.

The implementation of PlatformLoggingMXBean uses reflection to access the LoggingMXBean instance provided by the LogManager. If I am not mistaken what is proposed for removal here is actively used under the hood by the PlatformLoggingMXBean implementation - which means we cannot actually remove it?

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

PR Comment: https://git.openjdk.org/jdk/pull/23271#issuecomment-2637310374

From kevinw at openjdk.org  Wed Feb  5 16:20:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 5 Feb 2025 16:20:57 GMT
Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean,
 its implementation, and accessor method for removal
In-Reply-To: <-8DxvKP7B4LKHHSptr4dIoSs0npdXvTjxRsCuMpTWqs=.f0105578-7d55-4e2d-a0e3-e3183823ca66@github.com>
References: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
 <-8DxvKP7B4LKHHSptr4dIoSs0npdXvTjxRsCuMpTWqs=.f0105578-7d55-4e2d-a0e3-e3183823ca66@github.com>
Message-ID: <7LhVkP-yhPE8sCte6OKiH8MLcgy8ud7iYXM6J-8CjWQ=.e389ffc4-0d12-443c-b16c-1244cff79b82@github.com>

On Wed, 5 Feb 2025 15:51:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.
>> 
>> These deprecations should be uprated to state they are for future removal.
>> 
>> java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.
>
> The implementation of PlatformLoggingMXBean uses reflection to access the LoggingMXBean instance provided by the LogManager. If I am not mistaken what is proposed for removal here is actively used under the hood by the PlatformLoggingMXBean implementation - which means we cannot actually remove it?

Hi @dfuch -

What is proposed here is that java.util.logging.LoggingMXBean should be marked for removal.

Having both PlatformLoggingMXBean and LoggingMXBean in existence is confusing. 

Actual removal is not trivial, as yes the "new" PlatformLoggingMXBean is dependent on the existing LoggingMXBean implementation.

(Looking inside LoggingMXBean and seeing the actual implementations that accesses LogManager is also confusing.)

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

PR Comment: https://git.openjdk.org/jdk/pull/23271#issuecomment-2637389915

From dfuchs at openjdk.org  Wed Feb  5 19:51:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Feb 2025 19:51:04 GMT
Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean,
 its implementation, and accessor method for removal
In-Reply-To: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
References: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
Message-ID: <le5kgz7HLkpgfzk-x8eX3v9YaMCnr1ElkTp8ZnaKlFw=.ac972aec-195b-41e4-96e1-f6d9b8a0f385@github.com>

On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.
> 
> These deprecations should be uprated to state they are for future removal.
> 
> java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.

Maybe a first step should be to stop using the API that are proposed for removal internally. When nothing uses them (except other things that are also proposed for removal), then we can proceed by marking the APIs as deprecated for removal?

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

PR Comment: https://git.openjdk.org/jdk/pull/23271#issuecomment-2637860005

From coleenp at openjdk.org  Wed Feb  5 19:51:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Feb 2025 19:51:06 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
Message-ID: <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>

On Wed, 5 Feb 2025 01:10:39 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright and param name
>
> test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:
> 
>> 71:     public int getAppArrayModifiers() {
>> 72:         return clazzArray.getClass().getModifiers();
>> 73:     }
> 
> I'm guessing this is the benchmark that shows an extra load.  How about adding a benchmark that makes the Clazz[] final or @Stable, and see if that makes the extra load go away?

Name                      Cnt  Base   Error   Test   Error  Unit  Change
getAppArrayModifiers       30 0.923 ? 0.004  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
getAppArrayModifiersFinal  30 0.922 ? 0.000  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)

No it doesn't really help.  There's still an extra load.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943569183

From dlong at openjdk.org  Wed Feb  5 19:51:02 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 19:51:02 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
Message-ID: <mRbhLrczXnuM7AvcJJu7pmwHE2-Q4uTHaA09iboF4n4=.ae954a25-8015-45a3-aa12-1061e6b09bbc@github.com>

On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

I like the direction this is taking us, but I think we could go even further and eventually fold the JNI critical region into the existing safepoint mechanism.  To me, the safepoint mechanism already implements a readers-writer lock, with threads states like _thread_in_Java/_thread_in_vm already being "critical regions".   With this change, we have two nested readers-writer locks that a GC needs to acquire.  I think if we made entering and exiting a JNI critical region change the thread state, (probably by introducing a new thread state), then we don't need a separate readers-writer lock for JNI critical region.  However, maybe we don't want to go that far, as the current solution allows us GC-specific implementations and allows each different GC VMOp to decide if it needs to block for JNI critical regions.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2637865869

From egahlin at openjdk.org  Wed Feb  5 19:59:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 5 Feb 2025 19:59:13 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
Message-ID: <C9c7evEFBD7ROXLD1sQdHXO50d5jr4rzq0XvjE2RFZg=.4b345e8e-d194-4156-99be-153fd78b8221@github.com>

On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

JFR changes look good.

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

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2596847997

From amenkov at openjdk.org  Wed Feb  5 20:11:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 5 Feb 2025 20:11:53 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v2]
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <i1OZ4UFvtpUffKuD1gSdFB5J_9obY8wxqiuKHsWmieY=.00e2f90a-134b-4001-9534-1639a4260a7a@github.com>

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

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

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23405/files
  - new: https://git.openjdk.org/jdk/pull/23405/files/052319f9..96d01f7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=00-01

  Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23405/head:pull/23405

PR: https://git.openjdk.org/jdk/pull/23405

From dlong at openjdk.org  Wed Feb  5 20:26:16 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 20:26:16 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
 <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
Message-ID: <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>

On Wed, 5 Feb 2025 19:42:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:
>> 
>>> 71:     public int getAppArrayModifiers() {
>>> 72:         return clazzArray.getClass().getModifiers();
>>> 73:     }
>> 
>> I'm guessing this is the benchmark that shows an extra load.  How about adding a benchmark that makes the Clazz[] final or @Stable, and see if that makes the extra load go away?
>
> Name                      Cnt  Base   Error   Test   Error  Unit  Change
> getAppArrayModifiers       30 0.923 ? 0.004  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
> getAppArrayModifiersFinal  30 0.922 ? 0.000  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
> 
> No it doesn't really help.  There's still an extra load.

OK, if the extra load turns out to be a problem in the future, we could look into why the compilers are generating the load when the Class is known/constant.  If the old intrinsic was able to pull the constant out of the Klass, then surely we can do the same and pull the value from the Class field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943616021

From dlong at openjdk.org  Wed Feb  5 21:29:12 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 21:29:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

src/hotspot/share/compiler/compileLog.cpp line 116:

> 114:         print(" unloaded='1'");
> 115:       } else {
> 116:         print(" flags='%d'", klass->access_flags());

There may be tools that parse the log file and get confused by this change.  Maybe we should also change the label from "flags" to "access flags".

src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp line 350:

> 348:   writer->write(mark_symbol(klass, leakp));
> 349:   writer->write(package_id(klass, leakp));
> 350:   writer->write(klass->compute_modifier_flags());

Isn't this much more expensive than grabbing the value from the mirror, especially if we have to iterate over inner classes?

src/hotspot/share/oops/instanceKlass.hpp line 1128:

> 1126: #endif
> 1127: 
> 1128:   int compute_modifier_flags() const;

I don't see why this can't stay u2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943680670
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943679056
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943682936

From dlong at openjdk.org  Wed Feb  5 21:43:14 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 21:43:14 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <NvrhD47QIH5G8TfOihEL7SyCjPdfd2jP6mOI5gyDBXo=.9d21e6b9-e527-437a-a90b-37fc7a6b7472@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

src/hotspot/share/opto/memnode.cpp line 2458:

> 2456:           return TypePtr::NULL_PTR;
> 2457:         }
> 2458:         // ???

I suspect that we still need this code to support intrinsics like LibraryCallKit::inline_native_classID() and maybe other users of this field, but the comment below no longer makes sense.

src/hotspot/share/opto/memnode.cpp line 2459:

> 2457:         }
> 2458:         // ???
> 2459:         // (Folds up the 1st indirection in aClassConstant.getModifiers().)

Suggestion:

        // Fold up the load of the hidden field

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943695585
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943696867

From dlong at openjdk.org  Wed Feb  5 21:47:12 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 21:47:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
 <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
 <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>
Message-ID: <yuiSOJZCDOCs2H5MHBg5FZnJYjy4XxsEnRy87qL8DFg=.1d5fac0f-8695-4e26-ac3f-0d787421607f@github.com>

On Thu, 12 Dec 2024 10:16:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> @viktorklang-ora `@Stable` is not about how the field was set, but about the JIT observing a  non-default value at compile time.  If it observes a non-default value, it can treat it as a compile time constant.
>
> @DanHeidinga Great explanation, thank you!

If Class had other fields smaller than `int`, would be consider making this something like `char` to save space (allowing all the sub-word fields to be compacted)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1943701237

From dlong at openjdk.org  Wed Feb  5 21:53:11 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 5 Feb 2025 21:53:11 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <yTbRwO_J0qBiFJYLzUj0UUqfZFFJJJk0FvwVY1V11mk=.360808a6-849f-4487-9176-60957be5d811@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

Overall looks good to me.  Please ask @iwanowww to review compiler changes.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2597046622

From dholmes at openjdk.org  Thu Feb  6 01:52:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 01:52:57 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and
 parsing
Message-ID: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>

This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.

JDK-8348190: Framework for tracing makefile inclusion and parsing

The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.

Thanks.

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

Commit messages:
 - Revert "8348190: Framework for tracing makefile inclusion and parsing"

Changes: https://git.openjdk.org/jdk/pull/23481/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349511
  Stats: 2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod
  Patch: https://git.openjdk.org/jdk/pull/23481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23481/head:pull/23481

PR: https://git.openjdk.org/jdk/pull/23481

From darcy at openjdk.org  Thu Feb  6 02:04:15 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Feb 2025 02:04:15 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Approving clean backout.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597463613

From dholmes at openjdk.org  Thu Feb  6 02:44:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:44:08 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
Message-ID: <AWJoVSTeygOR6BO1A3fQOGLPGVzlF6zuRNMw4TMiVZc=.cf4c9f9e-75b8-45ef-b295-8fb57846fa24@github.com>

On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Approving clean backout.

Thanks @jddarcy !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638687813

From mikael at openjdk.org  Thu Feb  6 02:54:17 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 6 Feb 2025 02:54:17 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597531112

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
Message-ID: <o_LWA-N7-KZ6e3MLu8U2GOcgFRK6rgW58IWj5sGK_6s=.12f73a3c-70ce-49c3-b486-1585990fefac@github.com>

On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Marked as reviewed by mikael (Reviewer).

Thanks @vidmik !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638701374

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: Integrated: 8349511: [BACKOUT] Framework for tracing makefile
 inclusion and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <aWuh7nyeGLH2h82Pk0IN4KD8wwSrAXkioaZ_EWlOWN4=.5e1f6202-37f7-4b5a-a36a-2adf4ca85b10@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 64bd8d25
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2
Stats:     2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod

8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

Reviewed-by: darcy, mikael

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

PR: https://git.openjdk.org/jdk/pull/23481

From liach at openjdk.org  Thu Feb  6 04:40:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Feb 2025 04:40:11 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
 <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
 <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>
Message-ID: <7KdNVSXLx0N027uyQgtUuN82VpXTlyPpPOnBv3sqYRs=.6b549b56-36f9-4ab3-8469-4779d93dd1e7@github.com>

On Wed, 5 Feb 2025 20:23:05 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Name                      Cnt  Base   Error   Test   Error  Unit  Change
>> getAppArrayModifiers       30 0.923 ? 0.004  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
>> getAppArrayModifiersFinal  30 0.922 ? 0.000  1.260 ? 0.001 ns/op   0.73x (p = 0.000*)
>> 
>> No it doesn't really help.  There's still an extra load.
>
> OK, if the extra load turns out to be a problem in the future, we could look into why the compilers are generating the load when the Class is known/constant.  If the old intrinsic was able to pull the constant out of the Klass, then surely we can do the same and pull the value from the Class field.

Does `static final` help here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944083490

From dholmes at openjdk.org  Thu Feb  6 06:28:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 06:28:13 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
Message-ID: <Rw5jeyFJmYDfgALzFzf2PgEMf7RrpExCSqs74oZN7kI=.7d5bbf5e-19f2-457e-b08b-9ead9a4351ec@github.com>

On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

src/hotspot/share/runtime/javaThread.hpp line 938:

> 936:   }
> 937: 
> 938:   bool in_critical_atomic()    { return Atomic::load(&_jni_active_critical) > 0; }

If you think you need an atomic load here, then it would be needed for `in_critical()` so just add it there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1944166423

From dholmes at openjdk.org  Thu Feb  6 06:38:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 06:38:13 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
Message-ID: <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>

On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

> this PR uses an existing thread-local variable with a store-load barrier for synchronization.

@albertnetymk  can you explain how this protocol is intended to work please. I must be missing some higher-level context that provides additional synchronization because use of the per-thread counters is inherently racy.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2638958442

From dholmes at openjdk.org  Thu Feb  6 06:41:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 06:41:21 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <mRbhLrczXnuM7AvcJJu7pmwHE2-Q4uTHaA09iboF4n4=.ae954a25-8015-45a3-aa12-1061e6b09bbc@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <mRbhLrczXnuM7AvcJJu7pmwHE2-Q4uTHaA09iboF4n4=.ae954a25-8015-45a3-aa12-1061e6b09bbc@github.com>
Message-ID: <Nz4-Vb2Voo286H1QbFNCORxz2IzWjILYVJG4rXT5wEg=.c5157a2c-f156-459a-a1b6-297b3c258506@github.com>

On Wed, 5 Feb 2025 19:39:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>  I think we could go even further and eventually fold the JNI critical region into the existing safepoint mechanism.

@dean-long you seem to be forgetting why it was folded out in the first place. :) This was performance critical JNI code where the thread-state transitions were too heavyweight and expensive to use. So we keep the thread safepoint-safe (`_thread_in_native`) and have a way to tell the GC to pause whilst we are in these critical regions.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2638962365

From dholmes at openjdk.org  Thu Feb  6 07:03:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 07:03:19 GMT
Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass
 [v3]
In-Reply-To: <Q68prEVwcDw3SdnPdJBLiFhULf6LFr57IqYUAOAOECk=.379be364-3a3c-43fc-88f8-096a99c3f1cf@github.com>
References: <pxpFAGJcpI2NQjude2t70BPMmIl6rT3s3JUoi-MV3WQ=.eddb6a6f-6ee3-4592-a1ee-74c6200fad31@github.com>
 <il4KXlFgg1WhYmKowy3o_WOv6JJm1WY_Jek3_fs_rbA=.bf263451-182d-4cd9-8a37-371974c1dc2d@github.com>
 <NwOLYF3kR2b4HOZf6RxCQWq8F6ucWRIfi2ArqUiwKcI=.a0e56be6-9070-4a7d-95c1-6c51b7d4ef8a@github.com>
 <Q68prEVwcDw3SdnPdJBLiFhULf6LFr57IqYUAOAOECk=.379be364-3a3c-43fc-88f8-096a99c3f1cf@github.com>
Message-ID: <xwWwkCpz9pnwu-W62TAVrAGFSed-6g8te-g23Bxa5eE=.543d9ae4-da56-4832-9e32-66584eb2c6e4@github.com>

On Wed, 5 Feb 2025 14:04:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Thanks David and Johan for the reviews.
>
> Hi @coleenp, 
> 
> I am repeating the message from Theresa, since she is part of OpenJ9 and can't accept  OpenJDK Terms: 
> 
> 
> `serviceability/jvmti/RedefineClasses/RedefineVerifyError.java` I believe the correct behavior should be throwing a ClassFormatException since the generated class is not well formed.
> 
> According to the JVM specification in section 4.7.3 The Code Attribute:
> 
> If the method is either native or abstract, and is not a class or interface
> initialization method, then its method_info structure must not have a Code attribute
> in its attributes table. Otherwise, its method_info structure must have exactly
> one Code attribute in its attributes table.
> also
> The value of code_length must be greater than zero
> 
> Can you clarify why VerifyError is expected to be caught here?

Hi Amit (@offamitkumar ),

I think the answer to that is already given above:

https://github.com/openjdk/jdk/pull/22116#discussion_r1850265592

> The JVMTI code for redefinition returns JVMTI_ERROR_FAILS_VERIFICATION and not the pending exception to the caller. The agent eventually in java.instrument/share/native/libinstrument/JavaExceptions.c will recreate the VerifyError based on the JVMTI error code.

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

PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2638992732

From coleenp at openjdk.org  Thu Feb  6 12:11:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 12:11:14 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <yuiSOJZCDOCs2H5MHBg5FZnJYjy4XxsEnRy87qL8DFg=.1d5fac0f-8695-4e26-ac3f-0d787421607f@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
 <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
 <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>
 <yuiSOJZCDOCs2H5MHBg5FZnJYjy4XxsEnRy87qL8DFg=.1d5fac0f-8695-4e26-ac3f-0d787421607f@github.com>
Message-ID: <4aAX8rSEcvkeYteaJUXHfVEzBbNGwGlhDLIz548dFcs=.616fa7dd-d5bf-42d5-aca0-0bea0b5591d0@github.com>

On Wed, 5 Feb 2025 21:44:37 GMT, Dean Long <dlong at openjdk.org> wrote:

>> @DanHeidinga Great explanation, thank you!
>
> If Class had other fields smaller than `int`, would be consider making this something like `char` to save space (allowing all the sub-word fields to be compacted)?

I thought of doing this since I made modifiers u2 in the Hotspot code just previously, but all the Java code refers to this as an int.  And I didn't see other fields to compact it with.  Maybe if access_flags are moved we could make them both char (not short since they're unsigned).  It feels weird to not have unsigned short to my C++ eyes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944613105

From coleenp at openjdk.org  Thu Feb  6 13:13:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:13:29 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
Message-ID: <gqMJXQpP6idR6RS6bHOqE8D6JI8mlg5JpqZDcCc0L7o=.590b8dd1-a70f-4af4-88be-3fb205b8870c@github.com>

On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright and param name

Thank you for the detailed comments.

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

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2598534835

From coleenp at openjdk.org  Thu Feb  6 13:13:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:13:29 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v3]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <eZJdUNeSPci8TGUYqbi99392SJYBoDfBV2YSQWJleaI=.4f05072f-5d2d-4a6d-81b1-333305cd07c1@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/opto/memnode.cpp
  
  Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/ff693418..f92620eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Thu Feb  6 13:13:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:13:29 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>
Message-ID: <H3qkoCqZwtAyXL1ZWdPnuzvkV3ZRUuM565siUlSO4lM=.2339a020-bf74-41a4-adbf-2273284d06b6@github.com>

On Wed, 5 Feb 2025 21:24:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright and param name
>
> src/hotspot/share/compiler/compileLog.cpp line 116:
> 
>> 114:         print(" unloaded='1'");
>> 115:       } else {
>> 116:         print(" flags='%d'", klass->access_flags());
> 
> There may be tools that parse the log file and get confused by this change.  Maybe we should also change the label from "flags" to "access flags".

Okay, I wanted to remove the one use of ciKlass::modifier_flags() and the field with this change, but I'll add it back since I added a Klass::modifier_flags() function.

> src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp line 350:
> 
>> 348:   writer->write(mark_symbol(klass, leakp));
>> 349:   writer->write(package_id(klass, leakp));
>> 350:   writer->write(klass->compute_modifier_flags());
> 
> Isn't this much more expensive than grabbing the value from the mirror, especially if we have to iterate over inner classes?

I was trying not to add a Klass::modifier_flags function, but now I have.

> src/hotspot/share/opto/memnode.cpp line 2458:
> 
>> 2456:           return TypePtr::NULL_PTR;
>> 2457:         }
>> 2458:         // ???
> 
> I suspect that we still need this code to support intrinsics like LibraryCallKit::inline_native_classID() and maybe other users of this field, but the comment below no longer makes sense.

Thank you for noticing the ??? that I left in and the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944651499
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944640356
PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944697467

From coleenp at openjdk.org  Thu Feb  6 13:13:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:13:30 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <7KdNVSXLx0N027uyQgtUuN82VpXTlyPpPOnBv3sqYRs=.6b549b56-36f9-4ab3-8469-4779d93dd1e7@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
 <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
 <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>
 <7KdNVSXLx0N027uyQgtUuN82VpXTlyPpPOnBv3sqYRs=.6b549b56-36f9-4ab3-8469-4779d93dd1e7@github.com>
Message-ID: <fIDzS3_DxYMZA78UX_HiBqnAPvUcE2qhBfw30T2hrv4=.d65d867b-2a38-49b7-ba1b-8284ae19e7d2@github.com>

On Thu, 6 Feb 2025 04:37:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> OK, if the extra load turns out to be a problem in the future, we could look into why the compilers are generating the load when the Class is known/constant.  If the old intrinsic was able to pull the constant out of the Klass, then surely we can do the same and pull the value from the Class field.
>
> Does `static final` help here?

Yes.  Yes it does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944694824

From coleenp at openjdk.org  Thu Feb  6 13:23:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 13:23:54 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v4]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <4ruwzJXM3Jgy0rbobE3PPNAH4k8c10_4zAi6mCmc4Lw=.ccf7c825-4ffc-49fb-bc42-3c0168c1dcf8@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add Klass::modifier_flags to look in the mirror, restore ciKlass::modifier_flags, add benchmark.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/f92620eb..85026362

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=02-03

  Stats: 28 lines in 7 files changed: 26 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Thu Feb  6 14:31:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 14:31:28 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v5]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Make compute_modifiers return u2.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/85026362..146e2551

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=03-04

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Thu Feb  6 14:31:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 14:31:29 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <1yPHOj_hANp7ZvMfmgi6lRkpokgNNaUSc09FJfZvWk8=.bfcf2780-4afe-4253-ae0b-e3bc6ab7ee86@github.com>
Message-ID: <9iIj0xWClD_H4U0MiEUrQGqeIgjyFdC4tuN0sAP9kUo=.1c11d464-4380-4954-9e9f-c40872acff24@github.com>

On Wed, 5 Feb 2025 21:26:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright and param name
>
> src/hotspot/share/oops/instanceKlass.hpp line 1128:
> 
>> 1126: #endif
>> 1127: 
>> 1128:   int compute_modifier_flags() const;
> 
> I don't see why this can't stay u2.

I had some compilation error for conversion that has disappeared into the either with u2, so I've restored them to u2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1944825437

From liach at openjdk.org  Thu Feb  6 16:20:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 6 Feb 2025 16:20:21 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v5]
In-Reply-To: <4aAX8rSEcvkeYteaJUXHfVEzBbNGwGlhDLIz548dFcs=.616fa7dd-d5bf-42d5-aca0-0bea0b5591d0@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <yhyfqAgCbPEVVVdWt3CVX5gjPVSy0LQfQEUlWciih34=.f23c9cbc-ebc3-4f50-9223-a034d1fdc6a0@github.com>
 <ry9lIOtqKOCl6v48h9bIbACNHJleAKYwRXCkd_0VkfU=.9d87f360-b867-46cc-a44a-88ba991980ec@github.com>
 <rRoMJbmO4ZFCagXgmezUlgTxe48usUja4KqhdmXDsjk=.568fe8d4-1fbd-4dfc-99e8-5941b67248de@github.com>
 <yjBy9m5yM18_XOZjEN8dn5osnTUPviOliyM_qNHoKgQ=.f9c43bc8-4bee-46bb-b466-7d471bfcd582@github.com>
 <8Wx3xbbOnPXS5n1RuNaesqHbhKV3iLwrCVF0s6uWOrA=.cb20728e-e13c-4667-822b-3ba424cbc12f@github.com>
 <yuiSOJZCDOCs2H5MHBg5FZnJYjy4XxsEnRy87qL8DFg=.1d5fac0f-8695-4e26-ac3f-0d787421607f@github.com>
 <4aAX8rSEcvkeYteaJUXHfVEzBbNGwGlhDLIz548dFcs=.616fa7dd-d5bf-42d5-aca0-0bea0b5591d0@github.com>
Message-ID: <UIvrfGyV8aaiXHhTfrdrdhWX12Vx4kjonBNRFEwtTbw=.d008ebb0-d865-444e-b9c3-d198ff57bf7b@github.com>

On Thu, 6 Feb 2025 12:08:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> If Class had other fields smaller than `int`, would be consider making this something like `char` to save space (allowing all the sub-word fields to be compacted)?
>
> I thought of doing this since I made modifiers u2 in the Hotspot code just previously, but all the Java code refers to this as an int.  And I didn't see other fields to compact it with.  Maybe if access_flags are moved we could make them both char (not short since they're unsigned).  It feels weird to not have unsigned short to my C++ eyes.

>From a Java perspective, using `char` for the field is completely fine; this field is only accessed via `getModifiers` and not set by Java code, so the automatic widening conversion can handle it all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1945021458

From coleenp at openjdk.org  Thu Feb  6 18:44:23 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 18:44:23 GMT
Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass
 [v3]
In-Reply-To: <il4KXlFgg1WhYmKowy3o_WOv6JJm1WY_Jek3_fs_rbA=.bf263451-182d-4cd9-8a37-371974c1dc2d@github.com>
References: <pxpFAGJcpI2NQjude2t70BPMmIl6rT3s3JUoi-MV3WQ=.eddb6a6f-6ee3-4592-a1ee-74c6200fad31@github.com>
 <il4KXlFgg1WhYmKowy3o_WOv6JJm1WY_Jek3_fs_rbA=.bf263451-182d-4cd9-8a37-371974c1dc2d@github.com>
Message-ID: <QTz1M2nrFeExBl3PCQ1NhvJvjQf1gq30GkfI1fnfze8=.a20665b7-8b3a-4bf1-8f57-8c93874a8a7c@github.com>

On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path.
>> 
>> The fix for always verifying redefined classes was actually pushed with JDK-8341094, where the verifier code respected the parameter "should_verify_class".  By default this parameter follows the -Xverify setting.  For redefinition, this is passed as true.   The rest of the fix removes the special bootstrap loader cases that may have failed early on in the JDK development with -Xverify:all but now no longer do.  If someone tries to redefine these classes, they should also do the verification on the redefined bytecodes.
>> 
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification.

Thanks for answering David.  The new class should get a VerifyError not a ClassFormatError - the bytecodes were incorrect, as detected by the verifier.  It's not missing a code attribute but the code is truncated as reported with -Xlog:exceptions:


[0.339s][info][exceptions] Exception <a 'java/lang/VerifyError'{0x00000007ff8850c8}: Control flow falls through code end
[                        ] Exception Details:
[                        ]   Location:
[                        ]     java/lang/VerifyError.<init>()V @0: <invalid>
[                        ]   Reason:
[                        ]     Error exists in the bytecode
[                        ]   Bytecode:
[                        ]     0000000:
[                        ] > (0x00000007ff8850c8)
[                        ] thrown [/scratch/cphillim/hg/jdk-ci-pd/open/src/hotspot/share/classfile/verifier.cpp, line 293]
[                        ] for thread 0x000075ea2cbbe260


In the test the methods are here just don't have anything in them:


        {
            methodVisitor = classWriter.visitMethod(ACC_PUBLIC, "<init>", "()V", null, null);
            methodVisitor.visitCode();
            methodVisitor.visitEnd();
        }

        {
            methodVisitor = classWriter.visitMethod(ACC_PUBLIC, "<init>", "(Ljava/lang/String;)V", null, null);
            methodVisitor.visitCode();
            classWriter.visitEnd();
        }


So VerifyError is the right exception.  It might be that you need to add some nop() bytecode or something to generate the code attribute?

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

PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2640709606

From sspitsyn at openjdk.org  Thu Feb  6 19:09:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 6 Feb 2025 19:09:11 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v2]
In-Reply-To: <i1OZ4UFvtpUffKuD1gSdFB5J_9obY8wxqiuKHsWmieY=.00e2f90a-134b-4001-9534-1639a4260a7a@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <i1OZ4UFvtpUffKuD1gSdFB5J_9obY8wxqiuKHsWmieY=.00e2f90a-134b-4001-9534-1639a4260a7a@github.com>
Message-ID: <PCEhAb-rdPA577pJ0vO5tyrwxB9LZGwlPXAA_ifQ4TE=.5c9061bf-6117-478d-b565-0cb0ec58d6e1@github.com>

On Wed, 5 Feb 2025 20:11:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix implements streaming output support for attach protocol.
>> See JBS issue for evaluation, summary of the changes in the 1st comment.
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java line 70:

> 68: 
> 69:     private static void attach(LingeredApp app, boolean clientStreaming, boolean vmStreaming) throws Exception {
> 70:         HotSpotVirtualMachine vm = (HotSpotVirtualMachine)VirtualMachine.attach(String.valueOf(app.getPid()));

Q: It is confusing that both boolean arguments are not used. Would you like to get rid of them?

test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java line 86:

> 84: 
> 85:     private static void verify(boolean clientStreaming, boolean vmStreaming, String out) throws Exception {
> 86:         System.out.println("Target VM output:");

Q: It is confusing that the boolean argument vmStreaming is not used. Would you like to get rid of it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945156555
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945158080

From amenkov at openjdk.org  Thu Feb  6 20:23:32 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Feb 2025 20:23:32 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v3]
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <4Bmzepx0oatn_NqbrzEdCMEQCBBpPwV1VW7KymjdrUQ=.09ea6870-2d00-4059-acb5-df53b72a25ef@github.com>

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

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

  feedback - test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23405/files
  - new: https://git.openjdk.org/jdk/pull/23405/files/96d01f7c..d074f2f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=01-02

  Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23405/head:pull/23405

PR: https://git.openjdk.org/jdk/pull/23405

From vlivanov at openjdk.org  Thu Feb  6 21:15:12 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 6 Feb 2025 21:15:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v2]
In-Reply-To: <fIDzS3_DxYMZA78UX_HiBqnAPvUcE2qhBfw30T2hrv4=.d65d867b-2a38-49b7-ba1b-8284ae19e7d2@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <J3izMa8E182ejKhvLNQc0U__1Eswe4pAcSZd-g5OYEs=.ce24eab9-9e04-4220-9300-b81bee0453db@github.com>
 <EU357-FKuMBGUepB5H3CyvB-YhnJbRrvE0Zwab63Gw0=.3f51e9e8-0c3a-4d60-84fa-2fc8db065990@github.com>
 <0ZM_vg_dAmbdbeoIeZ8ylBUDj_4_jxM-aE6IKoH6ykM=.69c7554f-5e2b-40b9-8d1a-abe147548dbb@github.com>
 <0efX7bcHNl5p1RoF3VnqZIabdavsGosuMI14cZPDzbQ=.2bde6bbf-a59b-4f5b-9c68-7a8a258b2ee5@github.com>
 <7KdNVSXLx0N027uyQgtUuN82VpXTlyPpPOnBv3sqYRs=.6b549b56-36f9-4ab3-8469-4779d93dd1e7@github.com>
 <fIDzS3_DxYMZA78UX_HiBqnAPvUcE2qhBfw30T2hrv4=.d65d867b-2a38-49b7-ba1b-8284ae19e7d2@github.com>
Message-ID: <UYowvIDtIq6dD29gTSkg0hhi4JsrmETGcFNPuGrE_6Y=.bd96c4b1-3882-414a-ab6b-30abac2e665e@github.com>

On Thu, 6 Feb 2025 13:08:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Does `static final` help here?
>
> Yes.  Yes it does.

Cases when a class mirror is a compile-time constant are already well-optimized. Non constant cases are the ones where missing optimization opportunities arise. 

In this particular case, C2 doesn't benefit from the observation that `Clazz[]` is a leaf type at runtime (no subclasses). Hence, a value loaded from a field typed as `Clazz[]` has exactly the same type and `clazzArray.getClass()` can be constant folded to `Clazz[].class`.  Rather than a common case, it feels more like a corner case. So, worth addressing as a follow-up enhancement.

Another scenario is a meet of 2 primitive array types (ends up as `bottom[]` in C2 type system), but I believe it hasn't been optimized before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22652#discussion_r1945451909

From vlivanov at openjdk.org  Thu Feb  6 21:21:18 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 6 Feb 2025 21:21:18 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v5]
In-Reply-To: <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>
Message-ID: <YvJXs2OX-TBzUmJg0UJjwiVexzE85_cm_CQyX5FZZeo=.9bbcaeaf-06e0-4ea8-8a04-40b06a9cfc3f@github.com>

On Thu, 6 Feb 2025 14:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make compute_modifiers return u2.

Looks good. (Except a left-over `???` in a comment.)

I very much like this cleanup. Migrating from Klass to Class simplifies compiler logic since there's no need to care about primitives at runtime anymore.

Speaking of missing optimization opportunities (demonstrated by one microbenchmark), it looks like a corner case and can be addressed later.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2599983789

From ayang at openjdk.org  Thu Feb  6 21:45:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 6 Feb 2025 21:45:13 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>
Message-ID: <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>

On Thu, 6 Feb 2025 06:35:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> can you explain how this protocol is intended to work please. 

When a GC is requested, the `block()` function sets `_is_gc_request_pending` to `true` and then waits until all threads have exited their critical regions. Any thread attempting to enter a critical region during this time will detect the pending GC flag in `enter()` and follow the slow path, effectively waiting until the GC completes. The storeload barrier is critical to ensure that these two variables -- `_is_gc_request_pending` and the thread-local `_jni_active_critical` -- are accessed in the proper order.

> If you think you need an atomic load here, then it would be needed for in_critical() so just add it there.

`in_critical()` is used only by the owning thread, which has exclusive write access. Therefore, its access does not need to be atomic. However, the reads performed by other threads must be atomic, I believe.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2641116616

From cjplummer at openjdk.org  Thu Feb  6 22:44:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 6 Feb 2025 22:44:48 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
Message-ID: <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>

> Cleanup SA JavaThread support. Details in first comment:
> 
> Testing:
> - Tier1
> - Tier2 svc
> - Tier3
> - Tier5 svc
> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  update comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23456/files
  - new: https://git.openjdk.org/jdk/pull/23456/files/d13d365c..da818050

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23456&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23456&range=00-01

  Stats: 5 lines in 1 file changed: 1 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23456/head:pull/23456

PR: https://git.openjdk.org/jdk/pull/23456

From cjplummer at openjdk.org  Thu Feb  6 23:26:23 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 6 Feb 2025 23:26:23 GMT
Subject: RFR: 8349571: Remove JavaThreadFactory interface from SA
Message-ID: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>

The SA JavaThreadFactory interface is no longer used, so it is being removed. I stumbled on it while looking at JavaThread related code. It looks like it's original purpose is related to JavaThread subclasses at one point being platform dependent, as described in the following JavaThread.java comment:


/** This is an abstract class because there are certain OS- and
    CPU-specific operations (like the setting and getting of the last
    Java frame pointer) which need to be factored out. These
    operations are implemented by, for example,
    SolarisSPARCJavaThread, and the concrete subclasses are
    instantiated by the JavaThreadFactory in the Threads class. */


However, this is no longer the case, and this comment is being removed as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347).

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

Commit messages:
 - Remove JavaThreadFactory

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

PR: https://git.openjdk.org/jdk/pull/23505

From coleenp at openjdk.org  Thu Feb  6 23:26:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 23:26:31 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v6]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <FQVTF7A94az6n1bHbNae0CuaicfYRTcEh8qUzM7077s=.796fa77d-b455-4d96-b8ae-f6e1453c589a@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - Remove ??? in the code.
 - Hide Class.modifiers field.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/146e2551..304a17ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=04-05

  Stats: 6 lines in 3 files changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22652/head:pull/22652

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Thu Feb  6 23:26:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 6 Feb 2025 23:26:31 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v5]
In-Reply-To: <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <Rnq14bXvkpbsJQdX-PF9uNr86akoq0ujgHPrFBLfIqY=.0278cab5-71ed-4a80-a751-e38248928e2e@github.com>
Message-ID: <IpxDRodyniGksNWI6F0ool2cmMfdnxV-lTXSLWFjYxg=.b23c920e-0d65-46e5-a4ce-697dbc638c3e@github.com>

On Thu, 6 Feb 2025 14:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make compute_modifiers return u2.

Thank you Vladimir for encouraging me to continue this change.  I removed the ??? and hid the modifiers field for reflection as suggested in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2641339406

From amenkov at openjdk.org  Fri Feb  7 02:41:22 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Feb 2025 02:41:22 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v3]
In-Reply-To: <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
Message-ID: <wR14BqOJRmmtlCfXptoM9T6KhDAEFfw_b0MInjRa6OI=.1c799296-8137-41f6-bc79-371c4c63789c@github.com>

On Tue, 4 Feb 2025 10:10:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback - test
>
> src/hotspot/share/services/attachListener.cpp line 53:
> 
>> 51: 
>> 52: // Stream for printing attach operation results.
>> 53: // Supports buffered and streaming output for commands which can produce lenghtly reply.
> 
> "lengthy"

Fixed

> src/hotspot/share/services/attachListener.cpp line 56:
> 
>> 54: //
>> 55: // To support streaming output platform implementation need to implement AttachOperation::get_reply_writer() method
>> 56: // and ctor allow_streaming argument should be set to true.
> 
> Strange mix of "need" and "should".
> 
> Can we split this into multiple sentences? Here's a suggestion, though I'm not sure if it's 100% correct :-).
> 
> 
> An output platform implementation supports streaming if it implements AttachOperation::get_reply_writer().
> Streaming is enabled if the allow_streaming in the constructor is set to true.

Updated the comment

> src/hotspot/share/services/diagnosticFramework.cpp line 389:
> 
>> 387:   int count = 0;
>> 388:   while (iter.has_next()) {
>> 389:     if(_source == DCmd_Source_MBean && count > 0) {
> 
> Pre-existing style: Space between `if` and condition missing.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945879751
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945879963
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945879828

From amenkov at openjdk.org  Fri Feb  7 02:41:22 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Feb 2025 02:41:22 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v3]
In-Reply-To: <UCRtDbHSoHl32c6SaNEEQ9Qr9JJI0W_mcNuXu3AVdcE=.c8995b19-935b-49c4-982f-704ffecfe244@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
 <enrXXa7riPRBAadgRnhiIkygHK2D0EYKXjyVtr_sb6M=.3fcc000d-10bf-47d6-9108-3c65cc176613@github.com>
 <UCRtDbHSoHl32c6SaNEEQ9Qr9JJI0W_mcNuXu3AVdcE=.c8995b19-935b-49c4-982f-704ffecfe244@github.com>
Message-ID: <mEMWx8GfJ_cjB7DrnrJJXEv6obPbro3oKcV-CxMbDY8=.2ddc7f22-d669-4df7-83c9-ca4b1ceb472e@github.com>

On Wed, 5 Feb 2025 07:24:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is for [JDK-8319307](https://bugs.openjdk.org/browse/JDK-8319307)
>> @tstuefe Do you want to keep this comment to work on JDK-8319307?
>
> You can remove it.

Removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945880034

From amenkov at openjdk.org  Fri Feb  7 02:41:22 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Feb 2025 02:41:22 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v2]
In-Reply-To: <PCEhAb-rdPA577pJ0vO5tyrwxB9LZGwlPXAA_ifQ4TE=.5c9061bf-6117-478d-b565-0cb0ec58d6e1@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <i1OZ4UFvtpUffKuD1gSdFB5J_9obY8wxqiuKHsWmieY=.00e2f90a-134b-4001-9534-1639a4260a7a@github.com>
 <PCEhAb-rdPA577pJ0vO5tyrwxB9LZGwlPXAA_ifQ4TE=.5c9061bf-6117-478d-b565-0cb0ec58d6e1@github.com>
Message-ID: <cgZam8g-zVtwISdy0yaAZm41v4_yLZGKw47DczFHFhI=.e8a97d5a-519b-4abc-bac5-d3ac86a1bb35@github.com>

On Thu, 6 Feb 2025 17:34:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java line 70:
> 
>> 68: 
>> 69:     private static void attach(LingeredApp app, boolean clientStreaming, boolean vmStreaming) throws Exception {
>> 70:         HotSpotVirtualMachine vm = (HotSpotVirtualMachine)VirtualMachine.attach(String.valueOf(app.getPid()));
> 
> Q: It is confusing that both boolean arguments are not used. Would you like to get rid of them?

Dropped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945880212

From amenkov at openjdk.org  Fri Feb  7 02:44:36 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Feb 2025 02:44:36 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v2]
In-Reply-To: <PCEhAb-rdPA577pJ0vO5tyrwxB9LZGwlPXAA_ifQ4TE=.5c9061bf-6117-478d-b565-0cb0ec58d6e1@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <i1OZ4UFvtpUffKuD1gSdFB5J_9obY8wxqiuKHsWmieY=.00e2f90a-134b-4001-9534-1639a4260a7a@github.com>
 <PCEhAb-rdPA577pJ0vO5tyrwxB9LZGwlPXAA_ifQ4TE=.5c9061bf-6117-478d-b565-0cb0ec58d6e1@github.com>
Message-ID: <akjyqJ1cKtY5IwiEorOWOwNSB0YaYdg7R6nZFWD2nOw=.78112527-710c-4cea-aa11-bfeafd9fdc4f@github.com>

On Thu, 6 Feb 2025 17:35:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java line 86:
> 
>> 84: 
>> 85:     private static void verify(boolean clientStreaming, boolean vmStreaming, String out) throws Exception {
>> 86:         System.out.println("Target VM output:");
> 
> Q: It is confusing that the boolean argument vmStreaming is not used. Would you like to get rid of it?

Added verification for expected value.
Also updated logging and verification of clientStreaming to not fail on AIX (AIX does not support streaming output yet as I don't have an environment to test it)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1945881941

From dholmes at openjdk.org  Fri Feb  7 06:46:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Feb 2025 06:46:10 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>
 <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>
Message-ID: <zAeXXZW_4kcwsb3KRuM3WtzNxLFg6hxLlGAZrjb5fVM=.4837c962-5da8-4509-86a9-ce9d55c10f53@github.com>

On Thu, 6 Feb 2025 21:42:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> in_critical() is used only by the owning thread,

I see code using `thr->in_critical()` which is not obviously being executed by the current thread on itself. But in any case adding the atomic load to `in_critical()` is basically a no-op (loads are atomic) so no need to add a new API just to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2642070840

From dholmes at openjdk.org  Fri Feb  7 07:01:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Feb 2025 07:01:39 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>
 <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>
Message-ID: <ndrvB8CHcFiV-OwfnhKOgkainmEW_ct4fJZn28CqE4E=.e7b3a83b-89f6-43f6-8ee2-0ba540215fd4@github.com>

On Thu, 6 Feb 2025 21:42:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The storeload barrier is critical  ...

I'm not sure it is sufficient. I would have expected some full fences to be needed here as this is very similar to the interaction of thread state with safepoints. I will look closer on Monday (sorry).

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2642089369

From kevinw at openjdk.org  Fri Feb  7 11:42:09 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 7 Feb 2025 11:42:09 GMT
Subject: RFR: 8349571: Remove JavaThreadFactory interface from SA
In-Reply-To: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>
References: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>
Message-ID: <Vz6pd65JrIl9KQYbiOZCkjQaMYAs5-IGBQL6e6dNEVM=.e1af770e-406f-4f65-86da-be0386365cc7@github.com>

On Thu, 6 Feb 2025 23:22:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The SA JavaThreadFactory interface is no longer used, so it is being removed. I stumbled on it while looking at JavaThread related code. It looks like it's original purpose is related to JavaThread subclasses at one point being platform dependent, as described in the following JavaThread.java comment:
> 
> 
> /** This is an abstract class because there are certain OS- and
>     CPU-specific operations (like the setting and getting of the last
>     Java frame pointer) which need to be factored out. These
>     operations are implemented by, for example,
>     SolarisSPARCJavaThread, and the concrete subclasses are
>     instantiated by the JavaThreadFactory in the Threads class. */
> 
> 
> However, this is no longer the case, and this comment is being removed as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347).

Looks good, I see no other references.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23505#pullrequestreview-2601518642

From coleenp at openjdk.org  Fri Feb  7 12:34:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Feb 2025 12:34:40 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix jvmci test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22652/files
  - new: https://git.openjdk.org/jdk/pull/22652/files/304a17ee..37a8cf81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22652&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/22652

From coleenp at openjdk.org  Fri Feb  7 19:16:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Feb 2025 19:16:13 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <lE8Fzktp5eGkcXgqGo9BX2XZ-7nP2_63aoED1jxBbtk=.8dcfa9e0-c8a8-4922-937e-fdb22ee84c95@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

I added some code to hide the Class.modifiers field and fixed the JVMCI test. Please re-review.

Also @iwanowww I think the intrinsic for isInterface can be removed and just be Java code like:


public boolean isInterface()  {
  return getModifiers().isInterface();
}

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2643799984

From vlivanov at openjdk.org  Fri Feb  7 19:47:12 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Feb 2025 19:47:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <RwOpQ-TzMSazfLgxqUZ5fJcdzBmOHvhfgnelely73SQ=.0dbfb18a-98d1-4342-b897-1d99900fb3ec@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

Marked as reviewed by vlivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2602686659

From vlivanov at openjdk.org  Fri Feb  7 20:01:27 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 7 Feb 2025 20:01:27 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <lE8Fzktp5eGkcXgqGo9BX2XZ-7nP2_63aoED1jxBbtk=.8dcfa9e0-c8a8-4922-937e-fdb22ee84c95@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
 <lE8Fzktp5eGkcXgqGo9BX2XZ-7nP2_63aoED1jxBbtk=.8dcfa9e0-c8a8-4922-937e-fdb22ee84c95@github.com>
Message-ID: <Hai1knECYXvemIZZ5utF6G7XsGtjf7VH4wySvU6WT4s=.40d63bbb-4a91-4983-9921-82d963f8ead8@github.com>

On Fri, 7 Feb 2025 19:13:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I think the intrinsic for isInterface can be removed

Good point. Moreover, it seems most of intrinsics on Class queries can be replaced with a flag bit check on the mirror. (Do we have 16 unused bits in Class::modifiers after this change?)

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2643997479

From ccheung at openjdk.org  Fri Feb  7 20:27:49 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 7 Feb 2025 20:27:49 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks
Message-ID: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>

This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.

Passed tiers 1 - 5 testing.

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

Commit messages:
 - trailing whitespace
 - cleanup and add comments
 - 8280682: Refactor AOT code source validation checks

Changes: https://git.openjdk.org/jdk/pull/23476/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8280682
  Stats: 3172 lines in 40 files changed: 1346 ins; 1647 del; 179 mod
  Patch: https://git.openjdk.org/jdk/pull/23476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23476/head:pull/23476

PR: https://git.openjdk.org/jdk/pull/23476

From coleenp at openjdk.org  Fri Feb  7 21:14:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Feb 2025 21:14:13 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <Hai1knECYXvemIZZ5utF6G7XsGtjf7VH4wySvU6WT4s=.40d63bbb-4a91-4983-9921-82d963f8ead8@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
 <lE8Fzktp5eGkcXgqGo9BX2XZ-7nP2_63aoED1jxBbtk=.8dcfa9e0-c8a8-4922-937e-fdb22ee84c95@github.com>
 <Hai1knECYXvemIZZ5utF6G7XsGtjf7VH4wySvU6WT4s=.40d63bbb-4a91-4983-9921-82d963f8ead8@github.com>
Message-ID: <RXGNb9N_QtHpY_ACo3Tqlezykzg36nHJSHO0Ep7jVEQ=.0ee2e5c1-006e-436d-815a-9086bd002dc5@github.com>

On Fri, 7 Feb 2025 19:58:12 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Good point. Moreover, it seems most of intrinsics on Class queries can be replaced with a flag bit check on the mirror. (Do we have 16 unused bits in Class::modifiers after this change?)

Yes, I think so.  isArray and isPrimitive definitely.  We could first change the modifiers field to "char" because that's its size and then have two booleans for each of these.

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2644136904

From liach at openjdk.org  Fri Feb  7 21:37:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 7 Feb 2025 21:37:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <rOsaO-sBYnrdqrPazYWGUx95QxEJ6vkbqO-C47E-P5Q=.fdda2cd0-df90-4a6a-8c2c-4fb577a72de3@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

Making `isArray` and `isPrimitive` Java-based is going to be helpful for the interpreter performance of these methods in early bootstrap. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2644171713

From cjplummer at openjdk.org  Sat Feb  8 08:12:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 8 Feb 2025 08:12:58 GMT
Subject: RFR: 8349684: Remove SA core file tests from problem list for
 macosx-x64
Message-ID: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>

Now that we have retired OSX 11 and earlier, [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) does not seem to reproduce anymore. I ran the SA core file tests about 2000 times and only saw 1 failure, and it was not related to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433). I think this is acceptable and we should make SA core file tests on macosx-x64 part of our CI testing again and see how they do.

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

Commit messages:
 - Remove SA core files tests from problem list for macosx-x64

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

PR: https://git.openjdk.org/jdk/pull/23529

From alanb at openjdk.org  Sat Feb  8 19:44:12 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 8 Feb 2025 19:44:12 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <YJ99YDxAF7V-8aQ9vkVzWyGuNciUbP6D0yTaPs7jqgY=.edf8667d-605e-4ae9-87c0-bd6376daf30f@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

No more comments from me.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2604014387

From jwaters at openjdk.org  Sun Feb  9 13:10:19 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 9 Feb 2025 13:10:19 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <Qq762lW7bsLbDvZ0w_V6aUDBiDtSeffMRngVGsw4teY=.900b8f62-c67c-4d62-8814-3a4ab24042c2@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Don't close it

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2646295839

From kvn at openjdk.org  Sun Feb  9 17:49:40 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 9 Feb 2025 17:49:40 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod
Message-ID: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>

Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.

Added C++ static asserts to make sure no virtual methods are added in a future.

Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.

Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

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

Commit messages:
 - 8349088: De-virtualize Codeblob and nmethod

Changes: https://git.openjdk.org/jdk/pull/23533/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349088
  Stats: 518 lines in 23 files changed: 235 ins; 215 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/23533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533

PR: https://git.openjdk.org/jdk/pull/23533

From kvn at openjdk.org  Sun Feb  9 19:43:29 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 9 Feb 2025 19:43:29 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <bRugayK5HkT9rbk9LPYZ8SdsqyySDVVJbJIfhGuezGA=.2422266a-e58c-4038-a726-db3e54cf3588@github.com>

On Sun, 9 Feb 2025 17:45:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

@dougxc and @tkrodriguez,  please look if it affects Graal.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2646553512

From kvn at openjdk.org  Sun Feb  9 19:43:29 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 9 Feb 2025 19:43:29 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Fix Zero and Minimal VM builds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/11abd5e7..dda20f0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/23533

From cjplummer at openjdk.org  Mon Feb 10 03:14:22 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 10 Feb 2025 03:14:22 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
Message-ID: <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>

On Sun, 9 Feb 2025 19:43:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero and Minimal VM builds

I almost wished I hadn't looked because there is a lot of SA CodeBlob support that could use some cleanup. Most notably I think most of the wrapper subclasses are not needed by SA, and could be served by one common class. See what I'm doing in #23456 for JavaThread subclasses. Wrapper classes don't need to be 1-to-1 with the class type they are wrapping. A single wrapper class type can handle any number of hotspot types. It usually just make more sense for them to be 1-to-1, but when they are trivial and the implementation is replicated across subtypes, just having one wrapper class implement them all can simplify things.

The other thing I noticed is a lot of the subtypes seem to be doing some unnecessary things like registering Observers, and they all do something like the following:

44     Type type = db.lookupType("BufferBlob");

Even when it never references "type".

I'm not suggesting you clean up any of this now, but just pointed it out. I might file an issue and try to clean it up myself at some point.

I still need to take a closer look at the SA changes.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 38:

> 36: public class CodeCache {
> 37:   private static GrowableArray<CodeHeap> heapArray;
> 38:   private static VirtualConstructor virtualConstructor;

What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes.

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

PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2604594200
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1948335278

From cjplummer at openjdk.org  Mon Feb 10 03:29:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 10 Feb 2025 03:29:13 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
 <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>
Message-ID: <MuWo0UbHjeatHRYvdW2o5IuYS99xCt9Cx4tcuyd7YLI=.347b62cf-16ad-4f24-aaa0-db044acca1f8@github.com>

On Mon, 10 Feb 2025 02:47:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Zero and Minimal VM builds
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 38:
> 
>> 36: public class CodeCache {
>> 37:   private static GrowableArray<CodeHeap> heapArray;
>> 38:   private static VirtualConstructor virtualConstructor;
> 
> What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes.

I think I found the answer. Since there is no longer a vtable, TypeDataBase.addressTypeIsEqualToType() will no longer work for Codeblobs. I was wondering if the lack of a vtable might have some negative impact. Glad to see you found a solution. I hope the lack of a vtable does not creep in elsewhere. I know it will have some negative impact on things like the "findpc" functionality, which will no longer be able to tell the user that an address points to a Codeblob instance. There's no test for this, but users might run across it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1948352958

From yzheng at openjdk.org  Mon Feb 10 10:17:15 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 10 Feb 2025 10:17:15 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <s10zFU38xW679o1IZQLM-ABYTxKHhGnVzX1sg0rVoiY=.7fe943fc-f4c0-4cd5-ab69-fb6dbfa6fde6@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

JVMCI change looks good to me

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22652#pullrequestreview-2605295926

From dnsimon at openjdk.org  Mon Feb 10 11:03:13 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 10 Feb 2025 11:03:13 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod
In-Reply-To: <bRugayK5HkT9rbk9LPYZ8SdsqyySDVVJbJIfhGuezGA=.2422266a-e58c-4038-a726-db3e54cf3588@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <bRugayK5HkT9rbk9LPYZ8SdsqyySDVVJbJIfhGuezGA=.2422266a-e58c-4038-a726-db3e54cf3588@github.com>
Message-ID: <PqwHiIGu284wCbjgvDkhnG1pNNDZNOs0vn4cQV-cVoE=.398c16a5-79ec-4c12-a3ed-1cabc1fed6cd@github.com>

On Sun, 9 Feb 2025 19:36:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> @dougxc and @tkrodriguez, please look if it affects Graal.

I'm pretty sure JVMCI does not care about the virtual-ness of these C++ classes. Running tier9 in mach5 is a good way to be sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2647642674

From adinn at openjdk.org  Mon Feb 10 11:07:14 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 10 Feb 2025 11:07:14 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
Message-ID: <0LQ3b0zaCg8HEDx4C5xM8W4-qmQ9PkoAClhyVxKxxtE=.8cd94c7a-8496-436c-8387-6aa443942bb6@github.com>

On Sun, 9 Feb 2025 19:43:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero and Minimal VM builds

src/hotspot/share/code/codeBlob.cpp line 58:

> 56: #include <type_traits>
> 57: 
> 58: // Virtual methods are not allowed in code blobs to simplify caching compiled code.

Is it worth considering generating this code plus also some of the existing code in the header using an iterator template macro? e.g.

    #define CODEBLOBS_DO(do_codeblob_abstract, do_codeblob_nonleaf, \
                         do_codeblob_leaf)                          \
      do_codeblob_abstract(CodeBlob)                                \
      do_codeblob_leaf(nmethod, Nmethod, nmethod)                   \
      do_codeblob_abstract(RuntimeBlob)                             \
      do_codeblob_nonleaf(BufferBlob, Buffer, buffer)               \
      do_codeblob_leaf(AdapterBlob, Adapter, adapter)               \
      . . .                                                         \
      do_codeblob_leaf(RuntimeStub, Runtime_Stub, runtime_stub)     \
      . . .

The macro arguments to the templates would themselves be macros:

    do_codeblob_abstract(classname) // abstract, non-instantiable class
    do_codeblob_nonleaf(classname, kindname, accessorname) // instantiable, subclassable
    do_codeblob_leaf(classname, kindname, accessorname) // instantiable, non-subclassable

Using a template macro like this to generate the code below -- *plus also* some of the code currently declared piecemeal in the header -- would guarantee all cases are covered now and will remain so later so when the macro is updated. I think it would probably also allow case handling code in AOT cache code to be generated.

So, we would generate the code here as follows

    #define EMPTY1(classname) 
    #define EMPTY3(classname, kindname, accessorname)

    #define assert_nonvirtual_leaf(classname, kindname, accessorname) \
      static_assert(!std::is_polymorphic<classname>::value,            \
                    "no virtual methods are allowed in " # classname );

    CODEBLOBS_DO(empty1, empty3, assert_nonvirtual_leaf)

    #undef assert_nonvirtual_leaf

Likewise in codeBlob.hpp we could generate `enum CodeBlobKind` to cover all the non-abstract classes and likewise generate the accessor methods `is_nmethod()`, `is_buffer_blob()` in class `CodeBlob` which allow the kind to be tested.

    #define codekind_enum_tag(classname, kindname, accessorname) \
      kindname,

    enum CodeBlobKind : u1 {
      None,
      CODEBLOBS_DO(empty1, codekind_enum_tag, codekind_enum_tag)
      Number_Of_Kinds
    };

    #define is_codeblob_define(classname, kindname, accessorname) \
        void is_ # accessor_name () { return _kind == kindname; }

    class CodeBlob {
      . . .
      CODEBLOBS_DO(empty1, is_codeblob_define, is_codeblob_define);
      . . .
There may be other opportunities to use the iterator (e.g. in vmStructs.cpp?) but this looks like a good start.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1948849392

From coleenp at openjdk.org  Mon Feb 10 12:47:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Feb 2025 12:47:31 GMT
Subject: RFR: 8346567: Make Class.getModifiers() non-native [v7]
In-Reply-To: <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
 <tKFgUu23VemLpYbPlEKP78xbcZN3ltxni_Wr4lj2i-E=.581d6ed2-c421-427e-9eb2-ad0764c787ba@github.com>
Message-ID: <DmXMLnORTe6gOVepuVwqdgQDFU-2XSaO70XqWd1mhfU=.3cb505ca-fe8f-4e4b-940a-93713cb3f637@github.com>

On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
>> 
>> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jvmci test.

Thank you for the reviews Yudi, Alan, Chen, Vladimir and Dean, and the help and comments with the various pieces of this.

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

PR Comment: https://git.openjdk.org/jdk/pull/22652#issuecomment-2647880184

From coleenp at openjdk.org  Mon Feb 10 12:47:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Feb 2025 12:47:32 GMT
Subject: Integrated: 8346567: Make Class.getModifiers() non-native
In-Reply-To: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
References: <7X3DYiPMRGAIWCyCP64kbZvHuxjmmszGxfH1dfSu38k=.7fdb2512-1999-4c7e-835c-da96d57ca1be@github.com>
Message-ID: <-VYQTxGucpCCQZccdw6wMnDavFDAt75MDHY8mGxEMiw=.042099b8-41dc-4b0d-8bdd-a874f004a0f6@github.com>

On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The Class.getModifiers() method is implemented as a native method in java.lang.Class to access a field that we've calculated when creating the mirror.  The field is final after that point. The VM doesn't need it anymore, so there's no real need for the jdk code to call into the VM to get it.  This moves the field to Java and removes the intrinsic code.  I promoted the compute_modifiers() functions to return int since that's how java.lang.Class uses the value.  It should really be an unsigned short though.
> 
> There's a couple of JMH benchmarks added with this change.  One does show that for array classes for non-bootstrap class loader, this results in one extra load which in a long loop of just that, is observable.  I don't think this is real life code. The other benchmarks added show no regression.
> 
> Tested with tier1-8.

This pull request has now been integrated.

Changeset: c9cadbd2
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9cadbd23fb13933b8968f283d27842cd35f8d6f
Stats:     217 lines in 31 files changed: 71 ins; 127 del; 19 mod

8346567: Make Class.getModifiers() non-native

Reviewed-by: alanb, vlivanov, yzheng, dlong

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

PR: https://git.openjdk.org/jdk/pull/22652

From stefank at openjdk.org  Mon Feb 10 16:26:12 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 10 Feb 2025 16:26:12 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
Message-ID: <TInY73vEr-Zf1V8aJoj9Gi05j1HEVp6yERf7WyRAWTI=.68a66e73-b21f-4957-a231-49f87b592915@github.com>

On Sun, 9 Feb 2025 19:43:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero and Minimal VM builds

We have a similar situation with oopDesc that are not allowed to have a vtable. The solution there is to use the Klass as the proxy vtable and then have a bunch of Klass::oop_ functions that act like virtual dispatch functions for associated oopDesc functions.

I wonder if a similar approach can be use here? Such an approach would (to me at lest) have the benefit that we don't have to spread switch statements in various functions in the top-most class.

If you are interested in seeing a prototype of this, take a look at this branch:
https://github.com/openjdk/jdk/compare/master...stefank:jdk:code_blob_vptr

Just a suggestion if you want to consider alternatives to these switch statements.

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

PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2606457754

From kvn at openjdk.org  Mon Feb 10 16:39:19 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 10 Feb 2025 16:39:19 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <0LQ3b0zaCg8HEDx4C5xM8W4-qmQ9PkoAClhyVxKxxtE=.8cd94c7a-8496-436c-8387-6aa443942bb6@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
 <0LQ3b0zaCg8HEDx4C5xM8W4-qmQ9PkoAClhyVxKxxtE=.8cd94c7a-8496-436c-8387-6aa443942bb6@github.com>
Message-ID: <1P7Q-yHC0Ho8DPfgzZfxR27NmNQPJ4LcgEbilqdaVNw=.0c023c74-b3d9-4139-8363-5ebdf1a1805d@github.com>

On Mon, 10 Feb 2025 11:04:38 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Zero and Minimal VM builds
>
> src/hotspot/share/code/codeBlob.cpp line 58:
> 
>> 56: #include <type_traits>
>> 57: 
>> 58: // Virtual methods are not allowed in code blobs to simplify caching compiled code.
> 
> Is it worth considering generating this code plus also some of the existing code in the header using an iterator template macro? e.g.
> 
>     #define CODEBLOBS_DO(do_codeblob_abstract, do_codeblob_nonleaf, \
>                          do_codeblob_leaf)                          \
>       do_codeblob_abstract(CodeBlob)                                \
>       do_codeblob_leaf(nmethod, Nmethod, nmethod)                   \
>       do_codeblob_abstract(RuntimeBlob)                             \
>       do_codeblob_nonleaf(BufferBlob, Buffer, buffer)               \
>       do_codeblob_leaf(AdapterBlob, Adapter, adapter)               \
>       . . .                                                         \
>       do_codeblob_leaf(RuntimeStub, Runtime_Stub, runtime_stub)     \
>       . . .
> 
> The macro arguments to the templates would themselves be macros:
> 
>     do_codeblob_abstract(classname) // abstract, non-instantiable class
>     do_codeblob_nonleaf(classname, kindname, accessorname) // instantiable, subclassable
>     do_codeblob_leaf(classname, kindname, accessorname) // instantiable, non-subclassable
> 
> Using a template macro like this to generate the code below -- *plus also* some of the code currently declared piecemeal in the header -- would guarantee all cases are covered now and will remain so later so when the macro is updated. I think it would probably also allow case handling code in AOT cache code to be generated.
> 
> So, we would generate the code here as follows
> 
>     #define EMPTY1(classname) 
>     #define EMPTY3(classname, kindname, accessorname)
> 
>     #define assert_nonvirtual_leaf(classname, kindname, accessorname) \
>       static_assert(!std::is_polymorphic<classname>::value,            \
>                     "no virtual methods are allowed in " # classname );
> 
>     CODEBLOBS_DO(empty1, empty3, assert_nonvirtual_leaf)
> 
>     #undef assert_nonvirtual_leaf
> 
> Likewise in codeBlob.hpp we could generate `enum CodeBlobKind` to cover all the non-abstract classes and likewise generate the accessor methods `is_nmethod()`, `is_buffer_blob()` in class `CodeBlob` which allow the kind to be tested.
> 
>     #define codekind_enum_tag(classname, kindname, accessorname) \
>       kindname,
> 
>     enum CodeBlobKind : u1 {
>       None,
>       CODEBLOBS_DO(empty1, codekind_enum_tag, codekind_enum_tag)
>       Number_Of_Kinds
>     };
> 
>     ...

Thank you @adinn for suggestion but no, I don't like macros - hard to debug and they add more complexity in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1949483501

From kvn at openjdk.org  Mon Feb 10 16:50:12 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 10 Feb 2025 16:50:12 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <MuWo0UbHjeatHRYvdW2o5IuYS99xCt9Cx4tcuyd7YLI=.347b62cf-16ad-4f24-aaa0-db044acca1f8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
 <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>
 <MuWo0UbHjeatHRYvdW2o5IuYS99xCt9Cx4tcuyd7YLI=.347b62cf-16ad-4f24-aaa0-db044acca1f8@github.com>
Message-ID: <ikNjrWuT83NiylLufeiZausKN4JHJaGXowZ5CMOhMTg=.ca4265f3-3608-40ee-8596-f12148a03ecd@github.com>

On Mon, 10 Feb 2025 03:25:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 38:
>> 
>>> 36: public class CodeCache {
>>> 37:   private static GrowableArray<CodeHeap> heapArray;
>>> 38:   private static VirtualConstructor virtualConstructor;
>> 
>> What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes.
>
> I think I found the answer. Since there is no longer a vtable, TypeDataBase.addressTypeIsEqualToType() will no longer work for Codeblobs. I was wondering if the lack of a vtable might have some negative impact. Glad to see you found a solution. I hope the lack of a vtable does not creep in elsewhere. I know it will have some negative impact on things like the "findpc" functionality, which will no longer be able to tell the user that an address points to a Codeblob instance. There's no test for this, but users might run across it.

> What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes.

I don't need any more mapping from CodeBlob class to corresponding virtual table name which does not exist anymore. `CodeBlob::_kind` field's value is used to determine which class should be used.

I think `hashMap` is overkill here. I can construct array `Class<?> cbClasses[]` and use `cbClasses[CodeBlob::_kind]` instead of `if/else` in `getClassFor`. But I would still need to check for unknown value of `CodeBlob::_kind` somehow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1949505126

From kvn at openjdk.org  Mon Feb 10 17:06:13 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 10 Feb 2025 17:06:13 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <TInY73vEr-Zf1V8aJoj9Gi05j1HEVp6yERf7WyRAWTI=.68a66e73-b21f-4957-a231-49f87b592915@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
 <TInY73vEr-Zf1V8aJoj9Gi05j1HEVp6yERf7WyRAWTI=.68a66e73-b21f-4957-a231-49f87b592915@github.com>
Message-ID: <iLRSrhsBjEX-53Px4rstfpVqimSrAdbUT4rEWNXwKoY=.88bd3608-3917-45b2-b9a6-fa45937efd1e@github.com>

On Mon, 10 Feb 2025 16:23:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Zero and Minimal VM builds
>
> We have a similar situation with oopDesc that are not allowed to have a vtable. The solution there is to use the Klass as the proxy vtable and then have a bunch of Klass::oop_ functions that act like virtual dispatch functions for associated oopDesc functions.
> 
> I wonder if a similar approach can be use here? Such an approach would (to me at lest) have the benefit that we don't have to spread switch statements in various functions in the top-most class.
> 
> If you are interested in seeing a prototype of this, take a look at this branch:
> https://github.com/openjdk/jdk/compare/master...stefank:jdk:code_blob_vptr
> 
> Just a suggestion if you want to consider alternatives to these switch statements.

Thank you, @stefank. This is very interesting suggestion which I may take. I will check it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2648688942

From kevinw at openjdk.org  Mon Feb 10 17:52:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Feb 2025 17:52:11 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
Message-ID: <c0bI4zMDWutqS_swZqXlxc1u0uEmK_oCaMIAv3TI4T0=.85a0baa8-5760-4243-98d2-aa446c20185f@github.com>

On Thu, 6 Feb 2025 22:44:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Cleanup SA JavaThread support. Details in first comment:
>> 
>> Testing:
>> - Tier1
>> - Tier2 svc
>> - Tier3
>> - Tier5 svc
>> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comments

Looks good.

I think we need a HiddenJavaThread class,  and "visibility" cannot just be a boolean field in JavaThread, because virtualConstructor.addMapping wants a mapping to a class that will already know whether it's hidden.

In calling it HiddenJavaThread we might be labelling threads "JavaThread" when they don't run Java, but those I looked at are derived from JavaThread in native hotspot so it must be the right name.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23456#pullrequestreview-2606714536

From cjplummer at openjdk.org  Mon Feb 10 18:18:10 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 10 Feb 2025 18:18:10 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <c0bI4zMDWutqS_swZqXlxc1u0uEmK_oCaMIAv3TI4T0=.85a0baa8-5760-4243-98d2-aa446c20185f@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
 <c0bI4zMDWutqS_swZqXlxc1u0uEmK_oCaMIAv3TI4T0=.85a0baa8-5760-4243-98d2-aa446c20185f@github.com>
Message-ID: <9dR-LTG_tbcduhr1TuPFOIfArzrNtvAWbPlIi_Nw0Jo=.d9ce028d-da4d-45c5-944e-f9b2a1fa6cb6@github.com>

On Mon, 10 Feb 2025 17:49:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I think we need a HiddenJavaThread class, and "visibility" cannot just be a boolean field in JavaThread, because virtualConstructor.addMapping wants a mapping to a class that will already know whether it's hidden.
> 
As I just learned from Vladimir's CodeBlob work in #23533, we could actually do without the mapping and instead query a field in the instance to determine which wrapper class to use for it. The problem is that "hidden" is not a field, it is a method, although probably could be changed to a field, which might also help to implement [JDK-8348317](https://bugs.openjdk.org/browse/JDK-8348317). However, implementing that approach still basically requires all the changes in this PR, so I think it is still best to get this one in place and maybe file a followup CR for further improvement (although honestly I don't see myself working on it right away).

> In calling it HiddenJavaThread we might be labelling threads "JavaThread" when they don't run Java, but those I looked at are derived from JavaThread in native hotspot so it must be the right name.

Yeah, all these threads are hospot JavaThread instances. The naming inconsistency really begins there. This PR actually cleans it up by getting rid of the SA isJavaThread(), which was different then the hotspot isJavaThread().

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

PR Comment: https://git.openjdk.org/jdk/pull/23456#issuecomment-2648867520

From jsjolen at openjdk.org  Mon Feb 10 18:28:11 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Feb 2025 18:28:11 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v3]
In-Reply-To: <IEjlHXE81cJ1pFA2Js5uNs-Jis834z1Ve-9m_NPKzF8=.77d96896-4951-452e-9965-9699ad8297b4@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
 <IEjlHXE81cJ1pFA2Js5uNs-Jis834z1Ve-9m_NPKzF8=.77d96896-4951-452e-9965-9699ad8297b4@github.com>
Message-ID: <GJxbuwM9chjQeU-fbaVvx8iZMRzjm7mu1u9DzbL85-M=.d920d94b-c24d-4561-b758-b8c2bf37ee56@github.com>

On Tue, 4 Feb 2025 20:12:44 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> > I didn't really understand what makes this streaming. The old protocol first sent out the result, and then the data, has this changed?
> 
> The protocol works as before. All command handlers are updated to set the result code earlier (after argument parsing, but before command execution). After the result code is set, it's sent to the tool and the rest of output (data) are send directly to the tool without buffering.

Aha, I understand. Before, result code meant "Parsing OK, Command Execution OK", now it means "Parsing OK, starting Command Execution". That's fine by me.

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2648889826

From kevinw at openjdk.org  Mon Feb 10 19:25:43 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 10 Feb 2025 19:25:43 GMT
Subject: RFR: 8349723: Problemlist jdp tests for macosx-x64
Message-ID: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>

Trivial problemlist update.
Problemlist should be expanded for macosx, from just aarch64 to all, for these JDP tests, as x64 has occasional failures. 


---------
### Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue



### Reviewing
<details><summary>Using <code>git</code></summary>

Checkout this PR locally: \
`$ git fetch https://git.openjdk.org/jdk.git pull/23541/head:pull/23541` \
`$ git checkout pull/23541`

Update a local copy of the PR: \
`$ git checkout pull/23541` \
`$ git pull https://git.openjdk.org/jdk.git pull/23541/head`

</details>
<details><summary>Using Skara CLI tools</summary>

Checkout this PR locally: \
`$ git pr checkout 23541`

View PR using the GUI difftool: \
`$ git pr show -t 23541`

</details>
<details><summary>Using diff file</summary>

Download this PR as a diff file: \
<a href="https://git.openjdk.org/jdk/pull/23541.diff">https://git.openjdk.org/jdk/pull/23541.diff</a>

</details>

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

Commit messages:
 - 8349723: Problemlist jdp tests for macosx-x64

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

PR: https://git.openjdk.org/jdk/pull/23541

From syan at openjdk.org  Tue Feb 11 02:49:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 02:49:49 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
Message-ID: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>

H all,

This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.

I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.

1. java/lang/management/ThreadMXBean/VirtualThreads.java#default

VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.

2. java/lang/Thread/virtual/stress/PinALot.java

PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".

3. java/lang/Thread/virtual/SynchronizedNative.java

Call System.loadLibrary("SynchronizedNative") at line 85.

4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java


- Why we need the '/native' keywork?

I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.

Change has been verified locally, test-fix, no risk.

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

Commit messages:
 - 8349689: Several virtual thread tests missing /native keyword

Changes: https://git.openjdk.org/jdk/pull/23550/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349689
  Stats: 48 lines in 10 files changed: 0 ins; 0 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/23550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23550/head:pull/23550

PR: https://git.openjdk.org/jdk/pull/23550

From iklam at openjdk.org  Tue Feb 11 05:29:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Feb 2025 05:29:10 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks
In-Reply-To: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
Message-ID: <Ee1Jz1yzCyZLga2lB1yhfGzcyn_JkOHiLI8Q5nJLruA=.b2f03607-1811-4548-bef6-9abfb0fdb44b@github.com>

On Wed, 5 Feb 2025 22:32:58 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
> 
> Passed tiers 1 - 5 testing.

Looks good. A few suggestions for the in-line comments.

src/hotspot/share/cds/aotCodeSource.cpp line 133:

> 131: 
> 132: // AllCodeSourceStreams is used to iterate over all the code sources that
> 133: // are available to the application from -Xbootclasspath, -classpath and --module-path

Consider adding this comment:

// When creating an AOT cache, we store the contents from AllCodeSourceStreams
// into an array of AOTCodeSources. See AOTCodeSourceConfig::dumptime_init_helper().
// When loading the AOT cache in a production run, we compare the contents of the
// stored AOTCodeSources against the current AllCodeSourceStreams to determine whether
// the AOT cache is compatible with the current JVM. See AOTCodeSourceConfig::validate().

src/hotspot/share/cds/aotCodeSource.hpp line 126:

> 124: // Non-existent entries are recored during AOTCache creation. Those non-existent entries
> 125: // must not exist during runtime.
> 126: //

Typos:
- "subjected to AOTCodeSourceConfig::validate()" -- the function has two parameters, but we can omit them in this comment
- "validation is performed on *the* AOTCodeSources"
- "during AOTCache creation *are* the same"
- "on-existent entries are *recorded*"

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

PR Review: https://git.openjdk.org/jdk/pull/23476#pullrequestreview-2607702313
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1950250159
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1950244507

From alanb at openjdk.org  Tue Feb 11 07:29:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 07:29:09 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:

> 28:  * @modules java.base/java.lang:+open java.management
> 29:  * @library /test/lib
> 30:  * @run junit/othervm/native VirtualThreads

Can you add `--enable-native-access=ALL-UNNAMED` to this test while you are editing this line? It makes it more obvious that it invokes native code and also removes the warning at runtime.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950353219

From alanb at openjdk.org  Tue Feb 11 07:33:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 07:33:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

Can you check if these two needs to be updated too?

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
test/jdk/java/lang/Thread/virtual/Starvation.java

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650016781

From syan at openjdk.org  Tue Feb 11 07:43:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 07:43:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v2]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <0bp5M6-iiZxngQJk5uRVX6h_-uMXYYG2zBOtqgQEQDo=.96dc6c54-59ae-42d3-8f8e-ed531e15c0a9@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  add --enable-native-access=ALL-UNNAMED for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java#default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/03e76ed3..7c030997

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Tue Feb 11 07:43:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 07:43:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v2]
In-Reply-To: <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>
Message-ID: <mkh92dxM39AIrZDtRErygNzyJhmTC9kpS_zV0kJW954=.269d6d2d-fcbd-400e-b2e2-7adadf66dd14@github.com>

On Tue, 11 Feb 2025 07:26:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add --enable-native-access=ALL-UNNAMED for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java#default
>
> test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:
> 
>> 28:  * @modules java.base/java.lang:+open java.management
>> 29:  * @library /test/lib
>> 30:  * @run junit/othervm/native VirtualThreads
> 
> Can you add `--enable-native-access=ALL-UNNAMED` to this test while you are editing this line? It makes it more obvious that it invokes native code and also removes the warning at runtime.

Thanks. Argument `--enable-native-access=ALL-UNNAMED` has been added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950365978

From kevinw at openjdk.org  Tue Feb 11 08:03:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Feb 2025 08:03:11 GMT
Subject: RFR: 8349684: Remove SA core file tests from problem list for
 macosx-x64
In-Reply-To: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>
References: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>
Message-ID: <IXsAunesPd3aHeKCossujRWY7gcYUrr8sRPVMOlUkus=.882c7fed-90b9-4e54-864c-78250ccf4956@github.com>

On Sat, 8 Feb 2025 03:45:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Now that we have retired OSX 11 and earlier, [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) does not seem to reproduce anymore. I ran the SA core file tests about 2000 times and only saw 1 failure, and it was not related to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433). I think this is acceptable and we should make SA core file tests on macosx-x64 part of our CI testing again and see how they do.

Yes looks good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23529#pullrequestreview-2607947485

From syan at openjdk.org  Tue Feb 11 08:38:48 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:38:48 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/7c030997..413ee6b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=01-02

  Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23550/head:pull/23550

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Tue Feb 11 08:47:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:47:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>
Message-ID: <W3DxZL_gHfiu5vtMqDWnFGgWEU5LPV1odLtVXijdkJY=.d4252543-9bda-4e96-ab6b-2105c6547c03@github.com>

On Tue, 11 Feb 2025 07:30:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you check if these two needs to be updated too?
> 
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

These two tests also need `/native` keyword.

- Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java do not report test failed or error when missing load the native shared libary. So I add a check to make sure that the first virtual of this test run normally.

The original test output from jfr file shows below:


STARTED    ThreadPollOnYield::testThreadYieldPolls 'testThreadYieldPolls()'
Exception in thread "" java.lang.ExceptionInInitializerError
    at ThreadPollOnYield.lambda$testThreadYieldPolls$0(ThreadPollOnYield.java:59)
    at java.base/java.lang.VirtualThread.run(VirtualThread.java:466)
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:135)
    at jdk.test.lib.thread.VThreadPinner.<clinit>(VThreadPinner.java:50)
    ... 2 more
Caused by: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so
    at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:350)
    at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:335)
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:130)
    ... 3 more
Exception in thread "" java.lang.NoClassDefFoundError: Could not initialize class jdk.test.lib.thread.VThreadPinner
    at ThreadPollOnYield.lambda$testThreadYieldPolls$2(ThreadPollOnYield.java:69)
    at java.base/java.lang.VirtualThread.run(VirtualThread.java:466)
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.RuntimeException: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so [in thread "ForkJoinPool-1-worker-1"]
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:135)
    at jdk.test.lib.thread.VThreadPinner.<clinit>(VThreadPinner.java:50)
    at ThreadPollOnYield.lambda$testThreadYieldPolls$0(ThreadPollOnYield.java:59)
    ... 1 more
SUCCESSFUL ThreadPollOnYield::testThreadYieldPolls 'testThreadYieldPolls()'



- Test test/jdk/java/lang/Thread/virtual/Starvation.java execute over 120 seconds on my local environment. So I add `timeout=200` also.


elapsed time (seconds): 121.41

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650141187

From alanb at openjdk.org  Tue Feb 11 08:47:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 08:47:13 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
Message-ID: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>

On Tue, 11 Feb 2025 08:38:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

test/jdk/java/lang/Thread/virtual/Starvation.java line 28:

> 26:  * @library /test/lib
> 27:  * @bug 8345294
> 28:  * @run main/othervm/timeout=200/native --enable-native-access=ALL-UNNAMED Starvation 100000

Did you mean to add /timeout=200 to this test?

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 39:

> 37:  * @requires vm.continuations & vm.compMode != "Xcomp"
> 38:  * @library /test/lib
> 39:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED -Xcomp -XX:-TieredCompilation -XX:CompileCommand=inline,*::yield* -XX:CompileCommand=inline,*::*Yield ThreadPollOnYield

Would you mind splitting this line (jtreg is okay with that) as it's nearly 190 chars now so getting too long.

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:

> 67:         if (flag != true) {
> 68:             throw new RuntimeException("flag = " + flag);
> 69:         }

What are these other changes about?

test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:

> 28:  * @modules java.base/java.lang:+open java.management
> 29:  * @library /test/lib
> 30:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED VirtualThreads

Can you check if the end copyright date needs to be updated on this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950436579
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950439893
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950438562
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950440627

From syan at openjdk.org  Tue Feb 11 08:47:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:47:14 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
Message-ID: <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>

On Tue, 11 Feb 2025 08:41:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java
>
> test/jdk/java/lang/Thread/virtual/Starvation.java line 28:
> 
>> 26:  * @library /test/lib
>> 27:  * @bug 8345294
>> 28:  * @run main/othervm/timeout=200/native --enable-native-access=ALL-UNNAMED Starvation 100000
> 
> Did you mean to add /timeout=200 to this test?

Test test/jdk/java/lang/Thread/virtual/Starvation.java execute over 120 seconds on my local environment. So I add timeout=200 also.

> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:
> 
>> 67:         if (flag != true) {
>> 68:             throw new RuntimeException("flag = " + flag);
>> 69:         }
> 
> What are these other changes about?

Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950440123
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950439898

From syan at openjdk.org  Tue Feb 11 08:53:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:53:46 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v4]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <XL5_3IfJOXgAxPLi6mkQbGahdqhlwyh99KdOUZVjyP0=.aefddd7b-fbd1-477a-ab42-f0280d42b745@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  update copyright year for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java; Split @run line for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/413ee6b1..07f34357

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=02-03

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23550/head:pull/23550

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Tue Feb 11 08:53:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:53:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
Message-ID: <PVDVRTf-xeGDKnWVzkghJizkZRxWPIIagWHXvnsUc3c=.fdac3bf4-436c-4f80-ba14-2fc27f38d8c2@github.com>

On Tue, 11 Feb 2025 08:44:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java
>
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 39:
> 
>> 37:  * @requires vm.continuations & vm.compMode != "Xcomp"
>> 38:  * @library /test/lib
>> 39:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED -Xcomp -XX:-TieredCompilation -XX:CompileCommand=inline,*::yield* -XX:CompileCommand=inline,*::*Yield ThreadPollOnYield
> 
> Would you mind splitting this line (jtreg is okay with that) as it's nearly 190 chars now so getting too long.

Okey, this line has been split two lines.

> test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:
> 
>> 28:  * @modules java.base/java.lang:+open java.management
>> 29:  * @library /test/lib
>> 30:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED VirtualThreads
> 
> Can you check if the end copyright date needs to be updated on this one.

Sorry, the copyright date has been updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950447560
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950448055

From alanb at openjdk.org  Tue Feb 11 08:56:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 08:56:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
Message-ID: <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>

On Tue, 11 Feb 2025 08:44:15 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:
>> 
>>> 67:         if (flag != true) {
>>> 68:             throw new RuntimeException("flag = " + flag);
>>> 69:         }
>> 
>> What are these other changes about?
>
> Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.

Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950452441

From syan at openjdk.org  Tue Feb 11 09:03:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:03:24 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/07f34357..912c1ab3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23550&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23550/head:pull/23550

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Tue Feb 11 09:03:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:03:25 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
 <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
Message-ID: <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>

On Tue, 11 Feb 2025 08:53:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.
>
> Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.

Okey, the additional check has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950462081

From syan at openjdk.org  Tue Feb 11 09:10:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:10:12 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
 <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
 <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>
Message-ID: <jUNt_xes1UYoItHwJqUDnLoe_8ni56CMXGxvKmtRgcM=.432e03ea-b648-4647-9dfe-918a44c18ef9@github.com>

On Tue, 11 Feb 2025 09:00:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.
>
> Okey, the additional check has been removed.

I have created a separate [issue](https://bugs.openjdk.org/browse/JDK-8349787) to record that. I will investigate later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950471694

From alanb at openjdk.org  Tue Feb 11 09:24:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 09:24:10 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <-WVSOZWZXjlAhICbHjfuu-QEAlpqx_Pmyy4EIvfdwQk=.dcac8e8d-5662-4dda-87de-8931e86c3960@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

912c1ab3 looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2608124096

From syan at openjdk.org  Tue Feb 11 09:30:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:30:14 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <UgO_pPmUbbGUSzuY8XmBTgScyYkptyf45DKrKgRuOcY=.4d243896-996c-481e-b9aa-6a1810c4aa11@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

> [912c1ab](https://github.com/openjdk/jdk/commit/912c1ab384ffb82e36e46cbf2236b42d4321bc27) looks okay.

@AlanBateman Thanks for the patience suggest and review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650245614

From dholmes at openjdk.org  Tue Feb 11 09:32:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Feb 2025 09:32:13 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
Message-ID: <_CnY-j8qQhI5hEydYYH1gfQQP909-QrWTboS79F6UHA=.cf2527c7-5a81-4e4d-8433-ce18f9d63982@github.com>

On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

Sorry still on my to-do list.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2650249785

From mbaesken at openjdk.org  Tue Feb 11 16:01:45 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Feb 2025 16:01:45 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
Message-ID: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>

The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.

On Linux x86_64 for example the lib shrinks from
300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .

On Linux ppc64le for example the lib shrinks from
428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

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

Commit messages:
 - JDK-8349638

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

PR: https://git.openjdk.org/jdk/pull/23563

From mbaesken at openjdk.org  Tue Feb 11 16:16:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Feb 2025 16:16:10 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <OXCRbpvs0LRb0-1nM3XPf9aIN6InJ1MxebrYdD53Ivg=.9e67bcae-6720-43e6-8bf6-6dfe8a50da9d@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

Build time  (JOBS=1,  on Linux x86_64) of the project is pretty similar with LOW and SIZE.

      SIZE      LOW
real  14,7     15,4
usr   8.0       8,4
sys   1.9       2,0

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2651296271

From dfuchs at openjdk.org  Tue Feb 11 16:47:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Feb 2025 16:47:14 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal
In-Reply-To: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
Message-ID: <r7rvgk9hSCG2aiYuWfVMj0fI7rzgMf8nN_G1P-9ZUWI=.9268f0eb-aa49-419d-8541-4944ecfb6d4b@github.com>

On Fri, 10 Jan 2025 14:43:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
> 
> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.

src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 205:

> 203:      * @exception MBeanException Wraps a distributed communication Exception.
> 204:      * @deprecated This constructor exists for historical reasons.  It enables
> 205:      * reading from XML, which is unnecessary.

I wonder if we should say instead "Reading from XML if required should be implemented externally".

src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 975:

> 973:      * thrown.
> 974:      * @deprecated This method exists for historical reaons. It
> 975:      * enables writing as XML, which is unnecessary.

Same here: "Writing to XML, if required, should be implemented externally."

src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 1067:

> 1065:     }
> 1066: 
> 1067:     @SuppressWarnings("removal")

Can we add a comment to indicate that XMLParseException is deprecated for removal?

src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 1131:

> 1129:      * without the parentheses.
> 1130:      */
> 1131:     @SuppressWarnings("removal")

Can we add a comment to indicate that XMLParseException is deprecated for removal?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1951205306
PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1951207163
PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1951195117
PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1951200677

From jwaters at openjdk.org  Tue Feb 11 17:33:16 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Feb 2025 17:33:16 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

Just a heads up, there is a known issue with -Os and gcc (-Os turns on -fdeclone-ctor-dtor which causes the problem), especially if LTO is active. Turning more optimization levels to -Os could present a problem if you want to have LTO support for the JDK's native code outside of HotSpot as was discussed elsewhere

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2651543730

From cjplummer at openjdk.org  Tue Feb 11 19:04:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Feb 2025 19:04:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
Message-ID: <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>

On Tue, 11 Feb 2025 17:30:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Just a heads up, there is a known issue with -Os and gcc (-Os turns on -fdeclone-ctor-dtor which causes the problem), especially if LTO is active. Turning more optimization levels to -Os could present a problem if you want to have LTO support for the JDK's native code outside of HotSpot as was discussed elsewhere

There's no C++ code in libjdwp

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2651797405

From cjplummer at openjdk.org  Tue Feb 11 19:04:10 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Feb 2025 19:04:10 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

I'm not too familiar with optimization choices in the build system, but it seems libjdwp should be built optimized in the same manner as libjvm.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2651803597

From rriggs at openjdk.org  Tue Feb 11 21:05:10 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 11 Feb 2025 21:05:10 GMT
Subject: RFR: 8349723: Problemlist jdp tests for macosx-x64
In-Reply-To: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>
References: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>
Message-ID: <dcBgRT5lFl3iS-afyHy_Hwt8Qbckcyq3cbVJ_UBW53M=.2f01cfd7-5c87-46da-bcba-09ea7dba459d@github.com>

On Mon, 10 Feb 2025 15:33:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial problemlist update.
> Problemlist should be expanded for macosx, from just aarch64 to all, for these JDP tests, as x64 has occasional failures. 
> 
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23541/head:pull/23541` \
> `$ git checkout pull/23541`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23541` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23541/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 23541`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23541`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/23541.diff">https://git.openjdk.org/jdk/pull/23541.diff</a>
> 
> </details>

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23541#pullrequestreview-2610035825

From sspitsyn at openjdk.org  Tue Feb 11 23:14:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 11 Feb 2025 23:14:18 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
Message-ID: <0C1XqCtdLdRpxNFxjiIANAttU4FP0eQIMfSIkPuPmi8=.57cb2bca-c166-42a9-b8ce-c113dadf882e@github.com>

On Thu, 6 Feb 2025 22:44:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Cleanup SA JavaThread support. Details in first comment:
>> 
>> Testing:
>> - Tier1
>> - Tier2 svc
>> - Tier3
>> - Tier5 svc
>> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comments

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 54:

> 52:   private static long oopPtrSize;
> 53: 
> 54:   // For accessing platform dependent functionality

Nit: It is better to have dot at the end of comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1951735651

From cjplummer at openjdk.org  Tue Feb 11 23:20:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Feb 2025 23:20:17 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <0C1XqCtdLdRpxNFxjiIANAttU4FP0eQIMfSIkPuPmi8=.57cb2bca-c166-42a9-b8ce-c113dadf882e@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
 <0C1XqCtdLdRpxNFxjiIANAttU4FP0eQIMfSIkPuPmi8=.57cb2bca-c166-42a9-b8ce-c113dadf882e@github.com>
Message-ID: <fv89zdADgVSJQah9c7ET2Xnb7lj45UishNrj5FYtv78=.c89b72e2-770d-4be7-88b0-116e3cbebd6a@github.com>

On Tue, 11 Feb 2025 23:11:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comments
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 54:
> 
>> 52:   private static long oopPtrSize;
>> 53: 
>> 54:   // For accessing platform dependent functionality
> 
> Nit: It is better to have dot at the end of comment.

It's consistent with other comments in the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1951739000

From sspitsyn at openjdk.org  Tue Feb 11 23:20:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 11 Feb 2025 23:20:16 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
Message-ID: <jRMzsaRe2Wvkjgp9vaxbntFFndYeQYDEtb5uBfuWqb0=.01bb4dde-c808-41c0-ae88-58ddc6581f5b@github.com>

On Thu, 6 Feb 2025 22:44:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Cleanup SA JavaThread support. Details in first comment:
>> 
>> Testing:
>> - Tier1
>> - Tier2 svc
>> - Tier3
>> - Tier5 svc
>> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comments

This looks pretty good. Nice cleanup and simplification.
I've posted some nit and one question.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadStackTrace.java line 51:

> 49:         if (!thread.isJavaThread()) {
> 50:             return;
> 51:         }

Q: I wonder why does `!thread.isHiddenFromExternalView()` not used here. Have we always dumped the hidden from external view threads?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23456#pullrequestreview-2610327458
PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1951738696

From sspitsyn at openjdk.org  Tue Feb 11 23:23:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 11 Feb 2025 23:23:10 GMT
Subject: RFR: 8349571: Remove JavaThreadFactory interface from SA
In-Reply-To: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>
References: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>
Message-ID: <Kz0_bi-JGpbI4ic4Iadb9HAAkg9WDLQmJe48Yty-EiY=.e2be1668-c7fd-497e-ae36-d10fcb24190f@github.com>

On Thu, 6 Feb 2025 23:22:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The SA JavaThreadFactory interface is no longer used, so it is being removed. I stumbled on it while looking at JavaThread related code. It looks like it's original purpose is related to JavaThread subclasses at one point being platform dependent, as described in the following JavaThread.java comment:
> 
> 
> /** This is an abstract class because there are certain OS- and
>     CPU-specific operations (like the setting and getting of the last
>     Java frame pointer) which need to be factored out. These
>     operations are implemented by, for example,
>     SolarisSPARCJavaThread, and the concrete subclasses are
>     instantiated by the JavaThreadFactory in the Threads class. */
> 
> 
> However, this is no longer the case, and this comment is being removed as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347).

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23505#pullrequestreview-2610333546

From sspitsyn at openjdk.org  Tue Feb 11 23:28:14 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 11 Feb 2025 23:28:14 GMT
Subject: RFR: 8349684: Remove SA core file tests from problem list for
 macosx-x64
In-Reply-To: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>
References: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>
Message-ID: <Xl0uAT1LlE9t4BgaGSEsa-77j6ZmDuhgphZISTgw9GM=.17f1325d-6530-4323-99dc-fc4f3cc12c68@github.com>

On Sat, 8 Feb 2025 03:45:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Now that we have retired OSX 11 and earlier, [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) does not seem to reproduce anymore. I ran the SA core file tests about 2000 times and only saw 1 failure, and it was not related to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433). I think this is acceptable and we should make SA core file tests on macosx-x64 part of our CI testing again and see how they do.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23529#pullrequestreview-2610338500

From cjplummer at openjdk.org  Tue Feb 11 23:37:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Feb 2025 23:37:12 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <jRMzsaRe2Wvkjgp9vaxbntFFndYeQYDEtb5uBfuWqb0=.01bb4dde-c808-41c0-ae88-58ddc6581f5b@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
 <jRMzsaRe2Wvkjgp9vaxbntFFndYeQYDEtb5uBfuWqb0=.01bb4dde-c808-41c0-ae88-58ddc6581f5b@github.com>
Message-ID: <NEUAL-xNqWbIzwmqBL5AiPGTQbwHksEC9XZTkHpdMuo=.5d24453b-4268-42eb-b3c2-cf968caa4c3d@github.com>

On Tue, 11 Feb 2025 23:15:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comments
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadStackTrace.java line 51:
> 
>> 49:         if (!thread.isJavaThread()) {
>> 50:             return;
>> 51:         }
> 
> Q: I wonder why is `!thread.isHiddenFromExternalView()` not used here. Have we always dumped the hidden from external view threads?

It's only used by the code below, which has already done the check:

           if (threadObj != null && !thread.isExiting() && !thread.isHiddenFromExternalView()) {

                // dump thread stack trace
                ThreadStackTrace st = new ThreadStackTrace(thread);
                st.dumpStack(-1);
                numThreads++;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1951752872

From sspitsyn at openjdk.org  Tue Feb 11 23:46:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 11 Feb 2025 23:46:08 GMT
Subject: RFR: 8349723: Problemlist jdp tests for macosx-x64
In-Reply-To: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>
References: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>
Message-ID: <4wxt5YC9GDrFUSTN2YE57p3x9ej1yque-mWysggW5Ec=.ac747773-047b-4374-ba73-0239ec98fed4@github.com>

On Mon, 10 Feb 2025 15:33:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial problemlist update.
> Problemlist should be expanded for macosx, from just aarch64 to all, for these JDP tests, as x64 has occasional failures. 
> 
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23541/head:pull/23541` \
> `$ git checkout pull/23541`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23541` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23541/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 23541`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23541`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/23541.diff">https://git.openjdk.org/jdk/pull/23541.diff</a>
> 
> </details>

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23541#pullrequestreview-2610376040

From sspitsyn at openjdk.org  Tue Feb 11 23:53:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 11 Feb 2025 23:53:12 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <fv89zdADgVSJQah9c7ET2Xnb7lj45UishNrj5FYtv78=.c89b72e2-770d-4be7-88b0-116e3cbebd6a@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
 <0C1XqCtdLdRpxNFxjiIANAttU4FP0eQIMfSIkPuPmi8=.57cb2bca-c166-42a9-b8ce-c113dadf882e@github.com>
 <fv89zdADgVSJQah9c7ET2Xnb7lj45UishNrj5FYtv78=.c89b72e2-770d-4be7-88b0-116e3cbebd6a@github.com>
Message-ID: <XJMDSeDSYHQhrEF6YiaCN8tABNXrSmhuHz_ZYa5pKbA=.881f6c2c-3b9b-4fb4-a6cc-37b10f5dcf08@github.com>

On Tue, 11 Feb 2025 23:16:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 54:
>> 
>>> 52:   private static long oopPtrSize;
>>> 53: 
>>> 54:   // For accessing platform dependent functionality
>> 
>> Nit: It is better to have dot at the end of comment.
>
> It's consistent with other comments in the file.

Okay.

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadStackTrace.java line 51:
>> 
>>> 49:         if (!thread.isJavaThread()) {
>>> 50:             return;
>>> 51:         }
>> 
>> Q: I wonder why is `!thread.isHiddenFromExternalView()` not used here. Have we always dumped the hidden from external view threads?
>
> It's only used by the code below, which has already done the check:
> 
>            if (threadObj != null && !thread.isExiting() && !thread.isHiddenFromExternalView()) {
> 
>                 // dump thread stack trace
>                 ThreadStackTrace st = new ThreadStackTrace(thread);
>                 st.dumpStack(-1);
>                 numThreads++;

I see it now. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1951750825
PR Review Comment: https://git.openjdk.org/jdk/pull/23456#discussion_r1951764063

From kvn at openjdk.org  Tue Feb 11 23:58:14 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 11 Feb 2025 23:58:14 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
 <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>
Message-ID: <GPZdeIQ8_nb5jtnet5PBB3IIrkqaQMS-SxtcIPhcHeY=.0c90ff82-6b91-4ed9-a400-2967c712ca1c@github.com>

On Mon, 10 Feb 2025 03:11:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Zero and Minimal VM builds
>
> I almost wished I hadn't looked because there is a lot of SA CodeBlob support that could use some cleanup. Most notably I think most of the wrapper subclasses are not needed by SA, and could be served by one common class. See what I'm doing in #23456 for JavaThread subclasses. Wrapper classes don't need to be 1-to-1 with the class type they are wrapping. A single wrapper class type can handle any number of hotspot types. It usually just make more sense for them to be 1-to-1, but when they are trivial and the implementation is replicated across subtypes, just having one wrapper class implement them all can simplify things.
> 
> The other thing I noticed is a lot of the subtypes seem to be doing some unnecessary things like registering Observers, and they all do something like the following:
> 
> 44     Type type = db.lookupType("BufferBlob");
> 
> Even when it never references "type".
> 
> I'm not suggesting you clean up any of this now, but just pointed it out. I might file an issue and try to clean it up myself at some point.
> 
> I still need to take a closer look at the SA changes.

Before I forgot to answer you, @plummercj 
I completely agree with your comment about cleaning up wrapper subclasses which do nothing.

I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there?

An other purpose could be a place holder for additional information in a future which never come.

Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of  VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM.

So yes, feel free to clean this up.  I will help with review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2652321179

From kvn at openjdk.org  Wed Feb 12 00:11:28 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 00:11:28 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v3]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <vsqt46cBx-yGUN-M9EHus0kxHmB6FJDFMXYXB-cva0A=.e219913c-a58e-4c3d-8f86-11fa10c2ed58@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Add CodeBlob proxy vtable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/dda20f0b..43ae0ed2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=01-02

  Stats: 322 lines in 13 files changed: 175 ins; 90 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/23533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533

PR: https://git.openjdk.org/jdk/pull/23533

From kvn at openjdk.org  Wed Feb 12 00:11:28 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 00:11:28 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
Message-ID: <DNzQaCv2QBEUWhr8ml1mPS2DeR_-KDTk8jmAE8e8TEA=.6af74b88-db15-44bb-a9f2-c8302e1e379d@github.com>

On Sun, 9 Feb 2025 19:43:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero and Minimal VM builds

I adopted Stefan's suggestion. I agree that it is more "future-proof".

I also remove underscore `_` from `CodeBlobKind` names.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2652333587
PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2652335723

From kvn at openjdk.org  Wed Feb 12 00:14:31 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 00:14:31 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v4]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <T3fkdMOVqn8th3Lxu8Zly72Dr7qViHLLuPxu5_VPW6w=.f92bbf2b-bbda-4c56-a345-cda5a9cf1cdb@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Fix Minimal and Zero VM builds again

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/43ae0ed2..7d3dce0e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/23533

From kvn at openjdk.org  Wed Feb 12 00:22:31 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 00:22:31 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v5]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <koutEg_KOqdmHOvwLzzgSt7BlBjXGodx6Ry7wt3NWY0=.55e70830-6468-4f13-a861-fbdf34eb02c6@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Fix Minimal and Zero VM builds once more

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/7d3dce0e..1d108349

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=03-04

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533

PR: https://git.openjdk.org/jdk/pull/23533

From lmesnik at openjdk.org  Wed Feb 12 00:30:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Feb 2025 00:30:12 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <miP5yG1cxruk-95cFJS12OB98XAg0nSm_xkci79tbQ4=.921bf560-093f-4cb8-bcfd-eb24b0ff4049@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2610467761

From dholmes at openjdk.org  Wed Feb 12 02:51:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Feb 2025 02:51:12 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
Message-ID: <Wg84goMDZGeKGs2maxsaoAh71G4-bEq77AeJsEjYSAA=.df6c3052-ca29-4586-8dd0-092fd7bd2798@github.com>

On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

@albertnetymk I think that to get the correct "dekker duality" in this code you do need to have full fences between the stores and loads, not just a `storeload` barrier.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2610698148

From syan at openjdk.org  Wed Feb 12 03:03:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 03:03:26 GMT
Subject: Integrated: 8349689: Several virtual thread tests missing /native
 keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <XGK3Deje9V8dDObSEdwBq5uveDcwruowG_lPj9U8rvY=.c361a005-650c-4bab-ad71-a1f87159d360@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

This pull request has now been integrated.

Changeset: 88b4a906
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88b4a906d2c520ce6a7b21adc5e709067e520cdd
Stats:     55 lines in 12 files changed: 1 ins; 0 del; 54 mod

8349689: Several virtual thread tests missing /native keyword

Reviewed-by: alanb, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/23550

From syan at openjdk.org  Wed Feb 12 03:03:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 03:03:26 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <db73BhWt2Xgz_zGic_5SxAW-ho2D-yaSerK-v64lfNs=.30b138e6-20c2-4d5e-a738-cdb2c8ca551b@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2652545506

From cjplummer at openjdk.org  Wed Feb 12 03:06:15 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Feb 2025 03:06:15 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <GPZdeIQ8_nb5jtnet5PBB3IIrkqaQMS-SxtcIPhcHeY=.0c90ff82-6b91-4ed9-a400-2967c712ca1c@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
 <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>
 <GPZdeIQ8_nb5jtnet5PBB3IIrkqaQMS-SxtcIPhcHeY=.0c90ff82-6b91-4ed9-a400-2967c712ca1c@github.com>
Message-ID: <g1xZtizMWGUVmJj54HU6Xto4EFize_eVZy7gWRNrRus=.835606f5-7800-48af-84bd-2310d82d867e@github.com>

On Tue, 11 Feb 2025 23:55:46 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there?

Possibly getName() didn't exist when PStack was first written. It would be good if PStack not only included the type name as it does now, but also the actual name of the blob, which getName() would return.

> An other purpose could be a place holder for additional information in a future which never come.

Yes, and you also see that with the Observer registration and the `Type type = db.lookupType(<typename>)` code, which are only needed if you are going to lookup fields of the subtypes, which most don't ever do, yet they all have this code.
 
> Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM.

Yeah, that's not working right for CodeBlob subtypes that are not RuntimeStubs. Easy to fix though.

> So yes, feel free to clean this up. I will help with review.

Ok. Let me see where things are at after you are done with the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2652549878

From dholmes at openjdk.org  Wed Feb 12 03:46:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Feb 2025 03:46:16 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

test/jdk/java/lang/Thread/virtual/Starvation.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.

You missed the comma after 2025 here. This is now causing failures in our CI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1951933716

From syan at openjdk.org  Wed Feb 12 04:38:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 04:38:19 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
 <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>
Message-ID: <iow9jDZFLb3hH5Im4vQFk-lnBX6c4HZl93SMpWM7GTg=.4e95a434-c0d2-4a48-9c5c-d29b319d6cd4@github.com>

On Wed, 12 Feb 2025 03:43:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
>
> test/jdk/java/lang/Thread/virtual/Starvation.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.
> 
> You missed the comma after 2025 here. This is now causing failures in our CI.

Sorry, I create a new issue [JDK-8349876](https://bugs.openjdk.org/browse/JDK-8349876) for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1951963891

From mbaesken at openjdk.org  Wed Feb 12 07:34:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 07:34:10 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>
Message-ID: <eP4wEbJrjyue_sXBg6NtiK0f9GPkz_qobLw2myon6nQ=.0e7d4ba1-3049-454c-9f25-d74f80a796ea@github.com>

On Tue, 11 Feb 2025 19:01:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm not too familiar with optimization choices in the build system, but it seems libjdwp should be built optimized in the same manner as libjvm.

LIBJVM is built with optimization level  HIGHEST_JVM (seems this is -O3 with gcc/clang) by default , but there are configure-options to switch, if desired, to SIZE or to lto-optimization for libjvm 
https://github.com/openjdk/jdk/blob/adda12b724ec5fb890ef18ae21f0b5985ececfea/make/hotspot/lib/CompileJvm.gmk#L141

LIBJDWP is currently built with optimization level LOW.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2652867797

From mbaesken at openjdk.org  Wed Feb 12 07:34:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 07:34:11 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
 <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
Message-ID: <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>

On Tue, 11 Feb 2025 19:00:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Just a heads up, there is a known issue with -Os and gcc (-Os turns on -fdeclone-ctor-dtor which causes the problem), especially if LTO is active. Turning more optimization levels to -Os could present a problem if you want to have LTO support for the JDK's native code outside of HotSpot as was discussed elsewhere

Thanks for the heads up. Most  JDK libs are C , only very few contain C++ (I think harfbuzz is an example that comes to mind).   As pointed out,  libjdwp is not among the libs with C++.

Do you have an example of a bug caused by the issue you mention (and is this already documented in the JBS somewhere) ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2652871882

From mbaesken at openjdk.org  Wed Feb 12 07:45:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 07:45:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
 <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
 <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
Message-ID: <pKsn-Ek55gNwweWCB4N1N6J58coRVlU8B4hZRsjb0UA=.86b33954-de48-47fe-b227-014f53587787@github.com>

On Wed, 12 Feb 2025 07:31:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> if you want to have LTO support for the JDK's native code outside of HotSpot as was discussed elsewhere

Maybe per lib, additionally to the currently offered optimization options LOW, SIZE, HIGH etc  (the ones we currently have now) ?
But this is for another issue/PR .

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2652890196

From cjplummer at openjdk.org  Wed Feb 12 08:08:23 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Feb 2025 08:08:23 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <eP4wEbJrjyue_sXBg6NtiK0f9GPkz_qobLw2myon6nQ=.0e7d4ba1-3049-454c-9f25-d74f80a796ea@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>
 <eP4wEbJrjyue_sXBg6NtiK0f9GPkz_qobLw2myon6nQ=.0e7d4ba1-3049-454c-9f25-d74f80a796ea@github.com>
Message-ID: <LNW0HUk4qiZqQivWJzWSqah-QO523ZfmFFu9hOrih5w=.ee1cb919-a8e0-4e3d-af2e-6cf672fe1348@github.com>

On Wed, 12 Feb 2025 07:29:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> LIBJDWP is currently built with optimization level LOW.

Yes, but I'm still now sure why it wasn't always built with HIGH. Is there a reason for focusing on footprint here? What is the footprint different between HIGH and LOW?

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2652934161

From kevinw at openjdk.org  Wed Feb 12 08:25:14 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Feb 2025 08:25:14 GMT
Subject: RFR: 8349723: Problemlist jdp tests for macosx-x64
In-Reply-To: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>
References: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>
Message-ID: <XMpjnjY4TJbyJSSGNZng7_jP8IYNQi7YADfZDzkB6Ak=.1bedc124-adaa-4ad4-9d20-002b7472b99c@github.com>

On Mon, 10 Feb 2025 15:33:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial problemlist update.
> Problemlist should be expanded for macosx, from just aarch64 to all, for these JDP tests, as x64 has occasional failures. 
> 
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23541/head:pull/23541` \
> `$ git checkout pull/23541`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23541` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23541/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 23541`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23541`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/23541.diff">https://git.openjdk.org/jdk/pull/23541.diff</a>
> 
> </details>

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23541#issuecomment-2652964353

From kevinw at openjdk.org  Wed Feb 12 08:25:15 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Feb 2025 08:25:15 GMT
Subject: Integrated: 8349723: Problemlist jdp tests for macosx-x64
In-Reply-To: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>
References: <pTeJHrsebDik7ZUjH2GOgBLlQluwY4T5PzY7KIqf8Mg=.60986052-8b38-433b-a170-c81816295237@github.com>
Message-ID: <1dB9a7lU429VnLzWBf9R_GFMwV7_sRDfV1ZAfqfs0lU=.5d205f04-8568-47d2-a967-01a4050f5ca8@github.com>

On Mon, 10 Feb 2025 15:33:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial problemlist update.
> Problemlist should be expanded for macosx, from just aarch64 to all, for these JDP tests, as x64 has occasional failures. 
> 
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/23541/head:pull/23541` \
> `$ git checkout pull/23541`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/23541` \
> `$ git pull https://git.openjdk.org/jdk.git pull/23541/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 23541`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 23541`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/23541.diff">https://git.openjdk.org/jdk/pull/23541.diff</a>
> 
> </details>

This pull request has now been integrated.

Changeset: bb41df44
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb41df44d95cb4cadb8a18b3f999d35e169b35d3
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8349723: Problemlist jdp tests for macosx-x64

Reviewed-by: rriggs, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/23541

From mbaesken at openjdk.org  Wed Feb 12 08:33:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 08:33:11 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <LNW0HUk4qiZqQivWJzWSqah-QO523ZfmFFu9hOrih5w=.ee1cb919-a8e0-4e3d-af2e-6cf672fe1348@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <B-7qtMbCjBD4Em4LXhIs8rikEa2yVplBCeuSHk4LoUI=.7b35c820-f8af-4474-b022-3640d6c76571@github.com>
 <eP4wEbJrjyue_sXBg6NtiK0f9GPkz_qobLw2myon6nQ=.0e7d4ba1-3049-454c-9f25-d74f80a796ea@github.com>
 <LNW0HUk4qiZqQivWJzWSqah-QO523ZfmFFu9hOrih5w=.ee1cb919-a8e0-4e3d-af2e-6cf672fe1348@github.com>
Message-ID: <h2K9AldctVsSyxQT0zGKScyK8wR5XmGoS5lkihI2tsw=.4fb04ed5-d7a3-480b-84f4-e98ac339068e@github.com>

On Wed, 12 Feb 2025 08:05:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > LIBJDWP is currently built with optimization level LOW.
> 
> Yes, but I'm still now sure why it wasn't always built with HIGH. Is there a reason for focusing on footprint here? What is the footprint different between HIGH and LOW?

I tested various jdk native libs that are currently compiled with LOW , how they do with SIZE.
For some of those libs the size reduction is not very good, but for some it is 10 or 20 % .
So I focused on those that are compiled currently with LOW and might do better with SIZE.

I can test with HIGH instead of LOW, but I have for those JDK native libs usually no benchmarks showing any improvements,
For SIZE it is possible to show an improvement (in size) if there is one (or the other way around, for some libs it is easy to show that they do pretty much the same with SIZE and LOW).

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2652979995

From jwaters at openjdk.org  Wed Feb 12 08:36:09 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 12 Feb 2025 08:36:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
 <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
 <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
Message-ID: <8Njkj9a6ctpGKfCSa0qU2R6hmBhJ3w-KufA3h_HZJ_w=.fba12cda-dcd6-4b2a-8a5a-49ac20922caf@github.com>

On Wed, 12 Feb 2025 07:31:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Do you have an example of a bug caused by the issue you mention (and is this already documented in the JBS somewhere) ?

I don't believe this is documented anywhere in the issue tracker, I'll do so in a moment. The bug is an Internal Compiler Error, gcc crashes when that flag is on (And LTO seems to raise the likelihood of gcc crashing). It was supposedly fixed, but the crash still happens even with newer gcc so the fix doesn't seem to have worked

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2652990206

From mbaesken at openjdk.org  Wed Feb 12 08:45:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 08:45:10 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <8Njkj9a6ctpGKfCSa0qU2R6hmBhJ3w-KufA3h_HZJ_w=.fba12cda-dcd6-4b2a-8a5a-49ac20922caf@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <pjzaYC5h3XCFy4zNUVBjDYi0NPWpSVsrshgKFU00Reg=.84cc233c-fd04-4d6f-9517-a7950a33329a@github.com>
 <sW0f7mlble4ci216JSo9gI2vbkbktzcdQakk3RaAALQ=.57855ab8-53ca-4b9d-b8d1-b48ac32df211@github.com>
 <SPx1sVvg65sbwTrfSDjgU3BoYi63HMPE_oxOJMmk-M8=.db31ce11-f54c-42b8-89b5-a409d270ad4e@github.com>
 <8Njkj9a6ctpGKfCSa0qU2R6hmBhJ3w-KufA3h_HZJ_w=.fba12cda-dcd6-4b2a-8a5a-49ac20922caf@github.com>
Message-ID: <r5UAbj1yl4cbJMHujCB9mDM1qwMLCfNfvGAM1qzWvl0=.2d129716-35c8-4c89-9c17-eff52e1fb256@github.com>

On Wed, 12 Feb 2025 08:34:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> The bug is an Internal Compiler Error, gcc crashes when that flag is on (And LTO seems to raise the likelihood of gcc crashing).

Thanks for the details. I never saw this when setting opt-size AND lto/linktime-opt for libjvm; maybe my gcc 11.3 is good and does not show this.   But in case it shows up it is at least a bug that is easily visible because the build fails.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2653006749

From mbaesken at openjdk.org  Wed Feb 12 09:02:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 09:02:15 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX. On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 

This is what I get with HIGH ,  on Linux x86_64 (gcc 11.3 used)

du -sh images/jdk/lib/libjdwp.*
2.0M	images/jdk/lib/libjdwp.debuginfo
316K	images/jdk/lib/libjdwp.so

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2653045377

From sgehwolf at openjdk.org  Wed Feb 12 12:10:17 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Feb 2025 12:10:17 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v15]
In-Reply-To: <GOLkliNcZsHseg0QKDaS2qAfzst8-8o6v_Fki4Cmk00=.1b2a2161-018e-4cf1-8e3f-1ea7de174456@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <GOLkliNcZsHseg0QKDaS2qAfzst8-8o6v_Fki4Cmk00=.1b2a2161-018e-4cf1-8e3f-1ea7de174456@github.com>
Message-ID: <jJNunBu15HQY3T7PEkYbZo0o8_BuA_5okJ0y8zLCVN0=.1271d1da-3af5-4aea-a99d-62f49e040ef3@github.com>

On Fri, 10 Jan 2025 14:57:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
>> 
>> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
>> 
>> This patch addresses this issue by:
>> 
>> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
>> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
>> 
>> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
>> 
>> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
>> 
>> Thoughts?
>> 
>> Testing:
>> 
>> - [x] GHA
>> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
>> - [x] Some manual testing using systemd slices
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Fix missing imports
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Add exclusive access dirs directive for systemd tests
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/1f457977...c83c22eb

keep open bot. Still looking for a review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2653525390

From kvn at openjdk.org  Wed Feb 12 16:28:32 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 16:28:32 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Fix Zero VM build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/1d108349..b09ddce6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=04-05

  Stats: 11 lines in 2 files changed: 7 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533

PR: https://git.openjdk.org/jdk/pull/23533

From cjplummer at openjdk.org  Wed Feb 12 19:31:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Feb 2025 19:31:16 GMT
Subject: RFR: 8349571: Remove JavaThreadFactory interface from SA
In-Reply-To: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>
References: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>
Message-ID: <1sQMCwv8nb3AjzqxNwzxkxMMmW5Fl8h8V_HxdMMDrqs=.e5054f90-155b-4a89-9365-9faa255bdba4@github.com>

On Thu, 6 Feb 2025 23:22:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The SA JavaThreadFactory interface is no longer used, so it is being removed. I stumbled on it while looking at JavaThread related code. It looks like its original purpose is related to JavaThread subclasses at one point being platform dependent, as described in the following JavaThread.java comment:
> 
> 
> /** This is an abstract class because there are certain OS- and
>     CPU-specific operations (like the setting and getting of the last
>     Java frame pointer) which need to be factored out. These
>     operations are implemented by, for example,
>     SolarisSPARCJavaThread, and the concrete subclasses are
>     instantiated by the JavaThreadFactory in the Threads class. */
> 
> 
> However, this is no longer the case, and this comment is being removed as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347).

Thank you for the reviews Kevin and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/23505#issuecomment-2654655458

From cjplummer at openjdk.org  Wed Feb 12 19:31:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Feb 2025 19:31:19 GMT
Subject: RFR: 8349684: Remove SA core file tests from problem list for
 macosx-x64
In-Reply-To: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>
References: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>
Message-ID: <jB93XpNV1hKc8RfHF1CaVubjwlx0wSyhXVk8m_ILzKk=.b0af8c84-819c-4692-8254-897836283f15@github.com>

On Sat, 8 Feb 2025 03:45:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Now that we have retired OSX 11 and earlier, [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) does not seem to reproduce anymore. I ran the SA core file tests about 2000 times and only saw 1 failure, and it was not related to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433). I think this is acceptable and we should make SA core file tests on macosx-x64 part of our CI testing again and see how they do.

Thank you for the reviews Kevin and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/23529#issuecomment-2654651991

From cjplummer at openjdk.org  Wed Feb 12 19:31:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Feb 2025 19:31:17 GMT
Subject: Integrated: 8349571: Remove JavaThreadFactory interface from SA
In-Reply-To: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>
References: <sor3sOgjAkl7bZQWlytiVLEO2h-3vQFv2vPcPjYuMTg=.bf157887-e49b-4f88-b13e-acd43585ff83@github.com>
Message-ID: <KN61pkxNd_p2iIVReTix251nZgDFBu_7u-cOQkAolO0=.1c4b8a78-9f4d-4230-b6c1-0102e6e3345a@github.com>

On Thu, 6 Feb 2025 23:22:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The SA JavaThreadFactory interface is no longer used, so it is being removed. I stumbled on it while looking at JavaThread related code. It looks like its original purpose is related to JavaThread subclasses at one point being platform dependent, as described in the following JavaThread.java comment:
> 
> 
> /** This is an abstract class because there are certain OS- and
>     CPU-specific operations (like the setting and getting of the last
>     Java frame pointer) which need to be factored out. These
>     operations are implemented by, for example,
>     SolarisSPARCJavaThread, and the concrete subclasses are
>     instantiated by the JavaThreadFactory in the Threads class. */
> 
> 
> However, this is no longer the case, and this comment is being removed as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347).

This pull request has now been integrated.

Changeset: 2a5d1da3
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a5d1da3355a4df3109ec42646b5b0cf088b4c2a
Stats:     40 lines in 2 files changed: 0 ins; 40 del; 0 mod

8349571: Remove JavaThreadFactory interface from SA

Reviewed-by: kevinw, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/23505

From cjplummer at openjdk.org  Wed Feb 12 19:31:20 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Feb 2025 19:31:20 GMT
Subject: Integrated: 8349684: Remove SA core file tests from problem list for
 macosx-x64
In-Reply-To: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>
References: <3WOfttiBMCFBdue0F4r_IbABZ6mApIQ44SjO3HCfkd4=.0a7f3c6a-1232-409d-9b09-84e972c9a36c@github.com>
Message-ID: <8S1niwoSM_JZWWZ6uWH8TZGPyS7sFBpCgz_MwYYoSFI=.4a51c212-0216-4bcc-9194-60fca1790a44@github.com>

On Sat, 8 Feb 2025 03:45:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Now that we have retired OSX 11 and earlier, [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433) does not seem to reproduce anymore. I ran the SA core file tests about 2000 times and only saw 1 failure, and it was not related to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433). I think this is acceptable and we should make SA core file tests on macosx-x64 part of our CI testing again and see how they do.

This pull request has now been integrated.

Changeset: 74e458ba
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74e458bad6ba6e8aa85e0950119963a6f6cb2c03
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8349684: Remove SA core file tests from problem list for macosx-x64

Reviewed-by: kevinw, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/23529

From kvn at openjdk.org  Wed Feb 12 20:21:13 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 20:21:13 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
Message-ID: <lxju-ofQn-wIudGzN2NFQopKiFzzcn0ynYsE3Cnj-aQ=.3476c1da-ec8e-45d7-a3e7-b041458d1683@github.com>

On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero VM build

It is ready for re-review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2654754643

From kvn at openjdk.org  Thu Feb 13 01:27:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 01:27:41 GMT
Subject: RFR: 8349753: Incorrect use of CodeBlob::is_buffer_blob() in few
 places
Message-ID: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>

`CodeBlob::is_buffer_blob()` method is incorrectly used in few places because BufferBlob is not "leaf" class. You need to add checks for its subclasses too.

I also updated statistic output for CodeCache (`-XX:+PrintCodeCache -XX:+Verbose`) and corresponding test to reflect current state of code blobs.

Tested tier1-4, stress, xcomp

New output:

Non-nmethod blobs:
 #67 runtime = 43K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #0 upcall = 0K
 #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #1 exception = 0K (hdr 0K 30%, loc 0K 3%, code 0K 63%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #3 safepoint = 4K (hdr 0K 4%, loc 0K 1%, code 4K 93%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #1 mh_adapter = 10K (hdr 0K 0%, loc 0K 0%, code 9K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #1 vtable = 32K (hdr 0K 0%, loc 0K 0%, code 32K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #0 other = 0K


Output before:

Non-nmethod blobs:
 #66 runtime = 42K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #6 other = 47K (hdr 0K 0%, loc 0K 0%, code 46K 98%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])

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

Commit messages:
 - 8349753: Incorrect use of CodeBlob::is_buffer_blob() in few places

Changes: https://git.openjdk.org/jdk/pull/23607/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349753
  Stats: 47 lines in 4 files changed: 45 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23607/head:pull/23607

PR: https://git.openjdk.org/jdk/pull/23607

From cjplummer at openjdk.org  Thu Feb 13 01:55:22 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Feb 2025 01:55:22 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
Message-ID: <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>

On Wed, 12 Feb 2025 08:59:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This is what I get with HIGH , on Linux x86_64 (gcc 11.3 used)
> 
> du -sh images/jdk/lib/libjdwp.* 2.0M images/jdk/lib/libjdwp.debuginfo 316K images/jdk/lib/libjdwp.so

So it's about a 5% footprint increase to go from LOW to HIGH, and about a 10% footprint savings to go from LOW to SIZE. What specific gcc -O flag do each of these map to? I figure SIZE == -Os, HIGH == -O3. Not sure about LOW, but if it is -O1, then -Os will probably give a performance increase since it is -O2 minus some code bloat optimizations and plus some code size optimizations.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2655251215

From dlong at openjdk.org  Thu Feb 13 01:59:09 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 13 Feb 2025 01:59:09 GMT
Subject: RFR: 8349753: Incorrect use of CodeBlob::is_buffer_blob() in few
 places
In-Reply-To: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
References: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
Message-ID: <YZGjipWbn268ZOCpm594TyIYZk8Sb7k4J7IWxpAvzzE=.bdc9da6a-6b7a-4d5b-853a-fe02cb5b7270@github.com>

On Thu, 13 Feb 2025 01:22:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `CodeBlob::is_buffer_blob()` method is incorrectly used in few places because BufferBlob is not "leaf" class. You need to add checks for its subclasses too.
> 
> I also updated statistic output for CodeCache (`-XX:+PrintCodeCache -XX:+Verbose`) and corresponding test to reflect current state of code blobs.
> 
> Tested tier1-4, stress, xcomp
> 
> New output:
> 
> Non-nmethod blobs:
>  #67 runtime = 43K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 upcall = 0K
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 exception = 0K (hdr 0K 30%, loc 0K 3%, code 0K 63%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #3 safepoint = 4K (hdr 0K 4%, loc 0K 1%, code 4K 93%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 mh_adapter = 10K (hdr 0K 0%, loc 0K 0%, code 9K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 vtable = 32K (hdr 0K 0%, loc 0K 0%, code 32K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 other = 0K
> 
> 
> Output before:
> 
> Non-nmethod blobs:
>  #66 runtime = 42K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #6 other = 47K (hdr 0K 0%, loc 0K 0%, code 46K 98%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])

Looks good.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23607#pullrequestreview-2613632491

From kvn at openjdk.org  Thu Feb 13 01:59:09 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 01:59:09 GMT
Subject: RFR: 8349753: Incorrect use of CodeBlob::is_buffer_blob() in few
 places
In-Reply-To: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
References: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
Message-ID: <GR8GGi3_nIlQAWI5_CMm4ypEv-3Gt7PZ3h9Tp3zqsnA=.b1e839bf-09ff-4386-ad2c-883b0389ef57@github.com>

On Thu, 13 Feb 2025 01:22:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `CodeBlob::is_buffer_blob()` method is incorrectly used in few places because BufferBlob is not "leaf" class. You need to add checks for its subclasses too.
> 
> I also updated statistic output for CodeCache (`-XX:+PrintCodeCache -XX:+Verbose`) and corresponding test to reflect current state of code blobs.
> 
> Tested tier1-4, stress, xcomp
> 
> New output:
> 
> Non-nmethod blobs:
>  #67 runtime = 43K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 upcall = 0K
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 exception = 0K (hdr 0K 30%, loc 0K 3%, code 0K 63%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #3 safepoint = 4K (hdr 0K 4%, loc 0K 1%, code 4K 93%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 mh_adapter = 10K (hdr 0K 0%, loc 0K 0%, code 9K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 vtable = 32K (hdr 0K 0%, loc 0K 0%, code 32K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 other = 0K
> 
> 
> Output before:
> 
> Non-nmethod blobs:
>  #66 runtime = 42K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #6 other = 47K (hdr 0K 0%, loc 0K 0%, code 46K 98%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])

Thank you, Dean

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

PR Comment: https://git.openjdk.org/jdk/pull/23607#issuecomment-2655255875

From cjplummer at openjdk.org  Thu Feb 13 02:36:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Feb 2025 02:36:16 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
Message-ID: <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com>

On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero VM build

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 118:

> 116:   }
> 117: 
> 118:   public static Class<?> getClassFor(Address addr) {

Did you consider using a lookup table here that is indexed using the kind value?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 146:

> 144:         }
> 145:       }
> 146:       return null;

Should this be an assert?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 213:

> 211: 
> 212:   public boolean isUncommonTrapBlob()   {
> 213:     if (!VM.getVM().isServerCompiler()) return false;

Why is the check needed? Why not just return the value `getKind() == UncommonTrapKind` result below?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 95:

> 93:   }
> 94: 
> 95:   public CodeBlob createCodeBlobWrapper(Address cbAddr, Address start) {

I think the use of the name "start" here is a carryover from `findBlobUnsafe(Address start)`. I find it a very misleading name. cbAddr points to the "start" of the blob. "start" points somewhere in the middle of the blob. In fact callers of this API somethimes pass in findStart(addr) for cbAddr, which just adds to the confusion. Perhaps this is a good time to rename "start" to something else, although I can't come up with a good suggestion, but I think anything other than "start" would be an improvement. Maybe "pcAddr".  That aligns with the "for PC=" message below. Or maybe just "ptr" which aligns with `createCodeBlobWrapper(findStart(ptr), ptr);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953665953
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953666268
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953667349
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953682557

From kvn at openjdk.org  Thu Feb 13 03:43:17 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 03:43:17 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
 <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com>
Message-ID: <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com>

On Thu, 13 Feb 2025 02:06:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Zero VM build
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 118:
> 
>> 116:   }
>> 117: 
>> 118:   public static Class<?> getClassFor(Address addr) {
> 
> Did you consider using a lookup table here that is indexed using the kind value?

Example please.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 146:
> 
>> 144:         }
>> 145:       }
>> 146:       return null;
> 
> Should this be an assert?

I don't think we need it - the caller `CodeCache.createCodeBlobWrapper()` will throw `RuntimeException` when `null` is returned.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 213:
> 
>> 211: 
>> 212:   public boolean isUncommonTrapBlob()   {
>> 213:     if (!VM.getVM().isServerCompiler()) return false;
> 
> Why is the check needed? Why not just return the value `getKind() == UncommonTrapKind` result below?

`UncommonTrapKind` and `ExceptionKind` are not initialized for Client VM because corresponding `CodeBlobKind` values are not defined. See `CodeBlob.initialize()`.
Their not initialized value will be 0 which matches `CodeBlobKind::None` value. Returning true in such case will be incorrect.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 95:
> 
>> 93:   }
>> 94: 
>> 95:   public CodeBlob createCodeBlobWrapper(Address cbAddr, Address start) {
> 
> I think the use of the name "start" here is a carryover from `findBlobUnsafe(Address start)`. I find it a very misleading name. cbAddr points to the "start" of the blob. "start" points somewhere in the middle of the blob. In fact callers of this API somethimes pass in findStart(addr) for cbAddr, which just adds to the confusion. Perhaps this is a good time to rename "start" to something else, although I can't come up with a good suggestion, but I think anything other than "start" would be an improvement. Maybe "pcAddr".  That aligns with the "for PC=" message below. Or maybe just "ptr" which aligns with `createCodeBlobWrapper(findStart(ptr), ptr);`

`cbPc` with comment explaining that it could be inside code blob.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953732919
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953733212
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953738572
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953745389

From asmehra at openjdk.org  Thu Feb 13 04:10:11 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 13 Feb 2025 04:10:11 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks
In-Reply-To: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
Message-ID: <8yqgZ4ffmEyui_CyUR9lS-2MV4ONfzSaA-pMz-VvDMA=.e92da2b8-cfc5-4ef9-ab33-9d14ca02a2f8@github.com>

On Wed, 5 Feb 2025 22:32:58 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
> 
> Passed tiers 1 - 5 testing.

src/hotspot/share/cds/aotCodeSource.cpp line 762:

> 760:   }
> 761: 
> 762:   if (is_boot_classpath && runtime_css.has_next() && (need_to_check_app_classpath() || num_module_paths() > 0)) {

I am not sure I get what this block is for. Is it for the case where runtime boot cp has more entries than the dumptime boot cp, and it is checking if the extra entries really exist or they are just empty? If so, then `check_paths_existence` should only be checking the extra entries in the boot cp, not all of them.

Can you please explain this and probably add a comment as well to describe what this block is for.

src/hotspot/share/cds/aotCodeSource.cpp line 894:

> 892: // matched exactly.
> 893: bool AOTCodeSourceConfig::need_lcp_match(AllCodeSourceStreams& all_css) const {
> 894:   if (!need_lcp_match_helper(boot_start(), boot_end(), all_css.boot_cp()) ||

Can we reverse these conditions to make it easier to read?


  if (need_lcp_match_helper(boot_start(), boot_end(), all_css.boot_cp()) &&
      need_lcp_match_helper(app_start(), app_end(), all_css.app_cp())) {
    return true;
  } else {
    return false;
  }

src/hotspot/share/cds/aotCodeSource.cpp line 903:

> 901: 
> 902: bool AOTCodeSourceConfig::need_lcp_match_helper(int start, int end, CodeSourceStream& css) const {
> 903:   if (app_end() == boot_start()) {

I feel this block belongs to the caller `need_lcp_match`.

src/hotspot/share/cds/aotCodeSource.hpp line 213:

> 211: 
> 212:   // Common accessors
> 213:   int boot_start()                       const { return 1; }

Can we rename these methods to something like boot_start() -> boot_cp_start_index().
At the call site it makes it clear it is referring to the bootclasspath index, and not booting something :)

src/hotspot/share/cds/aotCodeSource.hpp line 234:

> 232:   // Functions used only during dumptime
> 233:   static void dumptime_init(TRAPS);
> 234:   static size_t estimate_size_for_archive() {

This method doesn't seem to be in use. Can this be removed?

src/hotspot/share/cds/filemap.cpp line 318:

> 316:   if (header()->has_full_module_graph() && has_extra_module_paths) {
> 317:     CDSConfig::stop_using_optimized_module_handling();
> 318:     log_info(cds)("optimized module handling: disabled because of extra module path(s) are specified");

typo: "disabled because ~of~ extra module path(s) are specified"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1953766439
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1953732835
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1953722869
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1953489002
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1953383815
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1953768345

From cjplummer at openjdk.org  Thu Feb 13 05:22:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Feb 2025 05:22:14 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
 <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com>
 <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com>
Message-ID: <vn5PGBP9fcajrfw0rRxo6CRMOKRZsUEzsremVe7X0qQ=.ff23c214-5599-49fb-9732-75e4df74c819@github.com>

On Thu, 13 Feb 2025 03:26:19 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 118:
>> 
>>> 116:   }
>>> 117: 
>>> 118:   public static Class<?> getClassFor(Address addr) {
>> 
>> Did you consider using a lookup table here that is indexed using the kind value?
>
> Example please.

static Class wrapperClasses = new Class[Number_Of_Kinds];
    wrapperClasses[NMethodKind] = NMethodBlob.class;
    wrapperClasses[BufferKind] = BufferBopb.class;
    ...;
    wrapperClasses[SafepointKind] = SafepointBlob.class;



    CodeBlob cb = new CodeBlob(addr);
    return wrapperClasses[cb.getKind()];

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 146:
>> 
>>> 144:         }
>>> 145:       }
>>> 146:       return null;
>> 
>> Should this be an assert?
>
> I don't think we need it - the caller `CodeCache.createCodeBlobWrapper()` will throw `RuntimeException` when `null` is returned.

I guess my real question is whether or not it can be considered normal behavior to return null. It seems it should never happen, which is why I was suggesting an assert.

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java line 213:
>> 
>>> 211: 
>>> 212:   public boolean isUncommonTrapBlob()   {
>>> 213:     if (!VM.getVM().isServerCompiler()) return false;
>> 
>> Why is the check needed? Why not just return the value `getKind() == UncommonTrapKind` result below?
>
> `UncommonTrapKind` and `ExceptionKind` are not initialized for Client VM because corresponding `CodeBlobKind` values are not defined. See `CodeBlob.initialize()`.
> Their not initialized value will be 0 which matches `CodeBlobKind::None` value. Returning true in such case will be incorrect.

Ok. Leaving UncommonTrapKind and ExceptionKind uninitialized seems a bit error prone. Perhaps they can be given some sort of INVALID value.

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 95:
>> 
>>> 93:   }
>>> 94: 
>>> 95:   public CodeBlob createCodeBlobWrapper(Address cbAddr, Address start) {
>> 
>> I think the use of the name "start" here is a carryover from `findBlobUnsafe(Address start)`. I find it a very misleading name. cbAddr points to the "start" of the blob. "start" points somewhere in the middle of the blob. In fact callers of this API somethimes pass in findStart(addr) for cbAddr, which just adds to the confusion. Perhaps this is a good time to rename "start" to something else, although I can't come up with a good suggestion, but I think anything other than "start" would be an improvement. Maybe "pcAddr".  That aligns with the "for PC=" message below. Or maybe just "ptr" which aligns with `createCodeBlobWrapper(findStart(ptr), ptr);`
>
> `cbPc` with comment explaining that it could be inside code blob.

That sounds fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953818292
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953819796
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953821968
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1953822595

From jrose at openjdk.org  Thu Feb 13 07:44:19 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 13 Feb 2025 07:44:19 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
Message-ID: <Z3zsWZU5JO5jqKnUtnysgiEkpMd-Mqvvc8F3rP9dBJ8=.34222123-6c96-44a4-ad68-9fb3c3e928c3@github.com>

On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero VM build

I've read the code and it looks good.  I find myself wishing for a few more comments to guide me, especially in knowing which methods to pay attention to, and which to ignore as "pure plumbing".

The array of vptr-ptrs is the key element.  It seems to work nicely.

There are lots of regularizations here, which I enjoy.  But the new code has (to me) distracting irregularities.  Why define one Vptr as a struct and others as classes?  Did we really regularize the names of all the print functions (they were irregular before)?

I was glad to see lots of magic code deleted from SA.  Although, having to look at SA at all is annoying!

I noticed a lot of churn in "innocent bystander" client code that looks like this:


                   p2i(_frame.pc()), decode_offset);
-      nm()->print_on(&ss);
+      nm()->print_on_v(&ss);
       nm()->method()->print_codes_on(&ss);


What is the client maintainer (or any casual reader) supposed to get from the "_v" suffix?  I know we have made the "v/nv" distinction before, but it is rather obscure, not documeted here.  Is it described elsewhere in our code base?  Our use of it here should be docuemented in codeBlob.hpp.

Normally, we try to keep client APIs invariant while doing refactorings like this, so as to avoid touching all the client code.

In this case, we have to use a new naming convention to distinguish all versions of (say) print_on:

M. The implementation in each CB class K, which can be private if K::Vptr is a friend.
P. The public API point, used outside of the CB classes, as well as inside.
V. The name of the virtual function defined by each K::Vptr.

I would expect I to have the "nice name" like print_on, not print_on_v, while while the private method M would be print_on_impl or print_on_nv, and never called except from Vptr or other methods of the same name.  But any convention will work, as long as it is documented and held to consistently.

I'm sympathetic to both Andrew's call for maacro-enforced regularity, and Vladimir's objection that macros make things hard to follow.  If macros won't work for us here, let's define a documented pattern and stick to it closely, documenting our decisions as we go.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2655760868

From shade at openjdk.org  Thu Feb 13 08:32:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Feb 2025 08:32:16 GMT
Subject: RFR: 8349753: Incorrect use of CodeBlob::is_buffer_blob() in few
 places
In-Reply-To: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
References: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
Message-ID: <aQC2xSmG77HCwLjI0LQsu-lrAlUj-_ouGgvDkTwYk1I=.f3fe27e9-1f67-4641-8441-4862710a3bf6@github.com>

On Thu, 13 Feb 2025 01:22:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `CodeBlob::is_buffer_blob()` method is incorrectly used in few places because BufferBlob is not "leaf" class. You need to add checks for its subclasses too.
> 
> I also updated statistic output for CodeCache (`-XX:+PrintCodeCache -XX:+Verbose`) and corresponding test to reflect current state of code blobs.
> 
> Tested tier1-4, stress, xcomp
> 
> New output:
> 
> Non-nmethod blobs:
>  #67 runtime = 43K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 upcall = 0K
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 exception = 0K (hdr 0K 30%, loc 0K 3%, code 0K 63%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #3 safepoint = 4K (hdr 0K 4%, loc 0K 1%, code 4K 93%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 mh_adapter = 10K (hdr 0K 0%, loc 0K 0%, code 9K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 vtable = 32K (hdr 0K 0%, loc 0K 0%, code 32K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 other = 0K
> 
> 
> Output before:
> 
> Non-nmethod blobs:
>  #66 runtime = 42K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #6 other = 47K (hdr 0K 0%, loc 0K 0%, code 46K 98%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])

Looks fine. I spot-checked other `CodeBlobKind`-s, and I don't think we are missing any other.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23607#pullrequestreview-2614215254

From aboldtch at openjdk.org  Thu Feb 13 08:32:21 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 13 Feb 2025 08:32:21 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
Message-ID: <Z20zaowGEnlGq_wSYvZbz9jVb7CWBjb4MYOTpmXkJ0o=.6c6c608d-8694-4eb5-9ac6-45001a33b4d8@github.com>

On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Zero VM build

Similar to what @rose00 noted I think the `_v` and `_nv` suffixes are unfortunate in the public API.

Maybe it we could add a protected `x_impl` containing the implementation, then dispatch to the correct one based on _kind, using the Vptr abstraction. And have the normal print_on method use this. We could let our leaf types to directly call the specific implementation, not that I think that our print functions require compile time devirtualisation. 

There are many solutions here with their pros and cons.

src/hotspot/share/code/codeBlob.hpp line 140:

> 138:       instance->print_value_on_nv(st);
> 139:     }
> 140:   };

I wonder why the base class is not abstract. AFAICT `print_value_on` is unreachable and `print_on` is only used by `DeoptimizationBlob::Vptr` which also seems like a behavioural change, as before this patch calling `print_on` a `DeoptimizationBlob` object would dispatch to `SingletonBlob::print_on` not `CodeBlob::print_on`. 

Suggestion:

 struct Vptr {
    virtual void print_on(const CodeBlob* instance, outputStream* st) const = 0;
    virtual void print_value_on(const CodeBlob* instance, outputStream* st) const = 0;
  };

src/hotspot/share/code/codeBlob.hpp line 339:

> 337:   void print_value_on(outputStream* st) const;
> 338: 
> 339:   class Vptr : public CodeBlob::Vptr {

I wonder if these should share the same type hierarchy as tier container class. This would also solve the issueI noted in my other comment about not calling the correct `print_on`.
Suggestion:

  class Vptr : public RuntimeBlob::Vptr {

src/hotspot/share/code/codeBlob.hpp line 427:

> 425:   void print_value_on(outputStream* st) const;
> 426: 
> 427:   class Vptr : public CodeBlob::Vptr {

Suggestion:

  class Vptr : public RuntimeBlob::Vptr {

src/hotspot/share/code/codeBlob.hpp line 467:

> 465:   void print_value_on(outputStream* st) const;
> 466: 
> 467:   class Vptr : public CodeBlob::Vptr {

Suggestion:

  class Vptr : public RuntimeBlob::Vptr {

src/hotspot/share/code/codeBlob.hpp line 553:

> 551:   void print_value_on(outputStream* st) const;
> 552: 
> 553:   class Vptr : public CodeBlob::Vptr {

This one specifically
Suggestion:

  class Vptr : public SingletonBlob::Vptr {

src/hotspot/share/code/codeBlob.hpp line 679:

> 677:   void print_value_on(outputStream* st) const;
> 678: 
> 679:   class Vptr : public CodeBlob::Vptr {

Suggestion:

  class Vptr : public RuntimeBlob::Vptr {

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

PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2614177723
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954019308
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954024528
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954028620
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954028940
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954027733
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954029504

From mbaesken at openjdk.org  Thu Feb 13 09:11:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Feb 2025 09:11:11 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
 <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
Message-ID: <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>

On Thu, 13 Feb 2025 01:52:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 
> So it's about a 5% footprint increase to go from LOW to HIGH, and about a 10% footprint savings to go from LOW to SIZE. What specific gcc -O flag do each of these map to? I figure SIZE == -Os, HIGH == -O3. Not sure about LOW, but if it is -O1, then -Os will probably give a performance increase since it is -O2 minus some code bloat optimizations and plus some code size optimizations.


Please see 
https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L310

On gcc/clang , SIZE is indeed -OS ;  HIGH is -O3;  LOW (=NORM) is -O2 .
'minus some code bloat optimizations'  yes  some alignment (-falign*) options are omitted with -Os (see https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html 

Btw what is also interesting is LTO optimization ;  with gcc this has high optimization and for some libs quite large size reduction because at link time it can remove/rearrange quite a lot of code leading to smaller libs .
But currently we have LTO support only for hotspot.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2655959995

From kevinw at openjdk.org  Thu Feb 13 12:30:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Feb 2025 12:30:32 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v2]
In-Reply-To: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
Message-ID: <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>

> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
> 
> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - comments
 - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
 - (c)
 - typo
 - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
 - Also XMLParseException
 - RMMB comment update
 - Deprecate XML interchange in DescriptorSupport

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23038/files
  - new: https://git.openjdk.org/jdk/pull/23038/files/f1aeaf95..1d236064

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23038&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23038&range=00-01

  Stats: 189272 lines in 4662 files changed: 93514 ins; 76111 del; 19647 mod
  Patch: https://git.openjdk.org/jdk/pull/23038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23038/head:pull/23038

PR: https://git.openjdk.org/jdk/pull/23038

From kevinw at openjdk.org  Thu Feb 13 12:33:17 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Feb 2025 12:33:17 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v2]
In-Reply-To: <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
Message-ID: <aP7EFjEXolc8BisVIiT4XO02tmk8apRanKqPIBGHMms=.8aea6c95-c01d-427c-9b17-1cda13d3957d@github.com>

On Thu, 13 Feb 2025 12:30:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
>> 
>> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - comments
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - (c)
>  - typo
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - Also XMLParseException
>  - RMMB comment update
>  - Deprecate XML interchange in DescriptorSupport

Thanks for the comments @dfuch 
Added the "can be implemented externally" wording.

I'm adding comments about XMLParseException usage, one for each use, which is quite verbose BUT temporary, as this is all about planning for imminent removal.

(Looking around at other uses of @SuppressWarnings("removal") I didn't find one where we spell out in a comment exactly what is for removal that we are suppressing.)

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

PR Comment: https://git.openjdk.org/jdk/pull/23038#issuecomment-2656459128

From kvn at openjdk.org  Thu Feb 13 16:01:11 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 16:01:11 GMT
Subject: RFR: 8349753: Incorrect use of CodeBlob::is_buffer_blob() in few
 places
In-Reply-To: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
References: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
Message-ID: <rL5Rj4Zuc72vBxJQz1xYTqsJMGDJKzor1QvoKyWi5hc=.005eeaf2-8a1e-42b1-891a-28f67d0f82e9@github.com>

On Thu, 13 Feb 2025 01:22:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `CodeBlob::is_buffer_blob()` method is incorrectly used in few places because BufferBlob is not "leaf" class. You need to add checks for its subclasses too.
> 
> I also updated statistic output for CodeCache (`-XX:+PrintCodeCache -XX:+Verbose`) and corresponding test to reflect current state of code blobs.
> 
> Tested tier1-4, stress, xcomp
> 
> New output:
> 
> Non-nmethod blobs:
>  #67 runtime = 43K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 upcall = 0K
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 exception = 0K (hdr 0K 30%, loc 0K 3%, code 0K 63%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #3 safepoint = 4K (hdr 0K 4%, loc 0K 1%, code 4K 93%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 mh_adapter = 10K (hdr 0K 0%, loc 0K 0%, code 9K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 vtable = 32K (hdr 0K 0%, loc 0K 0%, code 32K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 other = 0K
> 
> 
> Output before:
> 
> Non-nmethod blobs:
>  #66 runtime = 42K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #6 other = 47K (hdr 0K 0%, loc 0K 0%, code 46K 98%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])

Thank you, Aleksey, for review.

I will wait until [PR for moving Relocation from CodeCache]( https://github.com/openjdk/jdk/pull/21276) is integrated to not mess up @bulasevich work.

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

PR Comment: https://git.openjdk.org/jdk/pull/23607#issuecomment-2657049881

From kvn at openjdk.org  Thu Feb 13 16:12:19 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 16:12:19 GMT
Subject: Integrated: 8349753: Incorrect use of CodeBlob::is_buffer_blob() in
 few places
In-Reply-To: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
References: <BervYHmXszgQi_nFQycWJb5NmKi7CF-JEnolpddVNLQ=.c818538f-9a0b-4595-918e-d0d832221862@github.com>
Message-ID: <sU6rsfR_C9RF6uHfMz8ybeneJohfATbGkEYKC1dEER0=.afb26277-0c3b-4eba-9e70-6338f30acb06@github.com>

On Thu, 13 Feb 2025 01:22:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `CodeBlob::is_buffer_blob()` method is incorrectly used in few places because BufferBlob is not "leaf" class. You need to add checks for its subclasses too.
> 
> I also updated statistic output for CodeCache (`-XX:+PrintCodeCache -XX:+Verbose`) and corresponding test to reflect current state of code blobs.
> 
> Tested tier1-4, stress, xcomp
> 
> New output:
> 
> Non-nmethod blobs:
>  #67 runtime = 43K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 upcall = 0K
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 exception = 0K (hdr 0K 30%, loc 0K 3%, code 0K 63%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #3 safepoint = 4K (hdr 0K 4%, loc 0K 1%, code 4K 93%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 mh_adapter = 10K (hdr 0K 0%, loc 0K 0%, code 9K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 vtable = 32K (hdr 0K 0%, loc 0K 0%, code 32K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #0 other = 0K
> 
> 
> Output before:
> 
> Non-nmethod blobs:
>  #66 runtime = 42K (hdr 4K 10%, loc 1K 3%, code 36K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 uncommon trap = 0K (hdr 0K 13%, loc 0K 2%, code 0K 84%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #1 deoptimization = 2K (hdr 0K 3%, loc 0K 1%, code 2K 94%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #639 adapter = 955K (hdr 44K 4%, loc 24K 2%, code 880K 92%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #12 buffer blob = 917K (hdr 0K 0%, loc 0K 0%, code 916K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
>  #6 other = 47K (hdr 0K 0%, loc 0K 0%, code 46K 98%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])

This pull request has now been integrated.

Changeset: 0b50e479
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b50e479a060cf745a3e858d535516444fe80fd8
Stats:     47 lines in 4 files changed: 45 ins; 0 del; 2 mod

8349753: Incorrect use of CodeBlob::is_buffer_blob() in few places

Reviewed-by: dlong, shade

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

PR: https://git.openjdk.org/jdk/pull/23607

From stuefe at openjdk.org  Thu Feb 13 16:14:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 13 Feb 2025 16:14:02 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
Message-ID: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>

Greetings,

This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 

Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.

I wanted to track that information correctly and display it clearly in a way that is easy to understand.

The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).

The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.

The statistic gives us two new forms of output:

1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:


Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
    Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
    none                        1205512    155104    982984     33712         0         0         0         0         0     33712
    parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
    optimizer                    916584         0    556416         0         0         0         0         0         0    360168
    escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
    connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
    macroEliminate               196448         0    196448         0         0         0         0         0         0         0
    iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
    incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824     65456
    incrementalInline_igvn       458512         0    163640    294872         0         0         0         0         0         0
    incrementalInline_inline      32728         0         0     32728         0         0         0         0         0         0
                                 337880         0    108504    229376         0         0         0         0         0         0
    idealLoop                   2499568         0    566696   1932872         0         0         0         0         0         0
    idealLoopVerify              327600         0         0    327600         0         0         0         0         0         0
    ccp                           65456         0     32728         0         0         0         0         0         0     32728
    macroExpand                 1898544         0   1570944    327600         0         0         0         0         0         0
    graphReshape                 347920         0    347920         0         0         0         0         0         0         0
    matcher                     9480400   1817928   6417448   1245024         0         0         0         0         0         0
    postselect_cleanup           163800    163800         0         0         0         0         0         0         0         0
    scheduler                    458192     32728    425464         0         0         0         0         0         0         0
    regalloc                     178072    178072         0         0         0         0         0         0         0         0
    ctorChaitin                   39432     39432         0         0         0         0         0         0         0         0
    regAllocSplit               1865496     32728   1832768         0         0         0         0         0         0         0
    chaitinCoalesce1            1277112    196608   1080504         0         0         0         0         0         0         0
    peephole                      32728         0     32728         0         0         0         0         0         0         0
    output                     17868312  17868312         0         0         0         0         0         0         0         0
    shorten branches             458472     65456     32728    360288         0         0         0         0         0         0


This is pretty self-explanatory. In this example, when the compilation hit its peak of 58MB, it shows how much (column `Total`) we have allocated on behalf of each separate C2 phase that finished. Note that "none" means allocations happening outside of a TracePhase scope. The columns following `Total` show the breakup, in this particular phase, into individual arena types (resourcearea, node arena etc).

2) We also get a detailed timeline of phase execution and the gradual memory buildup. This also shows large spikes of memory that were confined inside the phase, and that we never got to see before:


    Allocation timelime by phase:
    Phase seq. number                             Bytes                  Nodes
    >0                            (outside)    102120 (+102120)       3 (+3) 
     >1                               parse  11787496 (+11685376)   7151 (+7148) 
    <0 (cont.)                    (outside)  11787496 (+0)         7151 (+0) 
     >2                           optimizer  11787496 (+0)         7151 (+0) 
      >3                            iterGVN  12180392 (+392896)    6313 (-838) 
     <2 (cont.)                   optimizer  12180392 (+0)         6313 (+0) 
      >4                  incrementalInline  12180392 (+0)         6313 (+0) 
       >5          incrementalInline_inline  12213120 (+32728)     6330 (+17) 
      <4 (cont.)          incrementalInline  12213120 (+0)         6330 (+0) 
       >6             incrementalInline_pru  12213120 (+0)         6287 (-43) 
      <4 (cont.)          incrementalInline  12213120 (+0)         6287 (+0) 
       >7            incrementalInline_igvn  12213120 (+0)         6286 (-1) 
      <4 (cont.)          incrementalInline  16631400 (+4418280)  17200 (+10914) 
       >8             incrementalInline_pru  16631400 (+0)        10185 (-7015) 
      <4 (cont.)          incrementalInline  16631400 (+0)        10185 (+0) 
       >9            incrementalInline_igvn  17122640 (+491240)    9374 (-811) 
      <4 (cont.)          incrementalInline  17122640 (+0)         9374 (+0) 
     <2 (cont.)                   optimizer  17122640 (+0)         9396 (+22) 
      >10             incrementalInline_pru  17122640 (+0)         9360 (-36) 
     <2 (cont.)                   optimizer  17122640 (+0)         9360 (+0) 
      >11            incrementalInline_igvn  17122640 (+0)         9353 (-7) 
     <2 (cont.)                   optimizer  17745072 (+622432)    9318 (-35) 
      >12                                    18082952 (+337880)    9317 (-1) 
     <2 (cont.)                   optimizer  18082952 (+0)         9317 (+0) 
      >13                         idealLoop  18420712 (+337760)    9247 (-70)         significant temporary peak: 19762880 (+1679928)
 
 < SNIP SNIP >

     <41 (cont.)                   regalloc  52599072 (+0)        23604 (+0) 
      >71                     chaitinSelect  52599072 (+0)        23604 (+0) 
     <41 (cont.)                   regalloc  52599072 (+0)        23604 (+0) 
      >72              postAllocCopyRemoval  52599072 (+0)        19285 (-4319)       significant temporary peak: 58359200 (+5760128)
     <41 (cont.)                   regalloc  52599072 (+0)        19285 (+0) 
      >73                    mergeMultidefs  52599072 (+0)        19285 (+0) 
     <41 (cont.)                   regalloc  52599072 (+0)        19285 (+0) 
      >74                       fixupSpills  52599072 (+0)        19256 (-29) 
     <41 (cont.)                   regalloc  40458304 (-12140768)  19256 (+0) 
    <0 (cont.)                    (outside)  40458304 (+0)        19256 (+0) 
     >75                      blockOrdering  40458304 (+0)        19268 (+12) 
    <0 (cont.)                    (outside)  40458304 (+0)        19268 (+0) 
     >76                           peephole  40491032 (+32728)    19332 (+64) 
    <0 (cont.)                    (outside)  40491032 (+0)        19332 (+0) 
     >77                             output  40491032 (+0)        19336 (+4) 
      >78                  shorten branches  40949504 (+458472)   19239 (-97) 
     <77 (cont.)                     output  40949504 (+0)        19240 (+1)          significant temporary peak: 58817816 (+17868312)
      >79                        bldOopMaps  48294864 (+7345360)  19240 (+0) 
     <77 (cont.)                     output  48294864 (+0)        19240 (+0) 
      >80                       fill buffer  50635256 (+2340392)  19574 (+334) 
     <77 (cont.)                     output  50635256 (+0)        19574 (+0) 
      >81                      install_code  50635256 (+0)        19574 (+0) 
     <77 (cont.)                     output  50634272 (-984)      19574 (+0) 
    <0 (cont.)                    (outside)   2225624 (-48408648)      0 (-19574) 


The timeline shows the individual phases in the order in which they were executed. The left side is the tree of possibly nested TracePhase scopes. Every phase execution (since a phase can run multiple times) now has a unique phase sequence number. The tree shows those phase sequence numbers, and if a child phase ends, you can see that we are back in the outer phase again ("cont."). Behind that, we see the phase name, allocations made during that phase (Bytes), and the number of nodes allocated. If the phase caused a large temporary spike, it shows up as a "significant temporary peak".

Here you can find a full printout of this information on a run of springboot petclinic with `-XX:CompileCommand=memstat,*.*` via `jcmd spring Compiler.memory verbose`: https://gist.github.com/tstuefe/9d00e7129d4cdf5d1dbc294a80cbe4ed

----

We also now print more detailed information if the JVM runs against a MemLimit and crashes (option `-XX:CompileCommand=memlimit`). Note that we run with a memlimit of 1GB by default in debug JVMs, and we already found a couple of footprint issues with this setting. See an example of a generated hs-err file here: https://gist.github.com/tstuefe/777ecd68b313097a8e9020ac9fea239a

----

Performance costs: Not really much to tell here; we only do a tiny bit more work now per arena chunk allocation and after the compilation ended, but nothing crazy. Nevertheless, I tested before and after this patch with SpecJBB, nothing rose above background noise.

Footprint costs: The new information causes the per-compilation data to be a lot more bulky. That is why I reduced the information stored long-term: we now only store the 32 most expensive compilations. To see the cost of every compilation in its gory details, use the `-XX:CompileCommand=memstat,*.*,print` option. Of course, you can always reduce the scope of your tracking, e.g. limit it to a certain class only.

---

Tests:
- I tested manually on x64 Linux. GHAs ran (including the new tests).
- Tests at SAP are green

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

Commit messages:
 - more code grooming and comments
 - grooming
 - wip
 - Improved compiler memory statistics

Changes: https://git.openjdk.org/jdk/pull/23530/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344009
  Stats: 1753 lines in 28 files changed: 1187 ins; 237 del; 329 mod
  Patch: https://git.openjdk.org/jdk/pull/23530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23530/head:pull/23530

PR: https://git.openjdk.org/jdk/pull/23530

From kvn at openjdk.org  Thu Feb 13 17:05:04 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 17:05:04 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v7]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <5LGcbNB2_MigrbHGKV3CY8e6z-1iioFUuiSvTU8-lNY=.af273d17-6ab5-4b12-ae41-e6900494b5ee@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Update SA based on comments
 - Merge branch 'master' into 8349088
 - Fix Zero VM build
 - Fix Minimal and Zero VM builds once more
 - Fix Minimal and Zero VM builds again
 - Add CodeBlob proxy vtable
 - Fix Zero and Minimal VM builds
 - 8349088: De-virtualize Codeblob and nmethod

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/b09ddce6..515495b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=05-06

  Stats: 11482 lines in 618 files changed: 7914 ins; 1738 del; 1830 mod
  Patch: https://git.openjdk.org/jdk/pull/23533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533

PR: https://git.openjdk.org/jdk/pull/23533

From kvn at openjdk.org  Thu Feb 13 17:05:05 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 17:05:05 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <vn5PGBP9fcajrfw0rRxo6CRMOKRZsUEzsremVe7X0qQ=.ff23c214-5599-49fb-9732-75e4df74c819@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
 <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com>
 <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com>
 <vn5PGBP9fcajrfw0rRxo6CRMOKRZsUEzsremVe7X0qQ=.ff23c214-5599-49fb-9732-75e4df74c819@github.com>
Message-ID: <Iu7pFTUKNy7wzzBWDf_JQgA5UdI-Vd5n_RlbsEbOmtk=.3280d691-9c26-4393-bfdc-c4fb30b03f35@github.com>

On Thu, 13 Feb 2025 05:14:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Example please.
>
> static Class wrapperClasses = new Class[Number_Of_Kinds];
>     wrapperClasses[NMethodKind] = NMethodBlob.class;
>     wrapperClasses[BufferKind] = BufferBopb.class;
>     ...;
>     wrapperClasses[SafepointKind] = SafepointBlob.class;
> 
> 
> 
>     CodeBlob cb = new CodeBlob(addr);
>     return wrapperClasses[cb.getKind()];

Done.

>> I don't think we need it - the caller `CodeCache.createCodeBlobWrapper()` will throw `RuntimeException` when `null` is returned.
>
> I guess my real question is whether or not it can be considered normal behavior to return null. It seems it should never happen, which is why I was suggesting an assert.

With your suggested `wrapperClasses[]` we will get OOB exception. No need separate assert.

>> `UncommonTrapKind` and `ExceptionKind` are not initialized for Client VM because corresponding `CodeBlobKind` values are not defined. See `CodeBlob.initialize()`.
>> Their not initialized value will be 0 which matches `CodeBlobKind::None` value. Returning true in such case will be incorrect.
>
> Ok. Leaving UncommonTrapKind and ExceptionKind uninitialized seems a bit error prone. Perhaps they can be given some sort of INVALID value.

Done. Initialized them to `Number_Of_Kinds + 1`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954886028
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954890522
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954891616

From kvn at openjdk.org  Thu Feb 13 17:14:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 17:14:59 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  rename SA argument

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/515495b2..61fdee68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/23533

From kvn at openjdk.org  Thu Feb 13 17:14:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 17:14:59 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <vn5PGBP9fcajrfw0rRxo6CRMOKRZsUEzsremVe7X0qQ=.ff23c214-5599-49fb-9732-75e4df74c819@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
 <070Dz3l6A_ZT20jprInpMdpeqE3gogKAmmpnCprr4j0=.3b4804dc-02d7-4aa6-af42-7ef076d4fe0d@github.com>
 <8VFudK82JuBbjj_s74lDlHd1TWurW8uiBbw2DutA-PU=.ec26075e-89ad-4caf-ae3f-f50e5407a5f6@github.com>
 <vn5PGBP9fcajrfw0rRxo6CRMOKRZsUEzsremVe7X0qQ=.ff23c214-5599-49fb-9732-75e4df74c819@github.com>
Message-ID: <II4rbWyPgglWU4xZpfSS44PwgMpGPvIKPzZS9rL1MiA=.e6136557-86f3-4053-abbf-ddf72e9d719a@github.com>

On Thu, 13 Feb 2025 05:19:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> `cbPc` with comment explaining that it could be inside code blob.
>
> That sounds fine.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954906986

From cjplummer at openjdk.org  Thu Feb 13 17:14:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Feb 2025 17:14:59 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <zH9gxmYS4fhlJiI1mVHPOZXN_5f6_reQDlPv-mBJGKw=.ea3686e7-f7ad-4811-8609-05befc856dde@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
 <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>
 <MuWo0UbHjeatHRYvdW2o5IuYS99xCt9Cx4tcuyd7YLI=.347b62cf-16ad-4f24-aaa0-db044acca1f8@github.com>
 <ikNjrWuT83NiylLufeiZausKN4JHJaGXowZ5CMOhMTg=.ca4265f3-3608-40ee-8596-f12148a03ecd@github.com>
 <zH9gxmYS4fhlJiI1mVHPOZXN_5f6_reQDlPv-mBJGKw=.ea3686e7-f7ad-4811-8609-05befc856dde@github.com>
Message-ID: <TXDo104cgPVsZyBlN2XxgMwEBWyW7cw1OMqcZRP-Pnw=.2082c207-2f2d-4bf6-89cb-27b388eb2b94@github.com>

On Mon, 10 Feb 2025 16:57:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> What is the reason for switching from the virtualConstructor/hashMap approach to using getClassFor()? The hashmap is the model for JavaThread, MetaData, and CollectedHeap subtypes.
>> 
>> I don't need any more mapping from CodeBlob class to corresponding virtual table name which does not exist anymore. `CodeBlob::_kind` field's value is used to determine which class should be used.
>> 
>> I think `hashMap` is overkill here. I can construct array `Class<?> cbClasses[]` and use `cbClasses[CodeBlob::_kind]` instead of `if/else` in `getClassFor`. But I would still need to check for unknown value of `CodeBlob::_kind` somehow.
>
>> impact on things like the "findpc" functionality
> 
> Do you mean `findpc()` function in VM which is used in debugger? Nothing should be changed for it.
> It calls `os::print_location()` which calls `CodeBlob::dump_for_addr(addr, st, verbose);`:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/os.cpp#L1278

Actually I was referring to the clhsdb findpc command, which uses PointerFinder, but actually that should be ok because it special cases the codecache and knows how to find CodeBlobs in it. It's the clhsdb "inspect" command that will no longer be able to identify the type for an address that points to the start of a CodeBlob. This is true of any address that points to the start of a hotspot C++ object that does not have a vtable, or is not declared in vmstructs. So it's not a new issue, but is just adding more types to the list that "inspect" won't figure out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1954906641

From jrose at openjdk.org  Thu Feb 13 17:25:13 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 13 Feb 2025 17:25:13 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <nr8I_5uRgl9CgLWFXyq754zgqih9UQkkpOEVcjYqt5k=.eb46380c-3050-47c3-974a-bf5631996c1a@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

One related idea:  The Vptr classes seem to be regular enough to be templated.  That is, one class body, instantiated with a template argument for each code blob type (and probably another for the enum).  That would remove some of the distracting per-class boilerplate.  Something like:


template<typename CB_T, CodeBlob::Kind Tkind>
class Vptr_Impl : public Vptr {
  override void print_on(const CodeBlob* instance, outputStream* st) const {
    assert(instance->kind() == Tkind, "sanity");
    ((const CB_T*)instance)->print_on_impl(st);
  }
  ?
  override bool assert_sane(cosnt CodeBlob* instance) {
     assert(instance->kind() == Tkind, "");
     return true;
  }
};

class CodeBlob {
  public:
  final Vptr* vptr() const {
    Vptr* vptr = vptr_array[_kind];
    assert(vptr->assert_sant(this), "correct array element");
    return vptr;
  }
  final void print_on(outputStream* st) const {
    vptr()->print_on(this, st);
  }
};


Then:


const Vptr* array[] = {
  &Vptr_Impl<CodeBlob, CodeBlobKind>(),
  ...
  &Vptr_Impl<UncommonTrapBlob, UncommonTrapKind>(),
  ...
};


The array could be filled by a macro that tracks the enum members; I like that as a small job for macros (no code in it).

Then:


class UncommonTrapBlob : public OtherBlob {
  protected:  // impl "M" method is not public
  void print_on_impl(outputStream* st) const {
    OtherBlob::print_on_impl(st);
    st->print("my field = %d", _my_field);
  }
  // Vptr needs to call impl method
  friend class Vptr_Impl;  // this might break down, so make it all public in the end
};


I don't see any reason the Vptr subclasses need to be related in any more detail as subs or supers.

Well, C++ is a bag of surprises, so there are probably several reasons the above sketch is wrong.  But something like it might add a little more readability and predictability to the code.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657274388

From kvn at openjdk.org  Thu Feb 13 17:29:14 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 17:29:14 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <nr8I_5uRgl9CgLWFXyq754zgqih9UQkkpOEVcjYqt5k=.eb46380c-3050-47c3-974a-bf5631996c1a@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
 <nr8I_5uRgl9CgLWFXyq754zgqih9UQkkpOEVcjYqt5k=.eb46380c-3050-47c3-974a-bf5631996c1a@github.com>
Message-ID: <hWjwtUyTPwZ-YArpxuZUF1Fq-bBruELG57kWULIgIgY=.73f5e444-1695-4f9e-ade9-af1cb5d206f4@github.com>

On Thu, 13 Feb 2025 17:22:18 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename SA argument
>
> One related idea:  The Vptr classes seem to be regular enough to be templated.  That is, one class body, instantiated with a template argument for each code blob type (and probably another for the enum).  That would remove some of the distracting per-class boilerplate.  Something like:
> 
> 
> template<typename CB_T, CodeBlob::Kind Tkind>
> class Vptr_Impl : public Vptr {
>   override void print_on(const CodeBlob* instance, outputStream* st) const {
>     assert(instance->kind() == Tkind, "sanity");
>     ((const CB_T*)instance)->print_on_impl(st);
>   }
>   ?
>   override bool assert_sane(cosnt CodeBlob* instance) {
>      assert(instance->kind() == Tkind, "");
>      return true;
>   }
> };
> 
> class CodeBlob {
>   public:
>   final Vptr* vptr() const {
>     Vptr* vptr = vptr_array[_kind];
>     assert(vptr->assert_sant(this), "correct array element");
>     return vptr;
>   }
>   final void print_on(outputStream* st) const {
>     vptr()->print_on(this, st);
>   }
> };
> 
> 
> Then:
> 
> 
> const Vptr* array[] = {
>   &Vptr_Impl<CodeBlob, CodeBlobKind>(),
>   ...
>   &Vptr_Impl<UncommonTrapBlob, UncommonTrapKind>(),
>   ...
> };
> 
> 
> The array could be filled by a macro that tracks the enum members; I like that as a small job for macros (no code in it).
> 
> Then:
> 
> 
> class UncommonTrapBlob : public OtherBlob {
>   protected:  // impl "M" method is not public
>   void print_on_impl(outputStream* st) const {
>     OtherBlob::print_on_impl(st);
>     st->print("my field = %d", _my_field);
>   }
>   // Vptr needs to call impl method
>   friend class Vptr_Impl;  // this might break down, so make it all public in the end
> };
> 
> 
> I don't see any reason the Vptr subclasses need to be related in any more detail as subs or supers.
> 
> Well, C++ is a bag of surprises, so there are probably several reasons the above sketch is wrong.  But something like it might add a little more readability and predictability to the code.

Thank you, @rose00 and @xmas92, for review and suggestions.

Let me say it first - printing code for code blobs and nmethod is big mess. It requires separate big change to clean it up.
For example, I have to go through CodeBlob's virtual dispatch `print_value_on_v()` for nmethod because some sets of `nmethod::print*()` are defined only in debug VM: [nmethod.hpp#L919](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/nmethod.hpp#L919)

Then `nmethod` has other mess which requires C++ trickery because it does not follow print API in CodeBlob:

  void print(outputStream* st) const;
  // need to re-define this from CodeBlob else the overload hides it
  void print_on(outputStream* st) const override { CodeBlob::print_on(st); }
  void print_on(outputStream* st, const char* msg) const;

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657282969

From kvn at openjdk.org  Thu Feb 13 17:37:19 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 17:37:19 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <kvipwhHTRWnwE_lU_KL3RxkwOHglyBGfkq7C-07hkfs=.dd12213b-9c87-48fe-9a50-7437f166c7f1@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

Saying that, I agree that I need to add comments explaining printing API and how Vptr class will work.
I will work on @xmas92 suggestions and look on using `_impl`.
I will try to look on templates @rose00 suggested but I don't want to complicate code for just for few print methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657303967

From kvn at openjdk.org  Thu Feb 13 18:04:17 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Feb 2025 18:04:17 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <3RrosS3Q-iEBqaD4hVGMfjY2hDGLqwWwSUqgT0Za1k4=.1e32f3f0-6677-4082-b100-ce9b4603ec80@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

> AFAICT `print_value_on` is unreachable 

It is reachable in product VM when `print_value_on_v()` is called for `nmethod` which does not have `print_value_on()` in product VM. Which can be solved by adding simple `nmethod::print_value_on()` for product VM but it will change current behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2657354310

From cjplummer at openjdk.org  Thu Feb 13 18:28:18 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Feb 2025 18:28:18 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
 <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
 <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>
Message-ID: <BRX7t2fTbaf1gwc8pLqeLHKAPnMTmaCOO4So8aNDAcA=.4e92635f-7c87-4380-8f5f-26710a3439ee@github.com>

On Thu, 13 Feb 2025 09:08:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Btw what is also interesting is LTO optimization ; with gcc this has high optimization and for some libs quite large size reduction because at link time it can remove/rearrange quite a lot of code leading to smaller libs .
> But currently we have LTO support only for hotspot.

LTO support was added for minimal VM, which doesn't support JVMTI and therefore does not support the debug agent, so that's probably why support for it was never added to the debug agent. I thought it was added for some of the libs though, like libjava.so, but I could be wrong.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2657410094

From cjplummer at openjdk.org  Thu Feb 13 19:31:15 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 13 Feb 2025 19:31:15 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <DygSEY7jGRAZgDhL_sxRitod87ENPG5ysSC3i-kJ0bY=.2cb646ca-6f66-4ace-aec9-384b8ef7cb15@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 97:

> 95:   // cbAddr - address of a code blob
> 96:   // cbPC   - address inside of a code blob
> 97:   public CodeBlob createCodeBlobWrapper(Address cbAddr, Address cbPC) {

Can you change findBlobUnsafe() above also? That's where the naming problem originated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955098013

From dlong at openjdk.org  Thu Feb 13 22:50:17 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 13 Feb 2025 22:50:17 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <ClsVckm4m2CbI-340xWXM9eq8swOEGjejA7-jhIm5CA=.6f295219-6198-4e5a-af0a-474e763cc8c3@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/c1/Runtime1.java line 65:

> 63:   public CodeBlob blobFor(int id) {
> 64:     Address blobAddr = blobsField.getStaticFieldAddress().getAddressAt(id * VM.getVM().getAddressSize());
> 65:     return VM.getVM().getCodeCache().createCodeBlobWrapper(blobAddr);

We don't need to change all the callers if we keep a 1-arg version of createCodeBlobWrapper():

public CodeBlob createCodeBlobWrapper(Address codeBlobAddr) {
    return createCodeBlobWrapper(codeBlobAddr, codeBlobAddr);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955316582

From dlong at openjdk.org  Thu Feb 13 23:04:17 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 13 Feb 2025 23:04:17 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <UIDt7b3LS2ZVfhQFiMj41t_A0e4cnTnIOD5TViBMv5M=.68fc6999-e9e2-4ede-9cf6-b4f485f14972@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

src/hotspot/share/compiler/oopMap.cpp line 567:

> 565:   fr->print_on(tty);
> 566:   tty->print("     ");
> 567:   cb->print_value_on(tty);  tty->cr();

We could minimize the number of files changed if we keep print_value_on() for compatibility:

void print_value_on(outputStream* st) const { print_value_on_v(st); }

src/hotspot/share/runtime/vframe.inline.hpp line 178:

> 176:                   INTPTR_FORMAT " not found or invalid at %d",
> 177:                   p2i(_frame.pc()), decode_offset);
> 178:       nm()->print_on_v(&ss);

I suggest removing _v suffix to reduce changes and match existing naming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955325657
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955327438

From dlong at openjdk.org  Fri Feb 14 00:11:16 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 14 Feb 2025 00:11:16 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <kjmAahvfyo5d63hmg3SqUtvqBNFrY3gnzYVeTvm98PY=.3c62b35a-bda8-462c-aa01-30db76aa9606@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

src/hotspot/share/code/codeBlob.hpp line 669:

> 667: 
> 668:   jobject  receiver()          { return _receiver; }
> 669:   ByteSize frame_data_offset() { return _frame_data_offset; }

`frame_data_offset()` seems to be unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1955373697

From dlong at openjdk.org  Fri Feb 14 00:17:14 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 14 Feb 2025 00:17:14 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <MwRthjcW9295noDiEJ0TukT8n93H07jFK6PXcd7IUyI=.d1d72e9d-0e20-4a1c-b8df-892d3177a759@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

HotSpot C++ changes look good.  I skipped SA changes.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2616477660

From stuefe at openjdk.org  Fri Feb 14 06:42:09 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Feb 2025 06:42:09 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <6IATWzJgb5zFVmIcXhH3XFoVOeU1RxinjTPIvhm4vL0=.f2d9e94d-e0f9-40ad-b843-25defa3c3b09@github.com>

On Sat, 8 Feb 2025 06:56:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Some additional technical information about how this statistic works:

The JVM informs the statistics about the following events:

A) When a compilation starts

B) When a compilation ends.

C) When a new compilation phase starts. That can happen in nested form.

D) When a compilation phase ends.

E) Whenever an arena grows a new chunk (regardless of whether this was a cached chunk from the chunk pool or a newly allocated chunk).

F) When an arena sheds chunks - either by rolling back to a previous ResourceMark or because the arena itself gets deleted.

During compilation (between (A) and (B)), we keep the statistic state for this compilation in an `ArenaStatCounter` object that is attached to the current compiler thread.

When a new compilation phase starts (C), we push the phase info onto a `PhaseInfoStack`. When a phase ends, we pop that information.

When we are informed of a new chunk allocation (E), we:
  - Set a stamp in the chunk header to mark it as being owned by this phase and this arena type
  - In the `ArenaStatCounter` object, we adjust global counters and counters in a two-dimensional table (`ArenaCounterTable`) that keeps counters per arena tag and compilation phase.
  - If total memory consumption for this compilation reaches a new peak, we take a snapshot of all counters as peak state.
  - We also handle `MemLimit` violations here: if `-XX:CompileCommand=memlimit...` was enabled, and the total footprint of the compilation surpasses that limit, we either end the JVM with a fatal error or we bail on the compilation. That depends on the sub-option given to the command.

When informed of a chunk deletion (F), we:
  - extract the stamp from the chunk header to know what phase/arena type this deallocation accounts to
  - we then adjust the counters for that phase/arena type in the `ArenaCounterTable`

When a compilation phase ends (D), we adjust the "footprint timeline". The footprint timeline - `FootprintTimeline` - is a one-dimensional buffer of (phase info, counter) tupels. It represents the "flattened out" form of the phase invocation tree: an invocation of a child phase nested in a parent phase "interrupts" the parent phase, and when the child phase ends, the parent phase is "restarted" as a new entry in the timeline. For example, let's say we execute phase "optimizer", and inside that, call the phase "iterGVN" and then "incrementalInline". Between these two phases, we allocate from resource area. The invocation tree looks like this:


> optimizer  1024 KB
     > iterGVN  1032 KB
< optimizer (cont.) 1032 KB + 1MB resource arena
     > incrementalInline 1032 KB + 1MB resource arena
< optimizer (cont.) 1032 KB + 1MB resource arena


The flattened-out footprint timeline will look somewhat like this:


Phase Sequence Number | Phase Name       | Footprint
5                       optimizer          1024 KB
6                       iterGVN            1032 KB
5                       optimizer          1032 KB + 1MB
7                       incrementalInline  1032 KB + 1MB
5                       optimizer          1032 KB + 1MB


Finally, when the compilation ends, we print out the statistic for it (if the suboption `print` was given with `-XX:CompileCommand=memstat`). We also save a copy of the counters to a global table that contains the N most expensive compilations. That table will be printed when one uses `jcmd <pid> Compiler.memory`. We also print it into the hs-err file.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2658400920

From mbaesken at openjdk.org  Fri Feb 14 08:34:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Feb 2025 08:34:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <BRX7t2fTbaf1gwc8pLqeLHKAPnMTmaCOO4So8aNDAcA=.4e92635f-7c87-4380-8f5f-26710a3439ee@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
 <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
 <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>
 <BRX7t2fTbaf1gwc8pLqeLHKAPnMTmaCOO4So8aNDAcA=.4e92635f-7c87-4380-8f5f-26710a3439ee@github.com>
Message-ID: <fvPNRfvJn8OnabiCVdc5QD19LWqdMsQqhMsvQ7an3JU=.1bf945fd-6061-4a2a-b709-f0ac7ae1452c@github.com>

On Thu, 13 Feb 2025 18:25:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > Btw what is also interesting is LTO optimization ; with gcc this has high optimization and for some libs quite large size reduction because at link time it can remove/rearrange quite a lot of code leading to smaller libs .
> > But currently we have LTO support only for hotspot.
> 
> LTO support was added for minimal VM, which doesn't support JVMTI and therefore does not support the debug agent, so that's probably why support for it was never added to the debug agent. I thought it was added for some of the libs though, like libjava.so, but I could be wrong.

The jvm feature link time optimization can be configured for a 'normal' JVM, this has afaik nothing to do with a minimal JVM .
Currently this configure option only changes the compile and link flags of libjvm so the compile and link flags of the JDK native libs are not changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2658593001

From rcastanedalo at openjdk.org  Fri Feb 14 08:58:09 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 14 Feb 2025 08:58:09 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>

On Sat, 8 Feb 2025 06:56:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Hi Thomas, this looks very useful, thanks! I will run some Oracle-internal functional and performance testing and come back with the results next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2658651169

From rcastanedalo at openjdk.org  Fri Feb 14 09:13:16 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 14 Feb 2025 09:13:16 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <RqrK2zjSjUOEdgxuAfQmkx2pvHJz278l2jclLIig19E=.5c581116-26ad-4c93-82c4-b6a36aac15ca@github.com>

On Sat, 8 Feb 2025 06:56:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

src/hotspot/share/runtime/handles.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 1997, 2024, Oracle and/or its affiliates. All rights reserved.

Nit: unnecessary copyright header change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1955794509

From stuefe at openjdk.org  Fri Feb 14 09:34:18 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Feb 2025 09:34:18 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v2]
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <feRzRUGP_T89ZWa_OXeG1iEtO4PYk2c7JAirkG1hS6g=.2fcc2820-ac2b-4614-98c2-c34ecef7211f@github.com>

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  revert unnecessary copyright change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23530/files
  - new: https://git.openjdk.org/jdk/pull/23530/files/89fce6a6..4f426160

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/23530

From cjplummer at openjdk.org  Fri Feb 14 17:19:15 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 14 Feb 2025 17:19:15 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <fvPNRfvJn8OnabiCVdc5QD19LWqdMsQqhMsvQ7an3JU=.1bf945fd-6061-4a2a-b709-f0ac7ae1452c@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <GLwo1ePPJs-QWxrwIitOakRqsaFupC4diQbwtFsg-hU=.a8fcea6f-9550-4660-b95c-1e59ce51dcbd@github.com>
 <i-mFesjXkUJTeFIVqfIkZcN7z3HkikoapJkteheXVcg=.bbfde91a-c35c-46ae-9b82-a33f9e5ef277@github.com>
 <_wmfxFfVII4zS5c7du-5x1gOR0zzxXl0Xd3npHj2EFc=.551038e6-1ac7-4568-9244-fceff7862376@github.com>
 <BRX7t2fTbaf1gwc8pLqeLHKAPnMTmaCOO4So8aNDAcA=.4e92635f-7c87-4380-8f5f-26710a3439ee@github.com>
 <fvPNRfvJn8OnabiCVdc5QD19LWqdMsQqhMsvQ7an3JU=.1bf945fd-6061-4a2a-b709-f0ac7ae1452c@github.com>
Message-ID: <MSZfQ4mczlPT9UMgnKVgAmps0-mXVxsgDQipONR2ZK0=.dc2b08c5-5b02-4c58-9266-fab3cc92b6d9@github.com>

On Fri, 14 Feb 2025 08:32:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The jvm feature link time optimization can be configured for a 'normal' JVM, this has afaik nothing to do with a minimal JVM .
> Currently this configure option only changes the compile and link flags of libjvm so the compile and link flags of the JDK native libs are not changed.

Yes, I understand that. It was introduced to support minimal VM, but like all the minimal VM optional support, it was made to be something that could be configured even when not building minimal VM. For example JVMTI is an optional JVM feature. That was done for minmal VM, but you can choose to not include JVMTI when you configure for any build.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2659870077

From ccheung at openjdk.org  Fri Feb 14 19:21:32 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 14 Feb 2025 19:21:32 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v2]
In-Reply-To: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
Message-ID: <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>

> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
> 
> Passed tiers 1 - 5 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam and @ashu-mehra comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23476/files
  - new: https://git.openjdk.org/jdk/pull/23476/files/816ae7ea..01238742

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=00-01

  Stats: 62 lines in 5 files changed: 12 ins; 17 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/23476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23476/head:pull/23476

PR: https://git.openjdk.org/jdk/pull/23476

From ccheung at openjdk.org  Fri Feb 14 19:21:32 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 14 Feb 2025 19:21:32 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v2]
In-Reply-To: <Ee1Jz1yzCyZLga2lB1yhfGzcyn_JkOHiLI8Q5nJLruA=.b2f03607-1811-4548-bef6-9abfb0fdb44b@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <Ee1Jz1yzCyZLga2lB1yhfGzcyn_JkOHiLI8Q5nJLruA=.b2f03607-1811-4548-bef6-9abfb0fdb44b@github.com>
Message-ID: <YdNs_ZQt4W5J_HX1KQWLBBGQDiTC3nwdW2rkdZblKmE=.0287cfcb-0ebd-419b-9a16-9430cc7dade4@github.com>

On Tue, 11 Feb 2025 05:25:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam and @ashu-mehra comment
>
> src/hotspot/share/cds/aotCodeSource.cpp line 133:
> 
>> 131: 
>> 132: // AllCodeSourceStreams is used to iterate over all the code sources that
>> 133: // are available to the application from -Xbootclasspath, -classpath and --module-path
> 
> Consider adding this comment:
> 
> // When creating an AOT cache, we store the contents from AllCodeSourceStreams
> // into an array of AOTCodeSources. See AOTCodeSourceConfig::dumptime_init_helper().
> // When loading the AOT cache in a production run, we compare the contents of the
> // stored AOTCodeSources against the current AllCodeSourceStreams to determine whether
> // the AOT cache is compatible with the current JVM. See AOTCodeSourceConfig::validate().

Added the comment.

> src/hotspot/share/cds/aotCodeSource.hpp line 126:
> 
>> 124: // Non-existent entries are recored during AOTCache creation. Those non-existent entries
>> 125: // must not exist during runtime.
>> 126: //
> 
> Typos:
> - "subjected to AOTCodeSourceConfig::validate()" -- the function has two parameters, but we can omit them in this comment
> - "validation is performed on *the* AOTCodeSources"
> - "during AOTCache creation *are* the same"
> - "on-existent entries are *recorded*"

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1956613731
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1956613683

From ccheung at openjdk.org  Fri Feb 14 19:21:33 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 14 Feb 2025 19:21:33 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v2]
In-Reply-To: <8yqgZ4ffmEyui_CyUR9lS-2MV4ONfzSaA-pMz-VvDMA=.e92da2b8-cfc5-4ef9-ab33-9d14ca02a2f8@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <8yqgZ4ffmEyui_CyUR9lS-2MV4ONfzSaA-pMz-VvDMA=.e92da2b8-cfc5-4ef9-ab33-9d14ca02a2f8@github.com>
Message-ID: <AtH17RlNlFlaoFnO80nXWlvxSIhL1_7Ccojpj3vJ_Lc=.ff20fdcf-376d-4c2b-9584-0fc9a8ac6775@github.com>

On Thu, 13 Feb 2025 03:55:50 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam and @ashu-mehra comment
>
> src/hotspot/share/cds/aotCodeSource.cpp line 762:
> 
>> 760:   }
>> 761: 
>> 762:   if (is_boot_classpath && runtime_css.has_next() && (need_to_check_app_classpath() || num_module_paths() > 0)) {
> 
> I am not sure I get what this block is for. Is it for the case where runtime boot cp has more entries than the dumptime boot cp, and it is checking if the extra entries really exist or they are just empty? If so, then `check_paths_existence` should only be checking the extra entries in the boot cp, not all of them.
> 
> Can you please explain this and probably add a comment as well to describe what this block is for.

I added some comment:

  // Check if the runtime boot classpath has more entries than the one stored in the archive and if the app classpath
  // or the module path requires validation.
  if (is_boot_classpath && runtime_css.has_next() && (need_to_check_app_classpath() || num_module_paths() > 0)) {
    // the check passes if all the extra runtime boot classpath entries are non-existent
    if (check_paths_existence(runtime_css)) {
      log_warning(cds)("boot classpath is longer than expected");
      return false;
    }
  }

Also fixed the `check_paths_existence()` method so it only checks the extra entries.

> src/hotspot/share/cds/aotCodeSource.cpp line 894:
> 
>> 892: // matched exactly.
>> 893: bool AOTCodeSourceConfig::need_lcp_match(AllCodeSourceStreams& all_css) const {
>> 894:   if (!need_lcp_match_helper(boot_start(), boot_end(), all_css.boot_cp()) ||
> 
> Can we reverse these conditions to make it easier to read?
> 
> 
>   if (need_lcp_match_helper(boot_start(), boot_end(), all_css.boot_cp()) &&
>       need_lcp_match_helper(app_start(), app_end(), all_css.app_cp())) {
>     return true;
>   } else {
>     return false;
>   }

Done.

> src/hotspot/share/cds/aotCodeSource.cpp line 903:
> 
>> 901: 
>> 902: bool AOTCodeSourceConfig::need_lcp_match_helper(int start, int end, CodeSourceStream& css) const {
>> 903:   if (app_end() == boot_start()) {
> 
> I feel this block belongs to the caller `need_lcp_match`.

Fixed.

> src/hotspot/share/cds/aotCodeSource.hpp line 213:
> 
>> 211: 
>> 212:   // Common accessors
>> 213:   int boot_start()                       const { return 1; }
> 
> Can we rename these methods to something like boot_start() -> boot_cp_start_index().
> At the call site it makes it clear it is referring to the bootclasspath index, and not booting something :)

I renamed them as follows:

  // Common accessors
  int boot_cp_start_index()          const { return 1; }
  int boot_cp_end_index()            const { return _boot_classpath_end; }
  int app_cp_start_index()           const { return boot_cp_end_index(); }
  int app_cp_end_index()             const { return _app_classpath_end; }
  int module_path_start_index()      const { return app_cp_end_index(); }
  int module_path_end_index()        const { return _module_end; }

> src/hotspot/share/cds/aotCodeSource.hpp line 234:
> 
>> 232:   // Functions used only during dumptime
>> 233:   static void dumptime_init(TRAPS);
>> 234:   static size_t estimate_size_for_archive() {
> 
> This method doesn't seem to be in use. Can this be removed?

Removed. I also removed the `estimate_size_for_archive_helper()` method.

> src/hotspot/share/cds/filemap.cpp line 318:
> 
>> 316:   if (header()->has_full_module_graph() && has_extra_module_paths) {
>> 317:     CDSConfig::stop_using_optimized_module_handling();
>> 318:     log_info(cds)("optimized module handling: disabled because of extra module path(s) are specified");
> 
> typo: "disabled because ~of~ extra module path(s) are specified"

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1956614255
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1956614149
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1956614064
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1956613894
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1956613789
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1956614357

From cjplummer at openjdk.org  Fri Feb 14 19:43:22 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 14 Feb 2025 19:43:22 GMT
Subject: RFR: 8348347: Cleanup JavaThread subclass support in SA [v2]
In-Reply-To: <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
 <WA6iGna2l9PtX3uPlaCii7LvF654FODUAoS8IpZSdjE=.b9625dfc-5d47-4d2b-84ac-615e30648118@github.com>
Message-ID: <75ojIXJ_CBsMwBhgP9zuNTAy2PDUqwmksbEI71CrlM4=.36613ebb-fb05-43f3-93e8-57d997ecd8ea@github.com>

On Thu, 6 Feb 2025 22:44:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Cleanup SA JavaThread support. Details in first comment:
>> 
>> Testing:
>> - Tier1
>> - Tier2 svc
>> - Tier3
>> - Tier5 svc
>> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comments

Thanks for the review Serguei and Kevin!

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

PR Comment: https://git.openjdk.org/jdk/pull/23456#issuecomment-2660127117

From cjplummer at openjdk.org  Fri Feb 14 19:43:23 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 14 Feb 2025 19:43:23 GMT
Subject: Integrated: 8348347: Cleanup JavaThread subclass support in SA
In-Reply-To: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
References: <QGYNLQi0PV1Ws9nSOkNSMVFSZDwE2hox6Hi6aJU1tj4=.d2643a7a-814f-42ba-ae31-66408559b6df@github.com>
Message-ID: <NFKvsYEd77xZeZv1L0Kxce2TETcnYMC2ISoH6ofBWu4=.55790654-e288-4792-9285-838ab2175cd8@github.com>

On Wed, 5 Feb 2025 04:18:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Cleanup SA JavaThread support. Details in first comment:
> 
> Testing:
> - Tier1
> - Tier2 svc
> - Tier3
> - Tier5 svc
> - Local testing of debuggee using graal java compiler threads. Verified that the compiler threads shows up in jstack output if the property is set.

This pull request has now been integrated.

Changeset: b6443f6f
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6443f6ff96707f67552df41c01d18c193560223
Stats:     431 lines in 16 files changed: 62 ins; 334 del; 35 mod

8348347: Cleanup JavaThread subclass support in SA

Reviewed-by: kevinw, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/23456

From kvn at openjdk.org  Fri Feb 14 23:14:18 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Feb 2025 23:14:18 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
Message-ID: <v2d22ewwY2ILZHBAE6SnHqJXOHYTxNcTyeE08Cc2CIg=.37550622-993b-49f4-abd0-5bc5c4301444@github.com>

On Thu, 13 Feb 2025 17:14:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SA argument

I addressed most @xmas92 and @dean-long comments and working on avoid `_v` suffix

Thank you, Dean, for review.

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

PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2618707275
PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2660443983

From kvn at openjdk.org  Fri Feb 14 23:14:20 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Feb 2025 23:14:20 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v6]
In-Reply-To: <Z20zaowGEnlGq_wSYvZbz9jVb7CWBjb4MYOTpmXkJ0o=.6c6c608d-8694-4eb5-9ac6-45001a33b4d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <uUg8vIR1j_4I2P3UYRzZA0EU8z5qXmethIRmUl7VBmE=.2be2895c-126a-4f27-9061-816b7c63d5e1@github.com>
 <Z20zaowGEnlGq_wSYvZbz9jVb7CWBjb4MYOTpmXkJ0o=.6c6c608d-8694-4eb5-9ac6-45001a33b4d8@github.com>
Message-ID: <zjci1dX7BD_H8OUz0iVVbVij3E6vFGpka_YY3pS_2OI=.c93cfb4e-55d1-4c77-b4ce-e58503620dce@github.com>

On Thu, 13 Feb 2025 08:15:16 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Zero VM build
>
> src/hotspot/share/code/codeBlob.hpp line 140:
> 
>> 138:       instance->print_value_on_nv(st);
>> 139:     }
>> 140:   };
> 
> I wonder why the base class is not abstract. AFAICT `print_value_on` is unreachable and `print_on` is only used by `DeoptimizationBlob::Vptr` which also seems like a behavioural change, as before this patch calling `print_on` a `DeoptimizationBlob` object would dispatch to `SingletonBlob::print_on` not `CodeBlob::print_on`. 
> 
> Suggestion:
> 
>  struct Vptr {
>     virtual void print_on(const CodeBlob* instance, outputStream* st) const = 0;
>     virtual void print_value_on(const CodeBlob* instance, outputStream* st) const = 0;
>   };

done

> src/hotspot/share/code/codeBlob.hpp line 339:
> 
>> 337:   void print_value_on(outputStream* st) const;
>> 338: 
>> 339:   class Vptr : public CodeBlob::Vptr {
> 
> I wonder if these should share the same type hierarchy as tier container class. This would also solve the issueI noted in my other comment about not calling the correct `print_on`.
> Suggestion:
> 
>   class Vptr : public RuntimeBlob::Vptr {

Fixed

> src/hotspot/share/code/codeBlob.hpp line 427:
> 
>> 425:   void print_value_on(outputStream* st) const;
>> 426: 
>> 427:   class Vptr : public CodeBlob::Vptr {
> 
> Suggestion:
> 
>   class Vptr : public RuntimeBlob::Vptr {

Fixed

> src/hotspot/share/code/codeBlob.hpp line 467:
> 
>> 465:   void print_value_on(outputStream* st) const;
>> 466: 
>> 467:   class Vptr : public CodeBlob::Vptr {
> 
> Suggestion:
> 
>   class Vptr : public RuntimeBlob::Vptr {

Fixed

> src/hotspot/share/code/codeBlob.hpp line 553:
> 
>> 551:   void print_value_on(outputStream* st) const;
>> 552: 
>> 553:   class Vptr : public CodeBlob::Vptr {
> 
> This one specifically
> Suggestion:
> 
>   class Vptr : public SingletonBlob::Vptr {

fixed

> src/hotspot/share/code/codeBlob.hpp line 679:
> 
>> 677:   void print_value_on(outputStream* st) const;
>> 678: 
>> 679:   class Vptr : public CodeBlob::Vptr {
> 
> Suggestion:
> 
>   class Vptr : public RuntimeBlob::Vptr {

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956799673
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956801833
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956801994
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956802109
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956803039
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956827486

From kvn at openjdk.org  Fri Feb 14 23:14:22 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Feb 2025 23:14:22 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <kjmAahvfyo5d63hmg3SqUtvqBNFrY3gnzYVeTvm98PY=.3c62b35a-bda8-462c-aa01-30db76aa9606@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
 <kjmAahvfyo5d63hmg3SqUtvqBNFrY3gnzYVeTvm98PY=.3c62b35a-bda8-462c-aa01-30db76aa9606@github.com>
Message-ID: <_9qiqpCFRxCMY4nADw0lqrNuOZYIKUpeY_7FYyoQWC8=.78588553-bede-45b1-bf2d-5ad306b81e29@github.com>

On Fri, 14 Feb 2025 00:08:35 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename SA argument
>
> src/hotspot/share/code/codeBlob.hpp line 669:
> 
>> 667: 
>> 668:   jobject  receiver()          { return _receiver; }
>> 669:   ByteSize frame_data_offset() { return _frame_data_offset; }
> 
> `frame_data_offset()` seems to be unused.

removed

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/c1/Runtime1.java line 65:
> 
>> 63:   public CodeBlob blobFor(int id) {
>> 64:     Address blobAddr = blobsField.getStaticFieldAddress().getAddressAt(id * VM.getVM().getAddressSize());
>> 65:     return VM.getVM().getCodeCache().createCodeBlobWrapper(blobAddr);
> 
> We don't need to change all the callers if we keep a 1-arg version of createCodeBlobWrapper():
> 
> public CodeBlob createCodeBlobWrapper(Address codeBlobAddr) {
>     return createCodeBlobWrapper(codeBlobAddr, codeBlobAddr);
> }

This is the only one place where arguments are the same. In other two arguments are different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956672379
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956667806

From kvn at openjdk.org  Fri Feb 14 23:14:23 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Feb 2025 23:14:23 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <DygSEY7jGRAZgDhL_sxRitod87ENPG5ysSC3i-kJ0bY=.2cb646ca-6f66-4ace-aec9-384b8ef7cb15@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
 <DygSEY7jGRAZgDhL_sxRitod87ENPG5ysSC3i-kJ0bY=.2cb646ca-6f66-4ace-aec9-384b8ef7cb15@github.com>
Message-ID: <07aI9gwcVtc89Bte9DRQ6VwmCfhcBJJQlrXhxkRRgX0=.97d4a1cc-92a2-43dc-8516-2433eca67263@github.com>

On Thu, 13 Feb 2025 19:27:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename SA argument
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeCache.java line 97:
> 
>> 95:   // cbAddr - address of a code blob
>> 96:   // cbPC   - address inside of a code blob
>> 97:   public CodeBlob createCodeBlobWrapper(Address cbAddr, Address cbPC) {
> 
> Can you change findBlobUnsafe() above also? That's where the naming problem originated.

After some thoughts I think `PC` is not usually used by us.
I renamed `cbAddr` to `cbStart` and `cbPC`/`start` to `addr` in this whole file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956664966

From dlong at openjdk.org  Fri Feb 14 23:47:12 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 14 Feb 2025 23:47:12 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
Message-ID: <8JUfZWRWpAhYCG9qO7Jxfj5k6d1iUNpRdawRn-veiBQ=.4b70e450-14e5-429a-aa95-08599673afba@github.com>

On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 385:

> 383: 
> 384: HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
> 385:   if (!should_alloc_in_eden(size) || GCLocker::is_active()) {

I don't understand why we are checking is_active() here.  The value is not reliable if we aren't at a safepoint, and iterating over all threads seems expensive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1956881801

From kvn at openjdk.org  Sat Feb 15 02:08:20 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 15 Feb 2025 02:08:20 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v8]
In-Reply-To: <UIDt7b3LS2ZVfhQFiMj41t_A0e4cnTnIOD5TViBMv5M=.68fc6999-e9e2-4ede-9cf6-b4f485f14972@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <lefn8L1ulD5y9lN9rRQwhTkyziJN6-ZmImxIC9SVsfw=.46a2461a-99b0-45bc-b11d-609e076de019@github.com>
 <UIDt7b3LS2ZVfhQFiMj41t_A0e4cnTnIOD5TViBMv5M=.68fc6999-e9e2-4ede-9cf6-b4f485f14972@github.com>
Message-ID: <pX-b0gPP4MvfCgWorgLDtLD-UkHdo-ryi0yaNPn6n9s=.96ca16be-a859-4a17-b80d-f0aecbbf6170@github.com>

On Thu, 13 Feb 2025 23:01:24 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename SA argument
>
> src/hotspot/share/runtime/vframe.inline.hpp line 178:
> 
>> 176:                   INTPTR_FORMAT " not found or invalid at %d",
>> 177:                   p2i(_frame.pc()), decode_offset);
>> 178:       nm()->print_on_v(&ss);
> 
> I suggest removing _v suffix to reduce changes and match existing naming.

Done. Testing now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1956985708

From kvn at openjdk.org  Sat Feb 15 06:13:57 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 15 Feb 2025 06:13:57 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v9]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <bOOpa8SBoYO5qmGYp0e7x01gp6uE6OjiXZ8-wjz9_DI=.27bac79d-4d10-490c-9cd8-8df3d090fe7b@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/61fdee68..89a383e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=07-08

  Stats: 115 lines in 12 files changed: 7 ins; 7 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/23533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23533/head:pull/23533

PR: https://git.openjdk.org/jdk/pull/23533

From kvn at openjdk.org  Sat Feb 15 06:29:14 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 15 Feb 2025 06:29:14 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v9]
In-Reply-To: <bOOpa8SBoYO5qmGYp0e7x01gp6uE6OjiXZ8-wjz9_DI=.27bac79d-4d10-490c-9cd8-8df3d090fe7b@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <bOOpa8SBoYO5qmGYp0e7x01gp6uE6OjiXZ8-wjz9_DI=.27bac79d-4d10-490c-9cd8-8df3d090fe7b@github.com>
Message-ID: <2aYXBHyZE83suQFtY_POyft2gbRwwF_Xf_qajA62Pgw=.1fe1143c-33c5-4e78-b691-3f85f176c598@github.com>

On Sat, 15 Feb 2025 06:13:57 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

I removed `_v` from `CodeBlob::print*_on(st)` methods to reduce scope of VM changes.  But I have to add `_impl` suffix to these methods in CodeBlob subclasses.

I renamed `nmethod::print_on(st, msg);` to `print_on_with_msg(at, msg) to avoid naming conflict C++ complains about. It cased change in `dependencyContext.cpp`.

I made `CodeBlob::Vptr` class abstract as suggested.

I added empty `Vptr` class to `RuntimeBlob` because it is referenced in subclasses and corrected extensions in sublcasses to avoid mistakes @xmas92 pointed.

I also did some arguments renaming in SA in `CodeCache.java` as requested.

Tier1-5 testing passed.

Ready for new round of reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2660770028

From kvn at openjdk.org  Sat Feb 15 06:34:56 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 15 Feb 2025 06:34:56 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10]
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <PLR4hd5rc20OFzfJxG7yDhph6PXNn6j1CJnvHI-OrI8=.7f019bc0-c1c4-4d68-8354-ca2567994784@github.com>

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Remove commented lines left by mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23533/files
  - new: https://git.openjdk.org/jdk/pull/23533/files/89a383e5..3fdf1c81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23533&range=08-09

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

PR: https://git.openjdk.org/jdk/pull/23533

From ayang at openjdk.org  Sat Feb 15 11:44:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 15 Feb 2025 11:44:44 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v3]
In-Reply-To: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
Message-ID: <ykFgVzd-uwQYcxFmbl379IvIMEmtePZPjINe_Q-cJZo=.c4f001c7-77ca-41e2-af32-5072e1899748@github.com>

> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
> 
> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
> 
> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
> 
> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into gclocker
 - review
 - Merge branch 'master' into gclocker
 - review
 - Merge branch 'master' into gclocker
 - gclocker

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23367/files
  - new: https://git.openjdk.org/jdk/pull/23367/files/1b6f908b..005087e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=01-02

  Stats: 18668 lines in 693 files changed: 10993 ins; 4307 del; 3368 mod
  Patch: https://git.openjdk.org/jdk/pull/23367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23367/head:pull/23367

PR: https://git.openjdk.org/jdk/pull/23367

From ayang at openjdk.org  Sat Feb 15 11:49:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 15 Feb 2025 11:49:13 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <8JUfZWRWpAhYCG9qO7Jxfj5k6d1iUNpRdawRn-veiBQ=.4b70e450-14e5-429a-aa95-08599673afba@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <8JUfZWRWpAhYCG9qO7Jxfj5k6d1iUNpRdawRn-veiBQ=.4b70e450-14e5-429a-aa95-08599673afba@github.com>
Message-ID: <VHVMrlJka1_oWLMJOB1OPsMWA3f8INwBy49lrz6f7y8=.3ccd4929-266d-4b3a-85c6-60c90e7c40ee@github.com>

On Fri, 14 Feb 2025 23:44:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Albert Mingkun Yang 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 gclocker
>>  - review
>>  - Merge branch 'master' into gclocker
>>  - gclocker
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 385:
> 
>> 383: 
>> 384: HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
>> 385:   if (!should_alloc_in_eden(size) || GCLocker::is_active()) {
> 
> I don't understand why we are checking is_active() here.  The value is not reliable if we aren't at a safepoint, and iterating over all threads seems expensive.

The intention is to avoid blocking java threads if possible, but there is no fundamental reason why it has be to this way. I have removed it for simpler (or less magical) code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1957098815

From ayang at openjdk.org  Sat Feb 15 11:52:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 15 Feb 2025 11:52:14 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <zAeXXZW_4kcwsb3KRuM3WtzNxLFg6hxLlGAZrjb5fVM=.4837c962-5da8-4509-86a9-ce9d55c10f53@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>
 <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>
 <zAeXXZW_4kcwsb3KRuM3WtzNxLFg6hxLlGAZrjb5fVM=.4837c962-5da8-4509-86a9-ce9d55c10f53@github.com>
Message-ID: <tjhqeB9WM0W5lW_zPBmRcWeUbnZHNIbGUVwAz5M2B2w=.c5846c0c-48dc-4ec7-8484-122ffc65b6da@github.com>

On Fri, 7 Feb 2025 06:43:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But in any case adding the atomic load to in_critical() is basically a no-op (loads are atomic) so no need to add a new API just to do that.

I have removed the new API, and switched to use the original `in_critical()`.

> I think that to get the correct "dekker duality" in this code you do need to have full fences between the stores and loads, not just a storeload barrier.

I have changed to `fence` for simpler reasoning. (In our codebase, the two have the same implementation, so perf should be the same.)

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2660886740

From aboldtch at openjdk.org  Mon Feb 17 06:41:18 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 17 Feb 2025 06:41:18 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10]
In-Reply-To: <PLR4hd5rc20OFzfJxG7yDhph6PXNn6j1CJnvHI-OrI8=.7f019bc0-c1c4-4d68-8354-ca2567994784@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <PLR4hd5rc20OFzfJxG7yDhph6PXNn6j1CJnvHI-OrI8=.7f019bc0-c1c4-4d68-8354-ca2567994784@github.com>
Message-ID: <UW6o1fVdNjYeif3nCIGQpZPvXasY40lIjBIczpsfY9I=.ad72b291-258f-4df1-b3ee-9a5326657db1@github.com>

On Sat, 15 Feb 2025 06:34:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove commented lines left by mistake

Not looked at the SA changes.

lgtm.

src/hotspot/share/code/codeBlob.hpp line 308:

> 306: 
> 307:   class Vptr : public CodeBlob::Vptr {
> 308:   };

Was this needed for some compiler? Or is it to be more explicit about the type hierarchy?

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2620128040
PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1957678232

From mbaesken at openjdk.org  Mon Feb 17 09:07:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Feb 2025 09:07:09 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <sCVQRKUH48CzjjJUgu4Av-2mbPPodY6-obTXCBcAaDI=.579f5a98-265c-47f4-9a5a-98cef76888a3@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

btw for libjdwp with lto enabled (have to modify the make settings because this is not supported out of the box) I get

1.8M	./lib/libjdwp.debuginfo
280K	./lib/libjdwp.so

This looks pretty good compared to HIGH or standard (LOW/NORM) settings.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2662470114

From kevinw at openjdk.org  Mon Feb 17 09:17:14 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Feb 2025 09:17:14 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v4]
In-Reply-To: <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
Message-ID: <CJjWwnTVcAs743BtUPrLKmmghA_YTwhT1lN8IbTXkCc=.60981038-bc72-41a7-a28e-f93c08fdd23c@github.com>

On Mon, 27 Jan 2025 19:41:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
>> 
>> Testing:
>> 
>> - [x] Tier1 CI
>> - [x] Tier2 CI svc testing
>> - [x] Tier3 CI svc testing
>> - [x] Tier5 CI svc testing
>> - [x] ran all svc test 10 times each on all supported platforms
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix white space errors.

src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 899:

> 897:     }
> 898: 
> 899:     if (step->pending) {

Is this condition the same as new line 876 above?  (I don't see where the intervening calls would affect it?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1957870981

From kevinw at openjdk.org  Mon Feb 17 11:26:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 17 Feb 2025 11:26:13 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v4]
In-Reply-To: <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
Message-ID: <VR53ZRiPl6AKmM5mQRNuIomk7F52bTyLNsfXFMnG_CY=.4f9547b7-b3e5-4fc2-9c81-fe852d14c7de@github.com>

On Mon, 27 Jan 2025 19:41:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
>> 
>> Testing:
>> 
>> - [x] Tier1 CI
>> - [x] Tier2 CI svc testing
>> - [x] Tier3 CI svc testing
>> - [x] Tier5 CI svc testing
>> - [x] ran all svc test 10 times each on all supported platforms
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix white space errors.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23182#pullrequestreview-2620775907

From jsjolen at openjdk.org  Mon Feb 17 14:04:12 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 17 Feb 2025 14:04:12 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <6IATWzJgb5zFVmIcXhH3XFoVOeU1RxinjTPIvhm4vL0=.f2d9e94d-e0f9-40ad-b843-25defa3c3b09@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <6IATWzJgb5zFVmIcXhH3XFoVOeU1RxinjTPIvhm4vL0=.f2d9e94d-e0f9-40ad-b843-25defa3c3b09@github.com>
Message-ID: <Z2b1KkxpZ0-pyIWrZdFRgbwenEfjjYdHopCtMoVi8To=.ef5af13a-8e0c-4cdd-9111-4941252b7e45@github.com>

On Fri, 14 Feb 2025 06:37:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> We also save a copy of the counters to a global table that contains the N most expensive compilations. That table will be printed when one uses jcmd <pid> Compiler.memory. We also print it into the hs-err file.

This is a new tool for me, but I'd appreciate it if there was the equivalent of `PrintNMTStatistics` such that the table produced from the JCmd is also printed on shutdown.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2663222964

From sgehwolf at openjdk.org  Mon Feb 17 14:06:25 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 17 Feb 2025 14:06:25 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
Message-ID: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>

On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added details in the log message

`CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening.

Testing:
>>And after the patch this would become this, right?
>>```
>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>/sys/fs/cgroup/cpu,cpuacct/
>>```
>
>It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be
>
>```
>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c
>/sys/fs/cgroup/cpu,cpuacct/bad
>/sys/fs/cgroup/cpu,cpuacct/
>```

The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 75:

> 73:               break;
> 74:             }
> 75:             suffix = strchr(suffix+1, '/');

Style:

Suggestion:

            suffix = strchr(suffix + 1, '/');

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 63:

> 61:                         Path cgp = Path.of(cgroupPath);
> 62:                         int nameCount = cgp.getNameCount();
> 63:                         for (int i=0; i<nameCount; ++i) {

Style:

Suggestion:

                        for (int i=0; i < nameCount; i++) {

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 73:

> 71:                                 break;
> 72:                             }
> 73:                             cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of("");

Suggestion:

                            cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of("");

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 60:

> 58: 
> 59:             Common.prepareWhiteBox();
> 60:             DockerTestUtils.buildJdkContainerImage(imageName);

This can be moved out of the condition. It's there in both cases.

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 85:

> 83:         } else {
> 84:             System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now.");
> 85:         }

Suggestion:

        throw new RuntimeException("cgroup version not known? was: " + metrics.getProvider());

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 98:

> 96:         opts.addDockerOpts("--privileged")
> 97:             .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host"))
> 98:             .addDockerOpts("--memory", "1g");

Please extract this "larger" memory limit out of this function. The expectation is to have:


Container memory limit => X
Some lower limit in a moved path => Y

Expect that the lower limit of Y is being detected.


For example:


testMemoryLimitSubgroupV1("1g", "100m", "104857600", false);

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 118:

> 116:         opts.addDockerOpts("--privileged")
> 117:             .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host"))
> 118:             .addDockerOpts("--memory", "1g");

Same here with the `1g` container memory limit. Move it to a parameter.

test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 72:

> 70:         } else {
> 71:             System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now.");
> 72:         }

Please `throw` here.

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

Changes requested by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2620718790
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958032435
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958043532
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958048577
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958073462
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958075672
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958059439
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958061783
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958077572

From alanb at openjdk.org  Mon Feb 17 15:26:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Feb 2025 15:26:14 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules [v2]
In-Reply-To: <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
Message-ID: <F3PCXiegB-EjgfP54T6G4Z_B23Ef5_nN9q-kl9M-V0o=.944af930-79bc-48a6-9041-52b8b7b82844@github.com>

On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
>> 
>> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
>> 
>> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
>> 
>> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @serialData text to CSR-approved version

I think this is oky, the CSR for the change writeExternal has already been reviewed.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2621362315

From hannesw at openjdk.org  Mon Feb 17 15:34:16 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 17 Feb 2025 15:34:16 GMT
Subject: Integrated: 8347123: Add missing @serial tags to other modules
In-Reply-To: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
Message-ID: <bpKNHxlo8g-0-F1SySvfie5_pj0K2tEXiu2cbLyHZ10=.140f9f54-7a24-4633-9901-3bd7ad507871@github.com>

On Wed, 8 Jan 2025 20:13:50 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
> 
> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
> 
> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
> 
> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.

This pull request has now been integrated.

Changeset: 3f0c1370
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f0c1370269db978072814c2170fc3987efade85
Stats:     104 lines in 39 files changed: 45 ins; 0 del; 59 mod

8347123: Add missing @serial tags to other modules

Reviewed-by: prr, nbenalla, alanb

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

PR: https://git.openjdk.org/jdk/pull/22980

From mbaesken at openjdk.org  Mon Feb 17 15:51:14 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 17 Feb 2025 15:51:14 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
Message-ID: <odVIQQDcyKJtY-WCiVhkFgwVDn_BwD0PLMqz6sEscHw=.19efc5b7-a33a-4e10-b624-037b5cba6e98@github.com>

On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added details in the log message

src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2SubsystemController.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.

You did not touch the test but change the COPYRIGHT year, why ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1958449655

From kvn at openjdk.org  Mon Feb 17 18:43:23 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 17 Feb 2025 18:43:23 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10]
In-Reply-To: <UW6o1fVdNjYeif3nCIGQpZPvXasY40lIjBIczpsfY9I=.ad72b291-258f-4df1-b3ee-9a5326657db1@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <PLR4hd5rc20OFzfJxG7yDhph6PXNn6j1CJnvHI-OrI8=.7f019bc0-c1c4-4d68-8354-ca2567994784@github.com>
 <UW6o1fVdNjYeif3nCIGQpZPvXasY40lIjBIczpsfY9I=.ad72b291-258f-4df1-b3ee-9a5326657db1@github.com>
Message-ID: <tvGthmdq3FTnD3fqAPLacJa3_VmAY4dwEmgi0NfQaBE=.8699ac74-47d5-4c7a-941b-1613f84fa52f@github.com>

On Mon, 17 Feb 2025 06:24:35 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove commented lines left by mistake
>
> src/hotspot/share/code/codeBlob.hpp line 308:
> 
>> 306: 
>> 307:   class Vptr : public CodeBlob::Vptr {
>> 308:   };
> 
> Was this needed for some compiler? Or is it to be more explicit about the type hierarchy?

Thank you, @xmas92, for review and suggestions.

It is second (explicit type hierarchy). I think it should be explicitly declared (even empty) because it is referenced in subclasses to avoid confusion. And it could be useful in a future if we need other virtual methods.

Local build with `gcc` on Linux passed without it but  I did not try to build on other platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23533#discussion_r1958673128

From cjplummer at openjdk.org  Mon Feb 17 22:56:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 17 Feb 2025 22:56:12 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <sCVQRKUH48CzjjJUgu4Av-2mbPPodY6-obTXCBcAaDI=.579f5a98-265c-47f4-9a5a-98cef76888a3@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <sCVQRKUH48CzjjJUgu4Av-2mbPPodY6-obTXCBcAaDI=.579f5a98-265c-47f4-9a5a-98cef76888a3@github.com>
Message-ID: <QninAaRo-cjkSjYVTMzeogmUK4NLeypar_7p8ttSI7U=.b6fc1a6d-720e-4be9-9f90-0310f22de66a@github.com>

On Mon, 17 Feb 2025 09:04:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> btw for libjdwp with lto enabled (have to modify the make settings because this is not supported out of the box) I get
> 
> 1.8M ./lib/libjdwp.debuginfo 280K ./lib/libjdwp.so
> 
> This looks pretty good compared to HIGH or standard (LOW/NORM) settings.

What is the optimization level?

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2664192106

From dholmes at openjdk.org  Tue Feb 18 01:28:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Feb 2025 01:28:20 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <tjhqeB9WM0W5lW_zPBmRcWeUbnZHNIbGUVwAz5M2B2w=.c5846c0c-48dc-4ec7-8484-122ffc65b6da@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>
 <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>
 <zAeXXZW_4kcwsb3KRuM3WtzNxLFg6hxLlGAZrjb5fVM=.4837c962-5da8-4509-86a9-ce9d55c10f53@github.com>
 <tjhqeB9WM0W5lW_zPBmRcWeUbnZHNIbGUVwAz5M2B2w=.c5846c0c-48dc-4ec7-8484-122ffc65b6da@github.com>
Message-ID: <LTme3fmXgtMsqI9JjpxQRLyj32IrpvS9SLdRbEMh2v0=.b20b88b8-7d2e-47d6-bb39-301cea4c80fe@github.com>

On Sat, 15 Feb 2025 11:49:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I have removed the new API, and switched to use the original in_critical().

You still need it to be an atomic load together with whatever compiler barriers that implies, otherwise it can be hoisted out of the spin-loop:

while (cur->in_critical()) {
  spin_yield.wait();
}

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2664351707

From dholmes at openjdk.org  Tue Feb 18 01:40:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Feb 2025 01:40:22 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v3]
In-Reply-To: <ykFgVzd-uwQYcxFmbl379IvIMEmtePZPjINe_Q-cJZo=.c4f001c7-77ca-41e2-af32-5072e1899748@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <ykFgVzd-uwQYcxFmbl379IvIMEmtePZPjINe_Q-cJZo=.c4f001c7-77ca-41e2-af32-5072e1899748@github.com>
Message-ID: <iQwqZnk4rYN-W9IzGLhpNAr1o-2rdf0bSPt9XLq5No8=.36adb820-a445-4a7a-8669-16ed2d7ad4a7@github.com>

On Sat, 15 Feb 2025 11:44:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

The GCLocker behaviour would be easier to discern if all of the `thread` parameters/variables that have to be the current thread were actually called `current` (with a few suitably placed assertions).

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

PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2622203973

From cjplummer at openjdk.org  Tue Feb 18 03:01:22 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Feb 2025 03:01:22 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v4]
In-Reply-To: <CJjWwnTVcAs743BtUPrLKmmghA_YTwhT1lN8IbTXkCc=.60981038-bc72-41a7-a28e-f93c08fdd23c@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
 <CJjWwnTVcAs743BtUPrLKmmghA_YTwhT1lN8IbTXkCc=.60981038-bc72-41a7-a28e-f93c08fdd23c@github.com>
Message-ID: <uD03n5EEDGyyqOrkixO60oJ7LDo2NWTt-rqp1b402jg=.af08b986-a35e-490f-892c-153faaa6dfee@github.com>

On Mon, 17 Feb 2025 09:14:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix white space errors.
>
> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 899:
> 
>> 897:     }
>> 898: 
>> 899:     if (step->pending) {
> 
> Is this condition the same as new line 876 above?  (I don't see where the intervening calls would affect it?)

That's a good question. I hadn't noticed the extra check for step->pending, and it looks like that was also in place for the previous version that relied on calling ClearFramePop on each outstanding NotifyFramePop. I think it is just bit rot as the code initially evolved. If it was possibly for the flag to be cleared by some other thread (I actually think it might be, but need to look closer), this extra check is not of much help since it could be cleared after the check. Let me look into this a bit more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1958993698

From cjplummer at openjdk.org  Tue Feb 18 03:05:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Feb 2025 03:05:16 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10]
In-Reply-To: <PLR4hd5rc20OFzfJxG7yDhph6PXNn6j1CJnvHI-OrI8=.7f019bc0-c1c4-4d68-8354-ca2567994784@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <PLR4hd5rc20OFzfJxG7yDhph6PXNn6j1CJnvHI-OrI8=.7f019bc0-c1c4-4d68-8354-ca2567994784@github.com>
Message-ID: <VuK7WXwT96D8YCQUtxc6ODJY7os3I6Uxav8le0rCGCk=.2de8b156-f103-4865-bf91-43bf4388376d@github.com>

On Sat, 15 Feb 2025 06:34:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove commented lines left by mistake

SA changes look good. Thanks for taking care of this.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23533#pullrequestreview-2622331256

From asmehra at openjdk.org  Tue Feb 18 05:24:10 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 18 Feb 2025 05:24:10 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v2]
In-Reply-To: <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
Message-ID: <vZAa9qCp1aLUuUPD8xYcXe24X6zZcY37TQwUx3Q-iZc=.4b1c2427-7165-4f0b-a7a9-bc05de643e5e@github.com>

On Fri, 14 Feb 2025 19:21:32 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
>> 
>> Passed tiers 1 - 5 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam and @ashu-mehra comment

Marked as reviewed by asmehra (Committer).

Just one more comment, rest looks good.

src/hotspot/share/runtime/threads.cpp line 27:

> 25:  */
> 26: 
> 27: #include "cds/aotCodeSource.hpp"

Why is this include needed?

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

PR Review: https://git.openjdk.org/jdk/pull/23476#pullrequestreview-2622461930
PR Comment: https://git.openjdk.org/jdk/pull/23476#issuecomment-2664635612
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959077605

From dholmes at openjdk.org  Tue Feb 18 07:28:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Feb 2025 07:28:19 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v2]
In-Reply-To: <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
Message-ID: <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>

On Fri, 14 Feb 2025 19:21:32 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
>> 
>> Passed tiers 1 - 5 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam and @ashu-mehra comment

This is a very large change to try and digest. Is it really just a refactor? I've made a few comments in places where it seems functionality may have been changed as well.

src/hotspot/share/cds/aotCodeSource.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

If the code has been moved from other files, the current opinion/consensus is that the first copyright year should be the oldest first year from all the files from which the code was obtained.

src/hotspot/share/cds/aotCodeSource.cpp line 106:

> 104:     for (const char* bootcp = Arguments::get_boot_class_path(); *bootcp != '\0'; ++bootcp) {
> 105:       if (*bootcp == *os::path_separator()) {
> 106:         ++ bootcp;

Nit (possibly pre-existing) - no space before/after unary operators

src/hotspot/share/cds/aotCodeSource.hpp line 125:

> 123: // during AOTCache creation are the same as when the AOTCache is used during runtime.
> 124: // Non-existent entries are recorded during AOTCache creation. Those non-existent entries
> 125: // must not exist during runtime.

Does this mean that if Foo.jar is on the classpath but does not in fact exist, then we record it was on the classpath and require it to be on the classpath at runtime, but also to still not exist?

src/hotspot/share/cds/aotCodeSource.hpp line 128:

> 126: //
> 127: // Some details on validation:
> 128: // - the boot classpath could be appended during runtime if there's no app classpath and

Suggestion:

// - the boot classpath can be appended to at runtime if there's no app classpath and no

src/hotspot/share/cds/aotCodeSource.hpp line 130:

> 128: // - the boot classpath could be appended during runtime if there's no app classpath and
> 129: //   module path specified when an AOTCache is created;
> 130: // - the app classpath could be appended during runtime;

Suggestion:

// - the app classpath can be appended to at runtime;

src/hotspot/share/cds/aotCodeSource.hpp line 131:

> 129: //   module path specified when an AOTCache is created;
> 130: // - the app classpath could be appended during runtime;
> 131: // - the module path during runtime could be a superset of the one specified during AOTCache creation.

Suggestion:

// - the module path at runtime can be a superset of the one specified during AOTCache creation.

src/hotspot/share/runtime/threads.cpp line 809:

> 807:     vm_exit_during_initialization("ClassLoader::initialize_module_path() failed unexpectedly");
> 808:   }
> 809: #endif

Not obvious where this functionality is now handled.

test/hotspot/jtreg/runtime/cds/appcds/BootClassPathMismatch.java line 243:

> 241:      * No error - bootclasspath can be appended during runtime if no -cp is specified.
> 242:      */
> 243:     public void testBootClassPathAppend() throws Exception {

A refactoring should not be introducing new test cases. Did you refactor and enhance?

test/hotspot/jtreg/runtime/cds/appcds/NonExistClasspath.java line 70:

> 68:             .assertNormalExit();
> 69: 
> 70:         // Replace nonExistPath with another non-existent file in the CP, it should still work

Not at all clearr why these test cases have been removed?

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

PR Review: https://git.openjdk.org/jdk/pull/23476#pullrequestreview-2622538668
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959178211
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959126336
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959181514
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959181842
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959183865
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959184959
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959192451
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959193331
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1959194900

From ayang at openjdk.org  Tue Feb 18 09:20:57 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Feb 2025 09:20:57 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v4]
In-Reply-To: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
Message-ID: <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>

> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
> 
> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
> 
> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
> 
> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into gclocker
 - review
 - Merge branch 'master' into gclocker
 - review
 - Merge branch 'master' into gclocker
 - review
 - Merge branch 'master' into gclocker
 - gclocker

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23367/files
  - new: https://git.openjdk.org/jdk/pull/23367/files/005087e3..78f91d4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=02-03

  Stats: 1461 lines in 94 files changed: 848 ins; 266 del; 347 mod
  Patch: https://git.openjdk.org/jdk/pull/23367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23367/head:pull/23367

PR: https://git.openjdk.org/jdk/pull/23367

From ayang at openjdk.org  Tue Feb 18 09:24:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Feb 2025 09:24:15 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <LTme3fmXgtMsqI9JjpxQRLyj32IrpvS9SLdRbEMh2v0=.b20b88b8-7d2e-47d6-bb39-301cea4c80fe@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>
 <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>
 <zAeXXZW_4kcwsb3KRuM3WtzNxLFg6hxLlGAZrjb5fVM=.4837c962-5da8-4509-86a9-ce9d55c10f53@github.com>
 <tjhqeB9WM0W5lW_zPBmRcWeUbnZHNIbGUVwAz5M2B2w=.c5846c0c-48dc-4ec7-8484-122ffc65b6da@github.com>
 <LTme3fmXgtMsqI9JjpxQRLyj32IrpvS9SLdRbEMh2v0=.b20b88b8-7d2e-47d6-bb39-301cea4c80fe@github.com>
Message-ID: <E3bUYzjwiPGr_oSTK1IdkQSVkPCF7SHlelgmRkR5Wbw=.d9f1c895-b65d-4384-96fd-9db63c420d16@github.com>

On Tue, 18 Feb 2025 01:25:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

> You still need it to be an atomic load

Then, maybe the logic is easier to read if the "atomic" access is visible directly from that context, instead of hiding it inside `in_critical`. Therefore, it probably makes more sense to introduce a new API. WDYT?

> The GCLocker behaviour would be easier to discern ...

Renamed to `current_thread` in `enter`,`exit`, and `enter_slow`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2665044825

From rcastanedalo at openjdk.org  Tue Feb 18 10:10:13 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 18 Feb 2025 10:10:13 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
Message-ID: <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>

On Fri, 14 Feb 2025 08:55:26 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Hi Thomas, this looks very useful, thanks! I will run some Oracle-internal functional and performance testing and come back with the results next week.

Functional test results (Oracle internal tier1-tier5) look good.

I measured C2 execution time before and after the changeset using DaCapo 23 and did not find any statistically significant difference, except for a 2-3% regression on the jython benchmark (using large input size). This small regression is IMO acceptable, particularly given that these changes can be seen as an investment to improve compiler resource utilization in the long run.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2665162403

From mbaesken at openjdk.org  Tue Feb 18 19:22:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Feb 2025 19:22:41 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <QninAaRo-cjkSjYVTMzeogmUK4NLeypar_7p8ttSI7U=.b6fc1a6d-720e-4be9-9f90-0310f22de66a@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <sCVQRKUH48CzjjJUgu4Av-2mbPPodY6-obTXCBcAaDI=.579f5a98-265c-47f4-9a5a-98cef76888a3@github.com>
 <QninAaRo-cjkSjYVTMzeogmUK4NLeypar_7p8ttSI7U=.b6fc1a6d-720e-4be9-9f90-0310f22de66a@github.com>
Message-ID: <yUEKUpNSGMckLkdc0Q0nYZHwInQ0lX8YA-GUaTPcGgU=.51c9c748-fe5a-4066-b179-1a9ff652d97f@github.com>

On Mon, 17 Feb 2025 22:53:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > btw for libjdwp with lto enabled (have to modify the make settings because this is not supported out of the box) I get
> > 1.8M ./lib/libjdwp.debuginfo 280K ./lib/libjdwp.so
> > This looks pretty good compared to HIGH or standard (LOW/NORM) settings.
> 
> What is the optimization level?

It was with unchanged optimization settings on lib-level (so LOW/NORM stayed for libjdwp) for the compilation, but -O3 set in the linkage settings.
See the patch I used for more clarity regarding this experiment 


diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
index 729e508cc26..b31a98dabc0 100644
--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -537,6 +537,10 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_HELPER],
     # no-strict-aliasing everywhere!)
     TOOLCHAIN_CFLAGS_JDK_CONLY="-fno-strict-aliasing"
 
+    # check here for opt-size setting (or later when setting)
+    TOOLCHAIN_CFLAGS_LTO_JDK="-flto=auto -fuse-linker-plugin -fno-strict-aliasing -fno-fat-lto-objects"
+    TOOLCHAIN_CXXFLAGS_LTO_JDK="-flto=auto -fuse-linker-plugin -fno-strict-aliasing -fno-fat-lto-objects"
+
   elif test "x$TOOLCHAIN_TYPE" = xclang; then
     # Restrict the debug information created by Clang to avoid
     # too big object files and speed the build up a little bit
@@ -876,9 +880,9 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP],
 
   $2CFLAGS_JDKEXE="$CFLAGS_JDK_COMMON $CFLAGS_JDK_COMMON_CONLY ${$1_CFLAGS_JDK} $PIEFLAG"
   $2CXXFLAGS_JDKEXE="$CFLAGS_JDK_COMMON $CFLAGS_JDK_COMMON_CXXONLY ${$1_CFLAGS_JDK} $PIEFLAG"
-  $2CFLAGS_JDKLIB="$CFLAGS_JDK_COMMON $CFLAGS_JDK_COMMON_CONLY ${$1_CFLAGS_JDK} \
+  $2CFLAGS_JDKLIB="$CFLAGS_JDK_COMMON $TOOLCHAIN_CFLAGS_LTO_JDK $CFLAGS_JDK_COMMON_CONLY ${$1_CFLAGS_JDK} \
       $JDK_PICFLAG ${$1_CFLAGS_CPU_JDK_LIBONLY}"
-  $2CXXFLAGS_JDKLIB="$CFLAGS_JDK_COMMON $CFLAGS_JDK_COMMON_CXXONLY ${$1_CFLAGS_JDK} \
+  $2CXXFLAGS_JDKLIB="$CFLAGS_JDK_COMMON $TOOLCHAIN_CXXFLAGS_LTO_JDK $CFLAGS_JDK_COMMON_CXXONLY ${$1_CFLAGS_JDK} \
       $JDK_PICFLAG ${$1_CFLAGS_CPU_JDK_LIBONLY}"
 
   AC_SUBST($2JVM_CFLAGS)
diff --git a/make/autoconf/flags-ldflags.m4 b/make/autoconf/flags-ldflags.m4
index 2e060a71d4d..fbd2514ec7e 100644
--- a/make/autoconf/flags-ldflags.m4
+++ b/make/autoconf/flags-ldflags.m4
@@ -59,6 +59,8 @@ AC_DEFUN([FLAGS_SETUP_LDFLAGS_HELPER],
         BASIC_LDFLAGS_JDK_ONLY="$BASIC_LDFLAGS_JDK_ONLY -Wl,--gc-sections"
       fi
     fi
+    # $(CXX_O_FLAG_HIGHEST_JVM) -> -O3 for gcc
+    BASIC_LDFLAGS_LTO_JDK="-O3 -flto=auto -fuse-linker-plugin -fno-strict-aliasing"
 
     BASIC_LDFLAGS_JVM_ONLY=""
 
@@ -192,7 +194,7 @@ AC_DEFUN([FLAGS_SETUP_LDFLAGS_CPU_DEP],
   # Export variables according to old definitions, prefix with $2 if present.
   LDFLAGS_JDK_COMMON="$BASIC_LDFLAGS $BASIC_LDFLAGS_JDK_ONLY \
       $OS_LDFLAGS $DEBUGLEVEL_LDFLAGS_JDK_ONLY ${$2EXTRA_LDFLAGS}"
-  $2LDFLAGS_JDKLIB="$LDFLAGS_JDK_COMMON \
+  $2LDFLAGS_JDKLIB="$LDFLAGS_JDK_COMMON $BASIC_LDFLAGS_LTO_JDK \
       $SHARED_LIBRARY_FLAGS $REPRODUCIBLE_LDFLAGS $FILE_MACRO_LDFLAGS"
   $2LDFLAGS_JDKEXE="$LDFLAGS_JDK_COMMON $EXECUTABLE_LDFLAGS \
       ${$1_CPU_EXECUTABLE_LDFLAGS} $REPRODUCIBLE_LDFLAGS $FILE_MACRO_LDFLAGS"

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2666010735

From kvn at openjdk.org  Tue Feb 18 19:24:22 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Feb 2025 19:24:22 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v2]
In-Reply-To: <g1xZtizMWGUVmJj54HU6Xto4EFize_eVZy7gWRNrRus=.835606f5-7800-48af-84bd-2310d82d867e@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <UpT0IDb0Y33QFlFCzUQad0y1qYnadGt6VwFxeR9GTZY=.8d61f572-209d-4509-b03d-068fb21ee3ce@github.com>
 <rs6rOizOwjIbK5bOSPR-YHledkZyK1ZrfXTYLAjaI2o=.8a8eab26-eae5-45f5-a10a-fc6cf4bbe94c@github.com>
 <GPZdeIQ8_nb5jtnet5PBB3IIrkqaQMS-SxtcIPhcHeY=.0c90ff82-6b91-4ed9-a400-2967c712ca1c@github.com>
 <g1xZtizMWGUVmJj54HU6Xto4EFize_eVZy7gWRNrRus=.835606f5-7800-48af-84bd-2310d82d867e@github.com>
Message-ID: <p1tQ4tR4An5lAGBXmeiWSiwzyVhQGHdiPolrRL3zvjk=.4c206362-11bc-4c7e-8514-bdc24c82bb00@github.com>

On Wed, 12 Feb 2025 03:03:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Before I forgot to answer you, @plummercj 
>> I completely agree with your comment about cleaning up wrapper subclasses which do nothing.
>> 
>> I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there?
>> 
>> An other purpose could be a place holder for additional information in a future which never come.
>> 
>> Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of  VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM.
>> 
>> So yes, feel free to clean this up.  I will help with review.
>
>> I think some wrapper subclasses for CodeBlob were kept because of `is*()` which were used only in `PStack` to print name. Why not use `getName()` for this purpose without big `if/else` there?
> 
> Possibly getName() didn't exist when PStack was first written. It would be good if PStack not only included the type name as it does now, but also the actual name of the blob, which getName() would return.
> 
>> An other purpose could be a place holder for additional information in a future which never come.
> 
> Yes, and you also see that with the Observer registration and the `Type type = db.lookupType(<typename>)` code, which are only needed if you are going to lookup fields of the subtypes, which most don't ever do, yet they all have this code.
>  
>> Other wrapper provides information available in `CodeBlob`. Like `RuntimeStub. callerMustGCArguments()`. `_caller_must_gc_arguments` field is part of VM's `CodeBlob` class for some time now. Looks like I missed change in SA when did change in VM.
> 
> Yeah, that's not working right for CodeBlob subtypes that are not RuntimeStubs. Easy to fix though.
> 
>> So yes, feel free to clean this up. I will help with review.
> 
> Ok. Let me see where things are at after you are done with the PR.

Thank you, @plummercj , for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2666228333

From kvn at openjdk.org  Tue Feb 18 19:24:34 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Feb 2025 19:24:34 GMT
Subject: RFR: 8349088: De-virtualize Codeblob and nmethod [v10]
In-Reply-To: <PLR4hd5rc20OFzfJxG7yDhph6PXNn6j1CJnvHI-OrI8=.7f019bc0-c1c4-4d68-8354-ca2567994784@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
 <PLR4hd5rc20OFzfJxG7yDhph6PXNn6j1CJnvHI-OrI8=.7f019bc0-c1c4-4d68-8354-ca2567994784@github.com>
Message-ID: <dAs_GALeshXTv-gRg4iGXrb59ZxDM1iCimXzIQ03f24=.8d891b89-e547-4923-8a9a-987af28acfb4@github.com>

On Sat, 15 Feb 2025 06:34:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
>> 
>> Added C++ static asserts to make sure no virtual methods are added in a future.
>> 
>> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
>> 
>> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove commented lines left by mistake

Thank you all for reviews and suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/23533#issuecomment-2666253220

From cjplummer at openjdk.org  Tue Feb 18 19:44:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Feb 2025 19:44:56 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v4]
In-Reply-To: <uD03n5EEDGyyqOrkixO60oJ7LDo2NWTt-rqp1b402jg=.af08b986-a35e-490f-892c-153faaa6dfee@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
 <CJjWwnTVcAs743BtUPrLKmmghA_YTwhT1lN8IbTXkCc=.60981038-bc72-41a7-a28e-f93c08fdd23c@github.com>
 <uD03n5EEDGyyqOrkixO60oJ7LDo2NWTt-rqp1b402jg=.af08b986-a35e-490f-892c-153faaa6dfee@github.com>
Message-ID: <sCAcgYBZSKhB_wdTmqbip48Iod0wpCoTKmr1HkEahGM=.541466ae-2760-4e6d-8fdb-2f857e40929b@github.com>

On Tue, 18 Feb 2025 02:58:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 899:
>> 
>>> 897:     }
>>> 898: 
>>> 899:     if (step->pending) {
>> 
>> Is this condition the same as new line 876 above?  (I don't see where the intervening calls would affect it?)
>
> That's a good question. I hadn't noticed the extra check for step->pending, and it looks like that was also in place for the previous version that relied on calling ClearFramePop on each outstanding NotifyFramePop. I think it is just bit rot as the code initially evolved. If it was possibly for the flag to be cleared by some other thread (I actually think it might be, but need to look closer), this extra check is not of much help since it could be cleared after the check. Let me look into this a bit more.

There are multiple threads that can end up calling clearStep(). However, all callers of clearStep() grab the eventHandler_lock() first, with one somewhat obscure exception:

debugInit_reset
threadControl_reset
removeVThreads
clearThread
stepControl_clearRequest
clearStep

This is done for a debugger reset after a connection has been dropped. Probably not at much risk of a race in clearStep, but I think is best to add eventHandler locking here also. After doing this there will be no race conditions to worry about.

I'm pretty sure this extra check for "pending" is just bit rot. I know I wanted an if block around the new code to make it easy to disable so I could easily benchmark and test with and without "the fix". I think at one point the code looked a lot different (I think there was something outside of the if), but that was long ago.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1960478633

From kvn at openjdk.org  Tue Feb 18 20:11:04 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Feb 2025 20:11:04 GMT
Subject: Integrated: 8349088: De-virtualize Codeblob and nmethod
In-Reply-To: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
References: <0PvzE8go0Q4VGhH_OF3OyPPgoD4qhxxfBgSHe41chBU=.e471b2a1-96ad-490d-b3d0-a050bd00d7d8@github.com>
Message-ID: <ErVvY1I8JdPoOXE4djJRzOhIeB1wvVZetGE8bnhau7U=.69b08d24-c6e5-408c-9045-6ab0447aca4b@github.com>

On Sun, 9 Feb 2025 17:45:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Remove virtual methods from CodeBlob and nmethod to simplify saving/restoring in Leyden AOT cache. It avoids the need to patch hidden VPTR pointer to class's virtual table.
> 
> Added C++ static asserts to make sure no virtual methods are added in a future.
> 
> Fixed/cleaned SA code which process CodeBlob and its subclasses. Use `CodeBlob::_kind` field value to determine the type of blob.
> 
> Tested tier1-5, hs-tier6-rt (for JFR testing), stress, xcomp

This pull request has now been integrated.

Changeset: 46d4a601
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46d4a601e04f90b11d4ccc97a49f4e7010b4fd83
Stats:     529 lines in 23 files changed: 262 ins; 152 del; 115 mod

8349088: De-virtualize Codeblob and nmethod

Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
Reviewed-by: cjplummer, aboldtch, dlong

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

PR: https://git.openjdk.org/jdk/pull/23533

From cjplummer at openjdk.org  Tue Feb 18 20:49:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Feb 2025 20:49:55 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v4]
In-Reply-To: <sCAcgYBZSKhB_wdTmqbip48Iod0wpCoTKmr1HkEahGM=.541466ae-2760-4e6d-8fdb-2f857e40929b@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
 <CJjWwnTVcAs743BtUPrLKmmghA_YTwhT1lN8IbTXkCc=.60981038-bc72-41a7-a28e-f93c08fdd23c@github.com>
 <uD03n5EEDGyyqOrkixO60oJ7LDo2NWTt-rqp1b402jg=.af08b986-a35e-490f-892c-153faaa6dfee@github.com>
 <sCAcgYBZSKhB_wdTmqbip48Iod0wpCoTKmr1HkEahGM=.541466ae-2760-4e6d-8fdb-2f857e40929b@github.com>
Message-ID: <5HB5-H_Rcff8_B0B3bV1f4wXSB48LOXDX5UUKgKlXpY=.a5e6b156-4189-4249-b973-4a37fa51ac6e@github.com>

On Tue, 18 Feb 2025 19:42:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> That's a good question. I hadn't noticed the extra check for step->pending, and it looks like that was also in place for the previous version that relied on calling ClearFramePop on each outstanding NotifyFramePop. I think it is just bit rot as the code initially evolved. If it was possibly for the flag to be cleared by some other thread (I actually think it might be, but need to look closer), this extra check is not of much help since it could be cleared after the check. Let me look into this a bit more.
>
> There are multiple threads that can end up calling clearStep(). However, all callers of clearStep() grab the eventHandler_lock() first, with one somewhat obscure exception:
> 
> debugInit_reset
> threadControl_reset
> removeVThreads
> clearThread
> stepControl_clearRequest
> clearStep
> 
> This is done for a debugger reset after a connection has been dropped. Probably not at much risk of a race in clearStep, but I think is best to add eventHandler locking here also. After doing this there will be no race conditions to worry about.
> 
> I'm pretty sure this extra check for "pending" is just bit rot. I know I wanted an if block around the new code to make it easy to disable so I could easily benchmark and test with and without "the fix". I think at one point the code looked a lot different (I think there was something outside of the if), but that was long ago.

I looked a bit more...

There are multiple threads that can end up calling clearStep(), so we need to be careful about races. There are two main paths into clearStep.
-The first is through stepControl_endStep. It always grabs the handler_lock and stepControl_lock.
-The 2nd is through through stepControl_clearRequest, which grabs no locks itself, but there are some already grabbed when it is called. It should really grab the stepControl_lock, but it can't because that lock is suppose to be grabbed before threadControl_lock, which has already been grabbed.  The proper order is handler_lock -> stepControl_lock -> threadControl_lock. So we need to fix locking for stepControl_clearRequest somehow.

There are 3 paths into stepControl_clearRequest().

1. The first goes through clearThread via removeThread via removeResumed.  This path always holds the handler_lock and threadControl_lock.
2. The 2nd goes through clearThread via removeThread via threadControl_onEventHandlerExit. This also holds the handler_lock and threadControl_onEventHandlerExit.
3. The 3rd goes through clearThread via removeVThreads via threadControl_reset. This path always holds the handler_lock, but not threadControl_lock

Holding the threadControl_lock here does not help us since stepControl_endStep does not grab that lock. Holding the eventHandler_lock does help since stepControl_endStep does grab it, but the 3rd path above does not grab the eventHandler_lock. I think the simplest fix here is to just make it do so. But that's using the eventHandler_lock to make stepControl code thread safe. Not exactly clean. So that means instead requiring the caller of stepControl_endStep to do all the needed locking. Basically add locking of stepControl_lock somewhere. Adding locking of stepControl_lock in clearThread is too late since we already hold the threadLock. It really needs to be pushed up the call chain of each of the above 3 paths to the point just before grabing the threadLock. For example for the 2nd call path above we have:

    if (ei == EI_THREAD_END) {
        eventHandler_lock(); /* for proper lock order - see removeThread() call below */
        debugMonitorEnter(threadLock);
 
So we need to add stepControl_lock() in between those too lines. We need to do similar for the 1st and 3rd paths also.

I think this is best held off for another PR. I can file a CR for it now with these notes. It's not a new problem, although might be slightly more at risk of going awry since we are doing a lot more in clearStep() now, but so far non of my testing has turned up any issues, so I think a proper fix can wait. It also relates to the ranked locking support project, which I hope to start back up soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1960569052

From imyers at openjdk.org  Tue Feb 18 23:08:57 2025
From: imyers at openjdk.org (Ian Myers)
Date: Tue, 18 Feb 2025 23:08:57 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
 <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
Message-ID: <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>

On Wed, 29 Jan 2025 23:15:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.
>> 
>> - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.
>> 
>> - Contacted ietf, these are the new links to use.
>> 
>> This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.
>> 
>> Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.
>
> make/common/Modules.gmk line 95:
> 
>> 93: SPEC_SUBDIRS += share/specs
>> 94: 
>> 95: MAN_SUBDIRS += share/man windows/man
> 
> Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.

Hi @magicus we are seeing build failures because linux builds contain man pages for windows-only tools as reported by https://bugs.openjdk.org/browse/JDK-8350137. Would replacing `windows/man` with `$(TARGET_OS)/man` prevent windows-only tools man pages being generated for linux builds?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1960715214

From cjplummer at openjdk.org  Tue Feb 18 23:38:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Feb 2025 23:38:35 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v5]
In-Reply-To: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
Message-ID: <RclcYW1ejBxBeaXNorFGjX7QHG0_IsiyY_EAReL6IwI=.5cc12370-e9f7-4c63-91ce-3a254a397b0a@github.com>

> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
> 
> Testing:
> 
> - [x] Tier1 CI
> - [x] Tier2 CI svc testing
> - [x] Tier3 CI svc testing
> - [x] Tier5 CI svc testing
> - [x] ran all svc test 10 times each on all supported platforms

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  get rid of redundant if

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23182/files
  - new: https://git.openjdk.org/jdk/pull/23182/files/bbd778fc..864671ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23182&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23182&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23182/head:pull/23182

PR: https://git.openjdk.org/jdk/pull/23182

From cjplummer at openjdk.org  Wed Feb 19 02:18:01 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Feb 2025 02:18:01 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses
Message-ID: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>

There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also.

I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. 

There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone):


  public String getName() {
    return "AdapterBlob: " + super.getName();
  }


So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type.  I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it.

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

Commit messages:
 - fix whitespace
 - undo mistaken line deletion
 - Clean CodeBlob support

Changes: https://git.openjdk.org/jdk/pull/23684/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23684&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350287
  Stats: 593 lines in 14 files changed: 11 ins; 578 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23684.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23684/head:pull/23684

PR: https://git.openjdk.org/jdk/pull/23684

From kvn at openjdk.org  Wed Feb 19 03:17:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 19 Feb 2025 03:17:54 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses
In-Reply-To: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
Message-ID: <RZakZmEU3nhc0TBHVE_KDstYFPDCw-tLoOiIVxiUzXo=.229940bf-8051-4010-8025-d32a0ce010c9@github.com>

On Wed, 19 Feb 2025 02:08:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type. 

I think this is fine: output is informative enough to figure out type of blob.  Please check SA tests if they look for old output.

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

PR Comment: https://git.openjdk.org/jdk/pull/23684#issuecomment-2667409688

From kvn at openjdk.org  Wed Feb 19 03:25:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 19 Feb 2025 03:25:52 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses
In-Reply-To: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
Message-ID: <RJoU-0K-EtmFe8YA5dJnJfRMsRS3ppQLNanyj_FcPx0=.c96a2d3e-9c0d-4031-af6d-bd87cd075584@github.com>

On Wed, 19 Feb 2025 02:08:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also.
> 
> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. 
> 
> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone):
> 
> 
>   public String getName() {
>     return "AdapterBlob: " + super.getName();
>   }
> 
> 
> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type.  I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/RuntimeStub.java line 47:

> 45:   private static void initialize(TypeDataBase db) {
> 46:     Type type = db.lookupType("RuntimeStub");
> 47:     callerMustGCArgumentsField = type.getCIntegerField("_caller_must_gc_arguments");

This field is in `CodeBlob` since JDK 23 [JDK-8329433](https://bugs.openjdk.org/browse/JDK-8329433) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeBlob.hpp#L126

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23684#discussion_r1960893284

From cjplummer at openjdk.org  Wed Feb 19 04:34:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Feb 2025 04:34:53 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses
In-Reply-To: <RZakZmEU3nhc0TBHVE_KDstYFPDCw-tLoOiIVxiUzXo=.229940bf-8051-4010-8025-d32a0ce010c9@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
 <RZakZmEU3nhc0TBHVE_KDstYFPDCw-tLoOiIVxiUzXo=.229940bf-8051-4010-8025-d32a0ce010c9@github.com>
Message-ID: <ylze0bWymQn8mSKkYLovI7XuHbvnYcUkMuvUe8nqfy4=.32aebd12-3842-415a-a716-b5e029e00b21@github.com>

On Wed, 19 Feb 2025 03:14:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type.
> 
> I think this is fine: output is informative enough to figure out type of blob. Please check SA tests if they look for old output.

The tests are all passing.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/RuntimeStub.java line 47:
> 
>> 45:   private static void initialize(TypeDataBase db) {
>> 46:     Type type = db.lookupType("RuntimeStub");
>> 47:     callerMustGCArgumentsField = type.getCIntegerField("_caller_must_gc_arguments");
> 
> This field is in `CodeBlob` since JDK 23 [JDK-8329433](https://bugs.openjdk.org/browse/JDK-8329433) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeBlob.hpp#L126

Ah, right. I forgot you had mentioned that. I think that means I can rid of RuntimeStub and RuntimeBlob once this code is moved to CodeBlob.

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

PR Comment: https://git.openjdk.org/jdk/pull/23684#issuecomment-2667484513
PR Review Comment: https://git.openjdk.org/jdk/pull/23684#discussion_r1960935263

From cjplummer at openjdk.org  Wed Feb 19 05:49:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Feb 2025 05:49:56 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2]
In-Reply-To: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
Message-ID: <k2NwhUstKFzIbzXfe4SJAmFAlxyaPIjwkkLkxZY48Yo=.c90111cb-d4ee-42dd-8f7c-0e44336351c5@github.com>

> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also.
> 
> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. 
> 
> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone):
> 
> 
>   public String getName() {
>     return "AdapterBlob: " + super.getName();
>   }
> 
> 
> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type.  I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Minor improvements.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23684/files
  - new: https://git.openjdk.org/jdk/pull/23684/files/138fed50..e965c310

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23684&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23684&range=00-01

  Stats: 110 lines in 4 files changed: 4 ins; 104 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23684.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23684/head:pull/23684

PR: https://git.openjdk.org/jdk/pull/23684

From duke at openjdk.org  Wed Feb 19 06:21:33 2025
From: duke at openjdk.org (sli-x)
Date: Wed, 19 Feb 2025 06:21:33 GMT
Subject: RFR: 8340434: Excessive Young GCs Triggered by CodeCache GC Threshold
Message-ID: <g22FgTJTATrz5UIKsSy3a98OgJIm8hvZ9KFm4u75PyY=.dea7d218-c0d7-43a9-afff-d167383eeb63@github.com>

The trigger of _codecache_GC_threshold in CodeCache::gc_on_allocation is the key to this problem.

if (used_ratio > threshold) {
    // After threshold is reached, scale it by free_ratio so that more aggressive
    // GC is triggered as we approach code cache exhaustion
    threshold *= free_ratio;
  }
  // If code cache has been allocated without any GC at all, let's make sure
  // it is eventually invoked to avoid trouble.
  if (allocated_since_last_ratio > threshold) {
    // In case the GC is concurrent, we make sure only one thread requests the GC.
    if (Atomic::cmpxchg(&_unloading_threshold_gc_requested, false, true) == false) {
      log_info(codecache)("Triggering threshold (%.3f%%) GC due to allocating %.3f%% since last unloading (%.3f%% used -> %.3f%% used)",
                          threshold * 100.0, allocated_since_last_ratio * 100.0, last_used_ratio * 100.0, used_ratio * 100.0);
      Universe::heap()->collect(GCCause::_codecache_GC_threshold);
    }
  }

Here with the limited codecache size, the free_ratio will get lower and lower (so as the threshold) if no methods can be swept and thus leads to a more and more frequent collection behavior. Since the collection happens in stw, the whole performance of gc will also be degraded. 

So a simple solution is to delete the scaling logic here. However, I think here lies some problems worth further exploring.

There're two options to control a code cache sweeper,  StartAggressiveSweepingAt and SweeperThreshold.  StartAggressiveSweepingAt is a sweeper triggered for little space in codeCache and does little harm. However,  SweeperThreshold, first introduced by [JDK-8244660](https://bugs.openjdk.org/browse/JDK-8244660), was designed for a regular sweep for codecache, when codeCache sweeper and heap collection are actually individual. After [JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025) and some patches related, the old mechanism of codeCache sweeper is merged into a concurrent heap collection. So the Code cache sweeper heuristics and the unloading behavior will be promised by the concurrent collection. There's no longer any "zombie" methods to be counted. Considering it will introduce lots of useless collection jobs, I think SweeperThreshold should be deleted now.

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

Commit messages:
 - remove SweeperThreshold and set it to Obselete

Changes: https://git.openjdk.org/jdk/pull/21084/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21084&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340434
  Stats: 55 lines in 14 files changed: 1 ins; 53 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21084/head:pull/21084

PR: https://git.openjdk.org/jdk/pull/21084

From tschatzl at openjdk.org  Wed Feb 19 06:21:33 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Feb 2025 06:21:33 GMT
Subject: RFR: 8340434: Excessive Young GCs Triggered by CodeCache GC
 Threshold
In-Reply-To: <g22FgTJTATrz5UIKsSy3a98OgJIm8hvZ9KFm4u75PyY=.dea7d218-c0d7-43a9-afff-d167383eeb63@github.com>
References: <g22FgTJTATrz5UIKsSy3a98OgJIm8hvZ9KFm4u75PyY=.dea7d218-c0d7-43a9-afff-d167383eeb63@github.com>
Message-ID: <VhKB5YMijnYFr4aLB6gLnxWH6uVivzdVrP2ydOMLOZo=.2cff75e3-bd13-441a-8c3c-199e66c24e6e@github.com>

On Thu, 19 Sep 2024 08:43:50 GMT, sli-x <duke at openjdk.org> wrote:

> Here with the limited codecache size, the free_ratio will get lower and lower (so as the threshold) if no methods can be swept and thus leads to a more and more frequent collection behavior. Since the collection happens in stw, the whole performance of gc will also be degraded.
>
>So a simple solution is to delete the scaling logic here. However, I think here lies some problems worth further exploring.
>
>There're two options to control a code cache sweeper, StartAggressiveSweepingAt and SweeperThreshold. StartAggressiveSweepingAt is a sweeper triggered for little space in codeCache and does little harm. However, SweeperThreshold, first introduced by [JDK-8244660](https://bugs.openjdk.org/browse/JDK-8244660), was designed for a regular sweep for codecache, when codeCache sweeper and heap collection are actually individual. After [JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025) and some patches related, the old mechanism of codeCache sweeper is merged into a concurrent heap collection. So the Code cache sweeper heuristics and the unloading behavior will be promised by the concurrent collection. There's no longer any "zombie" methods to be counted. Considering it will introduce lots of useless collection jobs, I think SweeperThreshold should be deleted now.

I think the general concern presented out by the code

>    // After threshold is reached, scale it by free_ratio so that more aggressive
>    // GC is triggered as we approach code cache exhaustion

is still valid.

How this is implemented also makes somewhat sense: changes are the trigger for collections, allow larger changes before trying to clean out the code cache the emptier the code cache is.

It tries to limit code cache memory usage by increasingly doing more frequent collections the more occupied the code cache becomes, i.e. some kind of backpressure on code cache usage.

Your use case of limiting the code cache size (and setting initial == max) seems to be relatively unusual one to me, and apparently does not fit that model as it seems that you set code cache size close to actual max usage.

Removing `SweepingThreshold` would affect the regular case as well in a significant way (allocate until bumping into the `StartAggressiveSweepingAt`) I do not think removing this part of the heuristic isn't good (or desired at all).

Maybe an alternative could be only not doing this heuristic part in your case; and even then  am not sure that waiting until hitting the `StartAggressiveSweepingAt` threshold is a good idea; it may be too late to avoid disabling the compiler at least temporarily. 
And even then, as long as the memory usage keeps being larger larger than the threshold, this will result in continuous code cache sweeps (_every time_ _any_ memory is allocated in the code cache).

>From the  [JDK-8244660](https://bugs.openjdk.org/browse/JDK-8244660) CR:

> This is because users with different sized code caches might want different thresholds. (Otherwise there would be no way to control the sweepers intensity). 

Which means that one could just take that suggestion literally and not only change the initial/max code cache size but also that threshold in your use case.

Stepping back a little, this situation very much resembles issues with G1's `InitiatingHeapOccupancyPercent` pre [JDK-8136677](https://bugs.openjdk.org/browse/JDK-8136677) where a one-size-fits-all value also did not work, and many many people tuned `InitiatingHeapOccupancyPercent` manually in the past.

Maybe a  similar mechanism at least taking actual code cache allocation rate into account ("when will the current watermark will be hit"?) would be preferable to replace both options (note that since I'm not an expert in code cache, there may be other reasons to clean out the code cache than just occupancy threshold)?

Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/21084#issuecomment-2383475220

From robilad at openjdk.org  Wed Feb 19 06:21:33 2025
From: robilad at openjdk.org (Dalibor Topic)
Date: Wed, 19 Feb 2025 06:21:33 GMT
Subject: RFR: 8340434: Excessive Young GCs Triggered by CodeCache GC
 Threshold
In-Reply-To: <g22FgTJTATrz5UIKsSy3a98OgJIm8hvZ9KFm4u75PyY=.dea7d218-c0d7-43a9-afff-d167383eeb63@github.com>
References: <g22FgTJTATrz5UIKsSy3a98OgJIm8hvZ9KFm4u75PyY=.dea7d218-c0d7-43a9-afff-d167383eeb63@github.com>
Message-ID: <OAjOmnQiWi734OrtK9vs9zyx1VJw5xQMDatdylli1ok=.65168c50-9652-4695-b8ae-9672fce40d39@github.com>

On Thu, 19 Sep 2024 08:43:50 GMT, sli-x <duke at openjdk.org> wrote:

> The trigger of _codecache_GC_threshold in CodeCache::gc_on_allocation is the key to this problem.
> 
> if (used_ratio > threshold) {
>     // After threshold is reached, scale it by free_ratio so that more aggressive
>     // GC is triggered as we approach code cache exhaustion
>     threshold *= free_ratio;
>   }
>   // If code cache has been allocated without any GC at all, let's make sure
>   // it is eventually invoked to avoid trouble.
>   if (allocated_since_last_ratio > threshold) {
>     // In case the GC is concurrent, we make sure only one thread requests the GC.
>     if (Atomic::cmpxchg(&_unloading_threshold_gc_requested, false, true) == false) {
>       log_info(codecache)("Triggering threshold (%.3f%%) GC due to allocating %.3f%% since last unloading (%.3f%% used -> %.3f%% used)",
>                           threshold * 100.0, allocated_since_last_ratio * 100.0, last_used_ratio * 100.0, used_ratio * 100.0);
>       Universe::heap()->collect(GCCause::_codecache_GC_threshold);
>     }
>   }
> 
> Here with the limited codecache size, the free_ratio will get lower and lower (so as the threshold) if no methods can be swept and thus leads to a more and more frequent collection behavior. Since the collection happens in stw, the whole performance of gc will also be degraded. 
> 
> So a simple solution is to delete the scaling logic here. However, I think here lies some problems worth further exploring.
> 
> There're two options to control a code cache sweeper,  StartAggressiveSweepingAt and SweeperThreshold.  StartAggressiveSweepingAt is a sweeper triggered for little space in codeCache and does little harm. However,  SweeperThreshold, first introduced by [JDK-8244660](https://bugs.openjdk.org/browse/JDK-8244660), was designed for a regular sweep for codecache, when codeCache sweeper and heap collection are actually individual. After [JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025) and some patches related, the old mechanism of codeCache sweeper is merged into a concurrent heap collection. So the Code cache sweeper heuristics and the unloading behavior will be promised by the concurrent collection. There's no longer any "zombie" methods to be counted. Considering it will introduce lots of useless collection jobs, I think SweeperThreshold should be deleted now.

Hi, 

please send an e-mail to dalibor.topic at oracle.com so that I can verify your account in Skara.

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

PR Comment: https://git.openjdk.org/jdk/pull/21084#issuecomment-2427338142

From cjplummer at openjdk.org  Wed Feb 19 06:26:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Feb 2025 06:26:53 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2]
In-Reply-To: <ylze0bWymQn8mSKkYLovI7XuHbvnYcUkMuvUe8nqfy4=.32aebd12-3842-415a-a716-b5e029e00b21@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
 <RZakZmEU3nhc0TBHVE_KDstYFPDCw-tLoOiIVxiUzXo=.229940bf-8051-4010-8025-d32a0ce010c9@github.com>
 <ylze0bWymQn8mSKkYLovI7XuHbvnYcUkMuvUe8nqfy4=.32aebd12-3842-415a-a716-b5e029e00b21@github.com>
Message-ID: <C1zl13MTVtsgS7YgFXHwXScu9HIicBqMQO1Koz7igYU=.c2466965-d12c-44d6-ba7b-6b81d43f6444@github.com>

On Wed, 19 Feb 2025 04:31:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/RuntimeStub.java line 47:
>> 
>>> 45:   private static void initialize(TypeDataBase db) {
>>> 46:     Type type = db.lookupType("RuntimeStub");
>>> 47:     callerMustGCArgumentsField = type.getCIntegerField("_caller_must_gc_arguments");
>> 
>> This field is in `CodeBlob` since JDK 23 [JDK-8329433](https://bugs.openjdk.org/browse/JDK-8329433) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeBlob.hpp#L126
>
> Ah, right. I forgot you had mentioned that. I think that means I can rid of RuntimeStub and RuntimeBlob once this code is moved to CodeBlob.

Ready for another review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23684#discussion_r1961019487

From dholmes at openjdk.org  Wed Feb 19 06:31:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Feb 2025 06:31:53 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v2]
In-Reply-To: <E3bUYzjwiPGr_oSTK1IdkQSVkPCF7SHlelgmRkR5Wbw=.d9f1c895-b65d-4384-96fd-9db63c420d16@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <zV5J1Y1GRriBP-m6z_7YOPKcUorVqYpmtYHHuU6pDiw=.de60d651-4c78-44f5-90e5-2f9d621f8e77@github.com>
 <WcYBQ-FvHA0uRRPs4AC69kK03jUtzduwYjHQ0GiVl_4=.86efe5b0-ac74-4703-8f27-c24b6d007436@github.com>
 <pg2Rns4l_RRJPG8F6aZ8oFJwmdEUwKSm27LFo1ZYbXw=.4622a137-f65d-4e03-9e77-d8c94be85269@github.com>
 <zAeXXZW_4kcwsb3KRuM3WtzNxLFg6hxLlGAZrjb5fVM=.4837c962-5da8-4509-86a9-ce9d55c10f53@github.com>
 <tjhqeB9WM0W5lW_zPBmRcWeUbnZHNIbGUVwAz5M2B2w=.c5846c0c-48dc-4ec7-8484-122ffc65b6da@github.com>
 <LTme3fmXgtMsqI9JjpxQRLyj32IrpvS9SLdRbEMh2v0=.b20b88b8-7d2e-47d6-bb39-301cea4c80fe@github.com>
 <E3bUYzjwiPGr_oSTK1IdkQSVkPCF7SHlelgmRkR5Wbw=.d9f1c895-b65d-4384-96fd-9db63c420d16@github.com>
Message-ID: <xwm9Gb4J3buaTEK-it7zYAjHBpr9Mk6Jg1Xtx_XfnMw=.d2d61a24-9825-4ced-a0ef-952b5ad95d9d@github.com>

On Tue, 18 Feb 2025 09:21:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Then, maybe the logic is easier to read if the "atomic" access is visible directly from that context, instead of hiding it inside in_critical. Therefore, it probably makes more sense to introduce a new API. WDYT?

Okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2667619218

From stuefe at openjdk.org  Wed Feb 19 06:38:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 19 Feb 2025 06:38:54 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
Message-ID: <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>

On Tue, 18 Feb 2025 10:07:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> > Hi Thomas, this looks very useful, thanks! I will run some Oracle-internal functional and performance testing and come back with the results next week.
> 
> Functional test results (Oracle internal tier1-tier5) look good.
> 
> I measured C2 execution time before and after the changeset using DaCapo 23 and did not find any statistically significant difference, except for a 2-3% regression on the jython benchmark (using large input size). This small regression is IMO acceptable, particularly given that these changes can be seen as an investment to improve compiler resource utilization in the long run.

Hi @robcasloz, interesting, I did not expect this. What did you measure? With Compilation statistic vs without, or with old vs new, but both enabled? (best, give me both sets of command line args)

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2667627899

From stuefe at openjdk.org  Wed Feb 19 06:44:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 19 Feb 2025 06:44:55 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v2]
In-Reply-To: <feRzRUGP_T89ZWa_OXeG1iEtO4PYk2c7JAirkG1hS6g=.2fcc2820-ac2b-4614-98c2-c34ecef7211f@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <feRzRUGP_T89ZWa_OXeG1iEtO4PYk2c7JAirkG1hS6g=.2fcc2820-ac2b-4614-98c2-c34ecef7211f@github.com>
Message-ID: <7qDiB3QXduIdnc6t-oTxHKT9kbUcwqzELGOSvWcwPAU=.21ade736-8c52-4bbb-b535-30540952a369@github.com>

On Fri, 14 Feb 2025 09:34:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unnecessary copyright change

> > We also save a copy of the counters to a global table that contains the N most expensive compilations. That table will be printed when one uses jcmd  Compiler.memory. We also print it into the hs-err file.
> 
> This is a new tool for me, but I'd appreciate it if there was the equivalent of `PrintNMTStatistics` such that the table produced from the JCmd is also printed on shutdown.
> 
> Edit: print_final_report doesn't support verbosity, that'd be nice to have.

Let's do this in a future RFE, if anyone misses it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2667638346

From kevinw at openjdk.org  Wed Feb 19 09:29:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 19 Feb 2025 09:29:57 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v5]
In-Reply-To: <RclcYW1ejBxBeaXNorFGjX7QHG0_IsiyY_EAReL6IwI=.5cc12370-e9f7-4c63-91ce-3a254a397b0a@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <RclcYW1ejBxBeaXNorFGjX7QHG0_IsiyY_EAReL6IwI=.5cc12370-e9f7-4c63-91ce-3a254a397b0a@github.com>
Message-ID: <qdYBnuyuMnBv9xZT0kj9_BI9XFun85vh8WrCtE7aG5Y=.7108a785-0c3a-4b3d-9eb1-9ab45b03947f@github.com>

On Tue, 18 Feb 2025 23:38:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
>> 
>> Testing:
>> 
>> - [x] Tier1 CI
>> - [x] Tier2 CI svc testing
>> - [x] Tier3 CI svc testing
>> - [x] Tier5 CI svc testing
>> - [x] ran all svc test 10 times each on all supported platforms
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of redundant if

Thanks for the detailed commentary, looks good!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23182#pullrequestreview-2626159402

From rcastanedalo at openjdk.org  Wed Feb 19 09:52:58 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 19 Feb 2025 09:52:58 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
Message-ID: <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>

On Wed, 19 Feb 2025 06:35:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > Hi Thomas, this looks very useful, thanks! I will run some Oracle-internal functional and performance testing and come back with the results next week.
> > 
> > 
> > Functional test results (Oracle internal tier1-tier5) look good.
> > I measured C2 execution time before and after the changeset using DaCapo 23 and did not find any statistically significant difference, except for a 2-3% regression on the jython benchmark (using large input size). This small regression is IMO acceptable, particularly given that these changes can be seen as an investment to improve compiler resource utilization in the long run.
> 
> Hi @robcasloz, interesting, I did not expect this. What did you measure? With Compilation statistic vs without, or with old vs new, but both enabled? (best, give me both sets of command line args)

I measured and compared C2 speed in bytecodes/s as reported by `-XX:+CITime` (averaged over a number of repetitions). I wanted to test that the feature does not affect C2's execution time when not used, so I simply compared C2 compilation speed for `jdk-25+10` vs. `jdk-25+10` with this changeset applied on top (both release builds) and `-XX:+CITime -Xbatch -XX:-TieredCompilation` on both builds (the last two flags for better stability across benchmark repetitions). I could observe the regression on both linux-x64 and macosx-aarch64 platforms. Let me know if you need more details.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2668094516

From nbenalla at openjdk.org  Wed Feb 19 11:05:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 19 Feb 2025 11:05:59 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
 <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>
 <kkbh1U2d4-82E1OOPq_SBkYolMqLmZz68XcT6ThMjEQ=.0e58b6b4-8e95-412e-8d3f-752e7af1a33e@github.com>
Message-ID: <HX3zhtWYlzDwcThjfRfh2UiSgtjvxOyz3lHTM4rr3cw=.98597d31-7abe-40a2-b7bf-36b592597b34@github.com>

On Tue, 18 Feb 2025 23:06:42 GMT, Ian Myers <imyers at openjdk.org> wrote:

>> make/common/Modules.gmk line 95:
>> 
>>> 93: SPEC_SUBDIRS += share/specs
>>> 94: 
>>> 95: MAN_SUBDIRS += share/man windows/man
>> 
>> Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.
>
> Hi @magicus we are seeing build failures because linux builds contain man pages for windows-only tools as reported by https://bugs.openjdk.org/browse/JDK-8350137. Would replacing `windows/man` with `$(TARGET_OS)/man` prevent windows-only tools man pages being generated for linux builds?

I think it will prevent windows-only tools man pages from being generated in linux builds, but it would prevent the man pages from appearing in the generated documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1961472101

From ayang at openjdk.org  Wed Feb 19 13:01:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 19 Feb 2025 13:01:55 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v4]
In-Reply-To: <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
Message-ID: <gdrj_PSWpvYz_ffubVsbRUStlIUY5Ndrl2eCbMGhvco=.5a1b1cb9-3f52-404c-bf46-5170990493b3@github.com>

On Tue, 18 Feb 2025 09:20:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

All suggestions/comments are addressed. Tier1-8 pass. It's ready for another round of review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2668584881

From tschatzl at openjdk.org  Wed Feb 19 15:06:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Feb 2025 15:06:56 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v4]
In-Reply-To: <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
Message-ID: <FKZkKZU9LdlfjcppemPXURTpo7YK-WuS9Hu3NnANkDs=.03f2616b-01ae-4089-91cd-9816540c6cc6@github.com>

On Tue, 18 Feb 2025 09:20:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2627110375

From mbaesken at openjdk.org  Wed Feb 19 15:29:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Feb 2025 15:29:52 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <87xR2Eb1LQv8xMaEtgBrPxSXRqu2w8nN-Mk0eR1f9l8=.a8540364-5915-4ee4-bf00-5b3949bae623@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

So what's the opinion, should we go for SIZE optimization for libjdwp?
My idea was that the current setting LOW indicates that the lib is not super performance critical; so SIZE might be a nice option ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2668985592

From kvn at openjdk.org  Wed Feb 19 15:50:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 19 Feb 2025 15:50:53 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2]
In-Reply-To: <k2NwhUstKFzIbzXfe4SJAmFAlxyaPIjwkkLkxZY48Yo=.c90111cb-d4ee-42dd-8f7c-0e44336351c5@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
 <k2NwhUstKFzIbzXfe4SJAmFAlxyaPIjwkkLkxZY48Yo=.c90111cb-d4ee-42dd-8f7c-0e44336351c5@github.com>
Message-ID: <tO4FssmbxWSLVy3IrFINHgF68lpRkX6GpNXVeCn3AdQ=.9830a250-971c-483a-bc3d-214f5cb42fd3@github.com>

On Wed, 19 Feb 2025 05:49:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also.
>> 
>> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. 
>> 
>> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone):
>> 
>> 
>>   public String getName() {
>>     return "AdapterBlob: " + super.getName();
>>   }
>> 
>> 
>> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type.  I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor improvements.

LGTM

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23684#pullrequestreview-2627250925

From cjplummer at openjdk.org  Wed Feb 19 17:16:59 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Feb 2025 17:16:59 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <87xR2Eb1LQv8xMaEtgBrPxSXRqu2w8nN-Mk0eR1f9l8=.a8540364-5915-4ee4-bf00-5b3949bae623@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <87xR2Eb1LQv8xMaEtgBrPxSXRqu2w8nN-Mk0eR1f9l8=.a8540364-5915-4ee4-bf00-5b3949bae623@github.com>
Message-ID: <6MUqbh3c042uylSdjksS2-5WDHW9xrsduxCZg7Bcbls=.7b2c8e74-8428-46cc-a640-c2a26eb2c92d@github.com>

On Wed, 19 Feb 2025 15:27:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> So what's the opinion, should we go for SIZE optimization for libjdwp?
> My idea was that the current setting LOW indicates that the lib is not super performance critical; so SIZE might be a nice option ?

I'm not sure how the decision was made to go with LOW for libjdwp. Much of what it does is transactional over the wire, so probably not subject much to code performance, but there are some more heavyweight tasks that the debug agent needs to do, especially when dealing with a a large number of threads. I'd like to see those tasks sped up if anything.

It seems LTO would be good to enable regardless of the optimization level. One thing you haven't given numbers for is LTO+HIGH. Based on the other results so far, seems the footprint would be slightly below to the current LOW setting (maybe 3-4k).

When faced with a decision like this that doesn't have concrete data as to what the right choice is, I'd tend to go with the status quo and make no change, although it seems going with LTO should be a good choice no matter the opt level unless there is some other possible negative side affect of doing so that hasn't been brought up.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2669266484

From cjplummer at openjdk.org  Wed Feb 19 17:27:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 19 Feb 2025 17:27:54 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v5]
In-Reply-To: <RclcYW1ejBxBeaXNorFGjX7QHG0_IsiyY_EAReL6IwI=.5cc12370-e9f7-4c63-91ce-3a254a397b0a@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <RclcYW1ejBxBeaXNorFGjX7QHG0_IsiyY_EAReL6IwI=.5cc12370-e9f7-4c63-91ce-3a254a397b0a@github.com>
Message-ID: <B5-pD5VtmeuXvDCsE7sJlH86KrkTw4RADIAIIYgRYYM=.3c2c511a-1f3c-4110-8a8f-401bc4f1ae01@github.com>

On Tue, 18 Feb 2025 23:38:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
>> 
>> Testing:
>> 
>> - [x] Tier1 CI
>> - [x] Tier2 CI svc testing
>> - [x] Tier3 CI svc testing
>> - [x] Tier5 CI svc testing
>> - [x] ran all svc test 10 times each on all supported platforms
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of redundant if

I filed [JDK-8350368](https://bugs.openjdk.org/browse/JDK-8350368) to address the clearStep() locking issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23182#issuecomment-2669296694

From ccheung at openjdk.org  Wed Feb 19 22:41:17 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 19 Feb 2025 22:41:17 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v3]
In-Reply-To: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
Message-ID: <MUCFh_Lqi-I5GjzIhy5SZzhmR8NqNQZaWDX3VtgKG_I=.db53fb81-1714-4d0b-a878-44a52a0a904c@github.com>

> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
> 
> Passed tiers 1 - 5 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @ashu-mehra and @dholmes-ora comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23476/files
  - new: https://git.openjdk.org/jdk/pull/23476/files/01238742..84206edd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=01-02

  Stats: 56 lines in 6 files changed: 40 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23476/head:pull/23476

PR: https://git.openjdk.org/jdk/pull/23476

From ccheung at openjdk.org  Wed Feb 19 22:41:18 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 19 Feb 2025 22:41:18 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v2]
In-Reply-To: <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
 <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
Message-ID: <cxgxOjvKuXwuJyM3lMgIF9qAp8Qx1ze9INDvzIhfTTA=.3284bedd-6f11-4a2d-b36a-ddd578d1b45f@github.com>

On Tue, 18 Feb 2025 07:08:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam and @ashu-mehra comment
>
> src/hotspot/share/cds/aotCodeSource.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> If the code has been moved from other files, the current opinion/consensus is that the first copyright year should be the oldest first year from all the files from which the code was obtained.

Since most of the code and logic are from filemap.[c|h]pp, I've updated the copyright year to 2003, 2025.

> src/hotspot/share/cds/aotCodeSource.cpp line 106:
> 
>> 104:     for (const char* bootcp = Arguments::get_boot_class_path(); *bootcp != '\0'; ++bootcp) {
>> 105:       if (*bootcp == *os::path_separator()) {
>> 106:         ++ bootcp;
> 
> Nit (possibly pre-existing) - no space before/after unary operators

Fixed.

> src/hotspot/share/cds/aotCodeSource.hpp line 125:
> 
>> 123: // during AOTCache creation are the same as when the AOTCache is used during runtime.
>> 124: // Non-existent entries are recorded during AOTCache creation. Those non-existent entries
>> 125: // must not exist during runtime.
> 
> Does this mean that if Foo.jar is on the classpath but does not in fact exist, then we record it was on the classpath and require it to be on the classpath at runtime, but also to still not exist?

Actually, we don't require the non-existent entries to be on the classpath at runtime. The appcds/NonExistClasspath.java test has cases to cover that.
So I've updated the comment as follows:

// Non-existent entries are recorded during AOTCache creation. Those non-existent entries,
// if they are specified at runtime, must not exist.

Also fixed a bug so that the behavior is the same as before this refactoring.

> src/hotspot/share/cds/aotCodeSource.hpp line 128:
> 
>> 126: //
>> 127: // Some details on validation:
>> 128: // - the boot classpath could be appended during runtime if there's no app classpath and
> 
> Suggestion:
> 
> // - the boot classpath can be appended to at runtime if there's no app classpath and no

Fixed.

> src/hotspot/share/cds/aotCodeSource.hpp line 130:
> 
>> 128: // - the boot classpath could be appended during runtime if there's no app classpath and
>> 129: //   module path specified when an AOTCache is created;
>> 130: // - the app classpath could be appended during runtime;
> 
> Suggestion:
> 
> // - the app classpath can be appended to at runtime;

Fixed.

> src/hotspot/share/cds/aotCodeSource.hpp line 131:
> 
>> 129: //   module path specified when an AOTCache is created;
>> 130: // - the app classpath could be appended during runtime;
>> 131: // - the module path during runtime could be a superset of the one specified during AOTCache creation.
> 
> Suggestion:
> 
> // - the module path at runtime can be a superset of the one specified during AOTCache creation.

Fixed.

> test/hotspot/jtreg/runtime/cds/appcds/BootClassPathMismatch.java line 243:
> 
>> 241:      * No error - bootclasspath can be appended during runtime if no -cp is specified.
>> 242:      */
>> 243:     public void testBootClassPathAppend() throws Exception {
> 
> A refactoring should not be introducing new test cases. Did you refactor and enhance?

This is a missing testcase and works the same before and after refactoring.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962467161
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962466958
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962467710
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962467840
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962467951
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962468046
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962468281

From ccheung at openjdk.org  Wed Feb 19 22:41:19 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 19 Feb 2025 22:41:19 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v2]
In-Reply-To: <vZAa9qCp1aLUuUPD8xYcXe24X6zZcY37TQwUx3Q-iZc=.4b1c2427-7165-4f0b-a7a9-bc05de643e5e@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
 <vZAa9qCp1aLUuUPD8xYcXe24X6zZcY37TQwUx3Q-iZc=.4b1c2427-7165-4f0b-a7a9-bc05de643e5e@github.com>
Message-ID: <y3Gt4jcx9N2OwmV5w7ivt8IxAdQJozXTk6Wse0Mgql4=.cbd204ae-c97d-45c4-b5c6-c77d9764f135@github.com>

On Tue, 18 Feb 2025 05:21:09 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam and @ashu-mehra comment
>
> src/hotspot/share/runtime/threads.cpp line 27:
> 
>> 25:  */
>> 26: 
>> 27: #include "cds/aotCodeSource.hpp"
> 
> Why is this include needed?

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962466829

From ccheung at openjdk.org  Wed Feb 19 22:41:19 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 19 Feb 2025 22:41:19 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v3]
In-Reply-To: <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
 <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
Message-ID: <zap_KUD7l_pwYc6dNtXBCY18PKzfxsEQxdW4Ce4ryRw=.f9a38c22-8450-4abc-8bc3-4a7f58b23f1a@github.com>

On Tue, 18 Feb 2025 07:22:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @ashu-mehra and @dholmes-ora comments
>
> src/hotspot/share/runtime/threads.cpp line 809:
> 
>> 807:     vm_exit_during_initialization("ClassLoader::initialize_module_path() failed unexpectedly");
>> 808:   }
>> 809: #endif
> 
> Not obvious where this functionality is now handled.

It is now being handled in `ClassLoaderDataShared::ensure_module_entry_tables_exist()` and `AOTCodeSourceConfig::dumptime_init_helper()`.

> test/hotspot/jtreg/runtime/cds/appcds/NonExistClasspath.java line 70:
> 
>> 68:             .assertNormalExit();
>> 69: 
>> 70:         // Now make nonExistPath exist. CDS will fail to load.
> 
> Not at all clearr why these test cases have been removed?

I've added back the removed test cases to ensure the handling of non-existent entries remains the same after refactoring.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962468145
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962468453

From ccheung at openjdk.org  Thu Feb 20 00:18:36 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 20 Feb 2025 00:18:36 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v4]
In-Reply-To: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
Message-ID: <gNy4Z9os_X175Cy0z7twQ8FfsJtIkjpqGdz5XvP2SWg=.f04d88cb-e636-42f4-8f4a-55be0b863592@github.com>

> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
> 
> Passed tiers 1 - 5 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  new test case in BootClassPathMismatch.java is not applicable to dynamic archive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23476/files
  - new: https://git.openjdk.org/jdk/pull/23476/files/84206edd..c2039929

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=02-03

  Stats: 6 lines in 1 file changed: 5 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23476/head:pull/23476

PR: https://git.openjdk.org/jdk/pull/23476

From ccheung at openjdk.org  Thu Feb 20 00:23:55 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 20 Feb 2025 00:23:55 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v2]
In-Reply-To: <cxgxOjvKuXwuJyM3lMgIF9qAp8Qx1ze9INDvzIhfTTA=.3284bedd-6f11-4a2d-b36a-ddd578d1b45f@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
 <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
 <cxgxOjvKuXwuJyM3lMgIF9qAp8Qx1ze9INDvzIhfTTA=.3284bedd-6f11-4a2d-b36a-ddd578d1b45f@github.com>
Message-ID: <hqb76DCP0QVD_gI1z7VS6RXXT1O8rL0fq4FD8jfocyI=.ba992524-3779-487c-b228-2d377a476fa1@github.com>

On Wed, 19 Feb 2025 22:37:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/BootClassPathMismatch.java line 243:
>> 
>>> 241:      * No error - bootclasspath can be appended during runtime if no -cp is specified.
>>> 242:      */
>>> 243:     public void testBootClassPathAppend() throws Exception {
>> 
>> A refactoring should not be introducing new test cases. Did you refactor and enhance?
>
> This is a missing testcase and works the same before and after refactoring.

I needed to exclude the new test from running in the dynamic archive mode because there's no -cp specified during dumping. Otherwise, the test fails with`java.lang.RuntimeException: test.dynamic.dump is not supported with an empty classpath while the classlist is not empty`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962568623

From kvn at openjdk.org  Thu Feb 20 00:38:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Feb 2025 00:38:54 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v4]
In-Reply-To: <gNy4Z9os_X175Cy0z7twQ8FfsJtIkjpqGdz5XvP2SWg=.f04d88cb-e636-42f4-8f4a-55be0b863592@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <gNy4Z9os_X175Cy0z7twQ8FfsJtIkjpqGdz5XvP2SWg=.f04d88cb-e636-42f4-8f4a-55be0b863592@github.com>
Message-ID: <Usca2OM6mNqektz4pfFFaPGhL7QsL0f2beau4VzSq6c=.5407bfe4-b5e1-44a5-bf11-39e094e4a2ab@github.com>

On Thu, 20 Feb 2025 00:18:36 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
>> 
>> Passed tiers 1 - 5 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new test case in BootClassPathMismatch.java is not applicable to dynamic archive

Passing by comment. We touched it on recent Leyden meeting. The name "AOTCodeSource" is very confusing. Especially when we start caching AOT compiled code. Can we rename it to avoid confusion?

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

PR Comment: https://git.openjdk.org/jdk/pull/23476#issuecomment-2670095758

From dholmes at openjdk.org  Thu Feb 20 02:17:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Feb 2025 02:17:57 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v4]
In-Reply-To: <zap_KUD7l_pwYc6dNtXBCY18PKzfxsEQxdW4Ce4ryRw=.f9a38c22-8450-4abc-8bc3-4a7f58b23f1a@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
 <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
 <zap_KUD7l_pwYc6dNtXBCY18PKzfxsEQxdW4Ce4ryRw=.f9a38c22-8450-4abc-8bc3-4a7f58b23f1a@github.com>
Message-ID: <DcYmVvslOVu_D23KD5i7ZzIYxL6_EIvE4fSpfhuaiqI=.d796426d-fcff-4172-b5f3-be7178b8b3d4@github.com>

On Wed, 19 Feb 2025 22:37:48 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 809:
>> 
>>> 807:     vm_exit_during_initialization("ClassLoader::initialize_module_path() failed unexpectedly");
>>> 808:   }
>>> 809: #endif
>> 
>> Not obvious where this functionality is now handled.
>
> It is now being handled in `ClassLoaderDataShared::ensure_module_entry_tables_exist()` and `AOTCodeSourceConfig::dumptime_init_helper()`.

I don't see anything there that does a vm_exit if something has gone wrong. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962759081

From ccheung at openjdk.org  Thu Feb 20 07:13:55 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 20 Feb 2025 07:13:55 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v4]
In-Reply-To: <DcYmVvslOVu_D23KD5i7ZzIYxL6_EIvE4fSpfhuaiqI=.d796426d-fcff-4172-b5f3-be7178b8b3d4@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
 <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
 <zap_KUD7l_pwYc6dNtXBCY18PKzfxsEQxdW4Ce4ryRw=.f9a38c22-8450-4abc-8bc3-4a7f58b23f1a@github.com>
 <DcYmVvslOVu_D23KD5i7ZzIYxL6_EIvE4fSpfhuaiqI=.d796426d-fcff-4172-b5f3-be7178b8b3d4@github.com>
Message-ID: <NO7FBn_NqC2VD91eGuXzfcQC0MEp4UDRfFuKlweNUFE=.06314d9c-f35c-408a-9aa3-127b7f0b31d8@github.com>

On Thu, 20 Feb 2025 02:15:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It is now being handled in `ClassLoaderDataShared::ensure_module_entry_tables_exist()` and `AOTCodeSourceConfig::dumptime_init_helper()`.
>
> I don't see anything there that does a vm_exit if something has gone wrong. ??

How about adding the vm_exit in `ClassLoaderDataShared::ensure_module_entry_table_exist()` instead of assert?


void ClassLoaderDataShared::ensure_module_entry_table_exist(oop class_loader) {
  Handle h_loader(JavaThread::current(), class_loader);
  ModuleEntryTable* met = Modules::get_module_entry_table(h_loader);
  if (met == nullptr) {
    vm_exit_during_initialization("ClassLoaderDataShared::ensure_module_entry_table_exist() failed unexpectedly");
  }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962972927

From dholmes at openjdk.org  Thu Feb 20 07:31:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Feb 2025 07:31:57 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v4]
In-Reply-To: <NO7FBn_NqC2VD91eGuXzfcQC0MEp4UDRfFuKlweNUFE=.06314d9c-f35c-408a-9aa3-127b7f0b31d8@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
 <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
 <zap_KUD7l_pwYc6dNtXBCY18PKzfxsEQxdW4Ce4ryRw=.f9a38c22-8450-4abc-8bc3-4a7f58b23f1a@github.com>
 <DcYmVvslOVu_D23KD5i7ZzIYxL6_EIvE4fSpfhuaiqI=.d796426d-fcff-4172-b5f3-be7178b8b3d4@github.com>
 <NO7FBn_NqC2VD91eGuXzfcQC0MEp4UDRfFuKlweNUFE=.06314d9c-f35c-408a-9aa3-127b7f0b31d8@github.com>
Message-ID: <Zdap1UiKGXce_E_WAtnApHir_DDGab9HDCkUAxAcPw8=.cdfef0db-f5a8-44a4-9462-8fbc0c565ab4@github.com>

On Thu, 20 Feb 2025 07:11:19 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> I don't see anything there that does a vm_exit if something has gone wrong. ??
>
> How about adding the vm_exit in `ClassLoaderDataShared::ensure_module_entry_table_exist()` instead of assert?
> 
> 
> void ClassLoaderDataShared::ensure_module_entry_table_exist(oop class_loader) {
>   Handle h_loader(JavaThread::current(), class_loader);
>   ModuleEntryTable* met = Modules::get_module_entry_table(h_loader);
>   if (met == nullptr) {
>     vm_exit_during_initialization("ClassLoaderDataShared::ensure_module_entry_table_exist() failed unexpectedly");
>   }
> }

I can't answer that. As a refactoring I expect to see the current behaviour preserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1962992658

From stuefe at openjdk.org  Thu Feb 20 12:41:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 20 Feb 2025 12:41:40 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v3]
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <fGc_LQClk9CeGtupQXwsLfnUjqlQ1UaFGjVAtja5NJQ=.b52171aa-2894-42c0-9c55-bdab3ccc1bc0@github.com>

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - avoid Thread::current in high traffic chunk alloc path
 - move TracePhase counter initialization into conditional path
 - Merge branch 'master' into JDK-8344009-Improve-Compiler-memstat
 - revert unnecessary copyright change
 - more code grooming and comments
 - grooming
 - wip
 - Improved compiler memory statistics

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23530/files
  - new: https://git.openjdk.org/jdk/pull/23530/files/4f426160..08308e9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=01-02

  Stats: 10793 lines in 456 files changed: 7069 ins; 1840 del; 1884 mod
  Patch: https://git.openjdk.org/jdk/pull/23530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23530/head:pull/23530

PR: https://git.openjdk.org/jdk/pull/23530

From stuefe at openjdk.org  Thu Feb 20 13:14:34 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 20 Feb 2025 13:14:34 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  avoid Thread::current in high traffic chunk alloc path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23530/files
  - new: https://git.openjdk.org/jdk/pull/23530/files/08308e9e..dd7a06ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=02-03

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23530/head:pull/23530

PR: https://git.openjdk.org/jdk/pull/23530

From mbaesken at openjdk.org  Thu Feb 20 13:35:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Feb 2025 13:35:52 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <6MUqbh3c042uylSdjksS2-5WDHW9xrsduxCZg7Bcbls=.7b2c8e74-8428-46cc-a640-c2a26eb2c92d@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <87xR2Eb1LQv8xMaEtgBrPxSXRqu2w8nN-Mk0eR1f9l8=.a8540364-5915-4ee4-bf00-5b3949bae623@github.com>
 <6MUqbh3c042uylSdjksS2-5WDHW9xrsduxCZg7Bcbls=.7b2c8e74-8428-46cc-a640-c2a26eb2c92d@github.com>
Message-ID: <vRuYr-EclorQhOF0Np8HiABIMiCMf3xNWzOIDT9FSjE=.b05a9c6b-7930-4d19-8b1c-34923b8699b0@github.com>

On Wed, 19 Feb 2025 17:12:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm not sure how the decision was made to go with LOW for libjdwp. 

>From what I heard from Magnus, those settings were done ages ago , before recent compiler switches and even before the current build system was introduced.

We switched in the meantime from gcc 11.3 to gcc 13.2 in our buildenv .
libjdwp.so / debuginfo is  with opt
SIZE -  264K  /  1.7M 
current NORM/LOW  - 304k / 1.9M

LTO with the patch as given above - 300K
LTO and also BUILDLIBJDWP opt set to HIGH - 328K

So for gcc13.2 with lto enabled (300K) , the lib size gets slightly larger compared to gcc 11.3 with lto enabled (280K).

> It seems LTO would be good to enable regardless of the optimization level. 

Unfortunately I think we do not have many benchmarks for the JDK native libs, or maybe I am not aware of them ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2671513995

From stuefe at openjdk.org  Thu Feb 20 13:56:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 20 Feb 2025 13:56:00 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
 <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
Message-ID: <UsbqibQ8MQcPxnxnYrGzwBZ3y_oOofIlE0gsPd90hvY=.47604844-d0cb-4986-a511-6e569ddd4d36@github.com>

On Wed, 19 Feb 2025 09:49:54 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>>> > Hi Thomas, this looks very useful, thanks! I will run some Oracle-internal functional and performance testing and come back with the results next week.
>>> 
>>> Functional test results (Oracle internal tier1-tier5) look good.
>>> 
>>> I measured C2 execution time before and after the changeset using DaCapo 23 and did not find any statistically significant difference, except for a 2-3% regression on the jython benchmark (using large input size). This small regression is IMO acceptable, particularly given that these changes can be seen as an investment to improve compiler resource utilization in the long run.
>> 
>> Hi @robcasloz, interesting, I did not expect this. What did you measure? With Compilation statistic vs without, or with old vs new, but both enabled? (best, give me both sets of command line args)
>
>> > > Hi Thomas, this looks very useful, thanks! I will run some Oracle-internal functional and performance testing and come back with the results next week.
>> > 
>> > 
>> > Functional test results (Oracle internal tier1-tier5) look good.
>> > I measured C2 execution time before and after the changeset using DaCapo 23 and did not find any statistically significant difference, except for a 2-3% regression on the jython benchmark (using large input size). This small regression is IMO acceptable, particularly given that these changes can be seen as an investment to improve compiler resource utilization in the long run.
>> 
>> Hi @robcasloz, interesting, I did not expect this. What did you measure? With Compilation statistic vs without, or with old vs new, but both enabled? (best, give me both sets of command line args)
> 
> I measured and compared C2 speed in bytecodes/s as reported by `-XX:+CITime` (averaged over a number of repetitions). I wanted to test that the feature does not affect C2's execution time when not used, so I simply compared C2 compilation speed for `jdk-25+10` vs. `jdk-25+10` with this changeset applied on top (both release builds) and `-XX:+CITime -Xbatch -XX:-TieredCompilation` on both builds (the last two flags for better stability across benchmark repetitions). I could observe the regression on both linux-x64 and macosx-aarch64 platforms. Let me know if you need more details.

@robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.

With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2671563378

From rcastanedalo at openjdk.org  Thu Feb 20 14:02:53 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 20 Feb 2025 14:02:53 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
 <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
Message-ID: <0wHGNSlwe7cWb7Plad2n8Swy8rayYTAf5IETuw9zl4U=.a4d6a129-aebc-4639-aaef-92ee6c4552c7@github.com>

On Wed, 19 Feb 2025 09:49:54 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>>> > Hi Thomas, this looks very useful, thanks! I will run some Oracle-internal functional and performance testing and come back with the results next week.
>>> 
>>> Functional test results (Oracle internal tier1-tier5) look good.
>>> 
>>> I measured C2 execution time before and after the changeset using DaCapo 23 and did not find any statistically significant difference, except for a 2-3% regression on the jython benchmark (using large input size). This small regression is IMO acceptable, particularly given that these changes can be seen as an investment to improve compiler resource utilization in the long run.
>> 
>> Hi @robcasloz, interesting, I did not expect this. What did you measure? With Compilation statistic vs without, or with old vs new, but both enabled? (best, give me both sets of command line args)
>
>> > > Hi Thomas, this looks very useful, thanks! I will run some Oracle-internal functional and performance testing and come back with the results next week.
>> > 
>> > 
>> > Functional test results (Oracle internal tier1-tier5) look good.
>> > I measured C2 execution time before and after the changeset using DaCapo 23 and did not find any statistically significant difference, except for a 2-3% regression on the jython benchmark (using large input size). This small regression is IMO acceptable, particularly given that these changes can be seen as an investment to improve compiler resource utilization in the long run.
>> 
>> Hi @robcasloz, interesting, I did not expect this. What did you measure? With Compilation statistic vs without, or with old vs new, but both enabled? (best, give me both sets of command line args)
> 
> I measured and compared C2 speed in bytecodes/s as reported by `-XX:+CITime` (averaged over a number of repetitions). I wanted to test that the feature does not affect C2's execution time when not used, so I simply compared C2 compilation speed for `jdk-25+10` vs. `jdk-25+10` with this changeset applied on top (both release builds) and `-XX:+CITime -Xbatch -XX:-TieredCompilation` on both builds (the last two flags for better stability across benchmark repetitions). I could observe the regression on both linux-x64 and macosx-aarch64 platforms. Let me know if you need more details.

> @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
> 
> With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.

Great, thanks! Will re-run benchmarking and report results early next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2671587462

From sgehwolf at openjdk.org  Thu Feb 20 14:22:20 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 20 Feb 2025 14:22:20 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v16]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <u5zEdl0x1vOXu2aa3xhsrfg3FZ58oBT08jvalZU9YW0=.2a829b23-b21b-4ec4-b934-816c56d2952a@github.com>

> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
> 
> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
> 
> This patch addresses this issue by:
> 
> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
> 
> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
> 
> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
> 
> Thoughts?
> 
> Testing:
> 
> - [x] GHA
> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
> - [x] Some manual testing using systemd slices

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Fix missing imports
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Add exclusive access dirs directive for systemd tests
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - ... and 32 more: https://git.openjdk.org/jdk/compare/e1d0a9c8...74abae5b

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

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=15
  Stats: 1621 lines in 27 files changed: 1373 ins; 152 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/20280.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280

PR: https://git.openjdk.org/jdk/pull/20280

From cjplummer at openjdk.org  Thu Feb 20 16:27:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Feb 2025 16:27:19 GMT
Subject: RFR: 8328866: Add raw monitor rank support to the debug agent
 [v13]
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <zVnYbgaYn-jEX0Q1nMMDYeJ2RqhOt-mdZjQOeKdU7PU=.f3b13fed-71d8-4e07-b810-9d6732304ea2@github.com>

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - merge
 - add newline before dumping raw monitors
 - Dump raw monitors as part of JVMTI DataDumpRequest event
 - Merge
 - Fix some rank orders after merge with 8332738.
 - tweak to raw monitor dump output
 - Merge
 - Fix a couple of minor typos in comments.
 - Simplify by getting rid of special logic around leaf monitors.
 - Flip rank order. Some cleanup and better comments for verifyMonitorRank().
 - ... and 14 more: https://git.openjdk.org/jdk/compare/53db5764...f1105055

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

Changes: https://git.openjdk.org/jdk/pull/19044/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19044&range=12
  Stats: 607 lines in 11 files changed: 544 ins; 2 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/19044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19044/head:pull/19044

PR: https://git.openjdk.org/jdk/pull/19044

From schernyshev at openjdk.org  Thu Feb 20 17:16:56 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 20 Feb 2025 17:16:56 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <odVIQQDcyKJtY-WCiVhkFgwVDn_BwD0PLMqz6sEscHw=.19efc5b7-a33a-4e10-b624-037b5cba6e98@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <odVIQQDcyKJtY-WCiVhkFgwVDn_BwD0PLMqz6sEscHw=.19efc5b7-a33a-4e10-b624-037b5cba6e98@github.com>
Message-ID: <kcAMTV-WogoDKxJJl-G5RlveHsMmRgHD8-ruClXQLRQ=.11dcd8e3-50a3-4648-8cf0-79bbcceb4795@github.com>

On Mon, 17 Feb 2025 15:48:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added details in the log message
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2SubsystemController.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.
> 
> You did not touch the test but change the COPYRIGHT year, why ?

Hi Matthias, thanks for spotting this. This is the leftover from the previous version of the patch. I'll remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1964037810

From schernyshev at openjdk.org  Thu Feb 20 17:29:37 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 20 Feb 2025 17:29:37 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v12]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <pCE3R1bagrzvun1a0BwoJ2DBo0GsHHUAIXgDKcFVY6Q=.ec8dc9cc-0dfb-4fda-b11b-787a4d664e14@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/a3002a92..39f44e92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=10-11

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Thu Feb 20 17:32:32 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 20 Feb 2025 17:32:32 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v13]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <_60M7CyqmgwYG1XOgkI-IGVqFCv9ZKW3oHFnwLiKUGA=.53db28b3-5c41-45f8-a198-f93bd03d8e85@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  revert header change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/39f44e92..8e8ab869

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Thu Feb 20 17:36:04 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 20 Feb 2025 17:36:04 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
Message-ID: <OObfj4QWk_Q3Fk2-mDJbpfeFNhOAbgEmDB-IBehjR4c=.672abfeb-fc3f-4c68-ad0d-693ac0eb7bcd@github.com>

On Mon, 17 Feb 2025 11:09:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added details in the log message
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 73:
> 
>> 71:                                 break;
>> 72:                             }
>> 73:                             cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of("");
> 
> Suggestion:
> 
>                             cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of("");

Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1964064662

From acobbs at openjdk.org  Thu Feb 20 21:05:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 20 Feb 2025 21:05:22 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions that
 lose information
Message-ID: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>

This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.

I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!

Currently, we generate this warning, but only for assignment operators, e.g.:

int x = 0;
x += 1.0f;   // warning here


This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:

void method(float f) { }
...
float a = 0x10000001;   // warning here
method(0x10000001);     // warning here


It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:

float f1 = 0x10000000;     // no warning here

The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.

As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:


float a = (float)0x10000001;   // no warning here

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

Commit messages:
 - Warn for more widening primitive conversions that lose information.

Changes: https://git.openjdk.org/jdk/pull/23718/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23718&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8261669
  Stats: 187 lines in 15 files changed: 149 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/23718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23718/head:pull/23718

PR: https://git.openjdk.org/jdk/pull/23718

From cjplummer at openjdk.org  Thu Feb 20 21:41:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Feb 2025 21:41:52 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <LBFFxYmwxq0HGPZ589bw35LgpJnR6a5gvlhvJkg5sRs=.45fb2bd3-d674-469a-8038-101b2086b831@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

I just don't feel comfortable tinkering with the flags in this manner when we aren't sure of the potential performance impact. The footprint improvement is somewhat negligible in the big picture.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2672745473

From sspitsyn at openjdk.org  Fri Feb 21 06:17:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Feb 2025 06:17:01 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2]
In-Reply-To: <k2NwhUstKFzIbzXfe4SJAmFAlxyaPIjwkkLkxZY48Yo=.c90111cb-d4ee-42dd-8f7c-0e44336351c5@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
 <k2NwhUstKFzIbzXfe4SJAmFAlxyaPIjwkkLkxZY48Yo=.c90111cb-d4ee-42dd-8f7c-0e44336351c5@github.com>
Message-ID: <2CJil-5PMv-VPzBH_Otga48W7AGMybgy0Kr8_XIztJY=.36640c32-77af-4166-96be-488784190ff3@github.com>

On Wed, 19 Feb 2025 05:49:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also.
>> 
>> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. 
>> 
>> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone):
>> 
>> 
>>   public String getName() {
>>     return "AdapterBlob: " + super.getName();
>>   }
>> 
>> 
>> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type.  I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor improvements.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23684#pullrequestreview-2632089455

From ccheung at openjdk.org  Fri Feb 21 06:19:55 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 21 Feb 2025 06:19:55 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v5]
In-Reply-To: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
Message-ID: <MlWig0TFj-P1lEmXY02h3pXpUizN-4WSJz8fi3Q1wBY=.2ff71fae-ba10-485d-bdb3-3c7872af58f9@github.com>

> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
> 
> Passed tiers 1 - 5 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  rename classes and add vm_exit_during_initialization call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23476/files
  - new: https://git.openjdk.org/jdk/pull/23476/files/c2039929..9e4e33dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=03-04

  Stats: 2603 lines in 15 files changed: 1268 ins; 1261 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/23476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23476/head:pull/23476

PR: https://git.openjdk.org/jdk/pull/23476

From ccheung at openjdk.org  Fri Feb 21 06:19:55 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 21 Feb 2025 06:19:55 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v4]
In-Reply-To: <Usca2OM6mNqektz4pfFFaPGhL7QsL0f2beau4VzSq6c=.5407bfe4-b5e1-44a5-bf11-39e094e4a2ab@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <gNy4Z9os_X175Cy0z7twQ8FfsJtIkjpqGdz5XvP2SWg=.f04d88cb-e636-42f4-8f4a-55be0b863592@github.com>
 <Usca2OM6mNqektz4pfFFaPGhL7QsL0f2beau4VzSq6c=.5407bfe4-b5e1-44a5-bf11-39e094e4a2ab@github.com>
Message-ID: <Rvef83fXSjr5XiqwW-5k2KK9HqIbrT3zrv3PVCDu4ow=.0333ed37-b38e-441f-9ee9-5685a5f359d7@github.com>

On Thu, 20 Feb 2025 00:35:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Passing by comment. We touched it on recent Leyden meeting. The name "AOTCodeSource" is very confusing. Especially when we start caching AOT compiled code. Can we rename it to avoid confusion?

Per our discussions, I've renamed "AOTCodeSource" to "AOTClassLocation". I also renamed the related classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/23476#issuecomment-2673567780

From ccheung at openjdk.org  Fri Feb 21 06:19:56 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 21 Feb 2025 06:19:56 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v5]
In-Reply-To: <Zdap1UiKGXce_E_WAtnApHir_DDGab9HDCkUAxAcPw8=.cdfef0db-f5a8-44a4-9462-8fbc0c565ab4@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <SIzVe_N4MeTrW_A3gGoGpmYsrYoi8AZNJJRNX7ykdTY=.6b5fd0d0-5a43-4efd-8259-65d771178fe5@github.com>
 <_9GFraN7--YUC8esAB28iHzdRC7eYJok355TpDH7Df8=.30548f08-454f-47ba-83d5-a4feabaee9ff@github.com>
 <zap_KUD7l_pwYc6dNtXBCY18PKzfxsEQxdW4Ce4ryRw=.f9a38c22-8450-4abc-8bc3-4a7f58b23f1a@github.com>
 <DcYmVvslOVu_D23KD5i7ZzIYxL6_EIvE4fSpfhuaiqI=.d796426d-fcff-4172-b5f3-be7178b8b3d4@github.com>
 <NO7FBn_NqC2VD91eGuXzfcQC0MEp4UDRfFuKlweNUFE=.06314d9c-f35c-408a-9aa3-127b7f0b31d8@github.com>
 <Zdap1UiKGXce_E_WAtnApHir_DDGab9HDCkUAxAcPw8=.cdfef0db-f5a8-44a4-9462-8fbc0c565ab4@github.com>
Message-ID: <ynfnAhsOk3v90K8ErBNM9RR3fRB3EXT3gJseUtQWSJI=.27c49d04-515b-4e6e-837c-6ee13103c9bc@github.com>

On Thu, 20 Feb 2025 07:29:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> How about adding the vm_exit in `ClassLoaderDataShared::ensure_module_entry_table_exist()` instead of assert?
>> 
>> 
>> void ClassLoaderDataShared::ensure_module_entry_table_exist(oop class_loader) {
>>   Handle h_loader(JavaThread::current(), class_loader);
>>   ModuleEntryTable* met = Modules::get_module_entry_table(h_loader);
>>   if (met == nullptr) {
>>     vm_exit_during_initialization("ClassLoaderDataShared::ensure_module_entry_table_exist() failed unexpectedly");
>>   }
>> }
>
> I can't answer that. As a refactoring I expect to see the current behaviour preserved.

After discussion with Ioi, we found a place to call the vm_exit function:


void AOTClassLocationConfig::dumptime_init(JavaThread* current) {
  assert(CDSConfig::is_dumping_archive(), "");
  _dumptime_instance = NEW_C_HEAP_OBJ(AOTClassLocationConfig, mtClassShared);
  _dumptime_instance->dumptime_init_helper(current);
  if (current->has_pending_exception()) {
    // we can get an exception only when we run out of metaspace, but that
    // shouldn't happen this early in bootstrap.
    java_lang_Throwable::print(current->pending_exception(), tty);
    vm_exit_during_initialization("AOTClassLocationConfig::dumptime_init_helper() failed unexpectedly");
  }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1964907863

From sspitsyn at openjdk.org  Fri Feb 21 06:30:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Feb 2025 06:30:59 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v2]
In-Reply-To: <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
Message-ID: <rYBB2a46pNGzfXv47lsnd8DovngQpgqjj6qnwx6X_FA=.2fb759c4-949b-41e1-b9ae-9e31b8d3d3dd@github.com>

On Thu, 13 Feb 2025 12:30:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
>> 
>> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - comments
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - (c)
>  - typo
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - Also XMLParseException
>  - RMMB comment update
>  - Deprecate XML interchange in DescriptorSupport

This fix looks okay. Posted one question though.

src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 977:

> 975:      * construction fails for any reason, this exception will be
> 976:      * thrown.
> 977:      * @deprecated This constructor exists for historical reasons.  If

Q: This is not constructor, right?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23038#pullrequestreview-2632098127
PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1964914802

From sspitsyn at openjdk.org  Fri Feb 21 06:38:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Feb 2025 06:38:56 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v2]
In-Reply-To: <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
Message-ID: <mAnzfi73_tAi4R593t0bPfeE8Jog_0GGyT3mzCxdjes=.c5136d73-482d-4c2c-b0c8-ba4507fd2ef5@github.com>

On Thu, 13 Feb 2025 12:30:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
>> 
>> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - comments
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - (c)
>  - typo
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - Also XMLParseException
>  - RMMB comment update
>  - Deprecate XML interchange in DescriptorSupport

src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 1170:

> 1168:                 " with arg: <" + s + ">";
> 1169:             throw new XMLParseException(e, msg);
> 1170:             // XMLParseException is deprecated for removal.

Q: Non-deprecated method will be using the deprecated class `XMLParseException`. What is the plan for replacement? Should this be fixed now? The same question for the line 1160.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1964928958

From mbaesken at openjdk.org  Fri Feb 21 07:53:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Feb 2025 07:53:53 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <LBFFxYmwxq0HGPZ589bw35LgpJnR6a5gvlhvJkg5sRs=.45fb2bd3-d674-469a-8038-101b2086b831@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <LBFFxYmwxq0HGPZ589bw35LgpJnR6a5gvlhvJkg5sRs=.45fb2bd3-d674-469a-8038-101b2086b831@github.com>
Message-ID: <AoiE6dtloSKurgmG03hkkGDxY3ZcUFVDYDMxzJVkJ38=.84000b42-522a-4824-83fe-98c7e32371cc@github.com>

On Thu, 20 Feb 2025 21:39:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I just don't feel comfortable tinkering with the flags in this manner when we aren't sure of the potential performance impact. The footprint improvement is somewhat negligible in the big picture.

Without good benchmarks it is hard to say. But this is true also for the current 'LOW' opt setting that was available since jdk9 at least (probably much longer)
https://github.com/AdoptOpenJDK/openjdk-jdk9/blob/f00b63d24697cce8067f468fe6cd8510374a46f5/jdk/make/lib/Lib-jdk.jdwp.agent.gmk#L80
and in the meantime there were quite a few compiler updates.
Probably we could look at the performance of related jtreg tests so spot bad performance degradations.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2673828187

From mbaesken at openjdk.org  Fri Feb 21 08:35:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Feb 2025 08:35:53 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <u_10Zet8fQY_JZZdCJ7W8LqAC-VyslvL5K692lNb_g4=.8af82114-dcfa-41e1-a93c-4dcba4022ff1@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

Btw. regarding footprint improvement, for some vendors it seems to be important, see 'Liberica JDK Lite' 
https://docs.bell-sw.com/liberica-jdk/latest/how-to/choosing-flavor/
(however I couldn't figure out from the page if they apply LTO on all native libs or only libjvm)

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2673903035

From dfuchs at openjdk.org  Fri Feb 21 09:32:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Feb 2025 09:32:57 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v2]
In-Reply-To: <mAnzfi73_tAi4R593t0bPfeE8Jog_0GGyT3mzCxdjes=.c5136d73-482d-4c2c-b0c8-ba4507fd2ef5@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
 <mAnzfi73_tAi4R593t0bPfeE8Jog_0GGyT3mzCxdjes=.c5136d73-482d-4c2c-b0c8-ba4507fd2ef5@github.com>
Message-ID: <ktNPuQIEuqRFlY-5b36M-q6696Xazlev7hYfjkWFB3s=.30a2c551-03e9-4d3c-b98a-a01c04acd0ea@github.com>

On Fri, 21 Feb 2025 06:36:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - comments
>>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>>  - (c)
>>  - typo
>>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>>  - Also XMLParseException
>>  - RMMB comment update
>>  - Deprecate XML interchange in DescriptorSupport
>
> src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 1170:
> 
>> 1168:                 " with arg: <" + s + ">";
>> 1169:             throw new XMLParseException(e, msg);
>> 1170:             // XMLParseException is deprecated for removal.
> 
> Q: Non-deprecated method will be using the deprecated class `XMLParseException`. What is the plan for replacement? Should this be fixed now? The same question for the line 1160.

Aside from the public deprecated API, the only places where this exception is used is in private static methods that support the implementation of the deprecated constructor, so these will go away when the constructor is eventually removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1965157527

From dfuchs at openjdk.org  Fri Feb 21 09:39:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Feb 2025 09:39:56 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v2]
In-Reply-To: <ktNPuQIEuqRFlY-5b36M-q6696Xazlev7hYfjkWFB3s=.30a2c551-03e9-4d3c-b98a-a01c04acd0ea@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
 <mAnzfi73_tAi4R593t0bPfeE8Jog_0GGyT3mzCxdjes=.c5136d73-482d-4c2c-b0c8-ba4507fd2ef5@github.com>
 <ktNPuQIEuqRFlY-5b36M-q6696Xazlev7hYfjkWFB3s=.30a2c551-03e9-4d3c-b98a-a01c04acd0ea@github.com>
Message-ID: <Vt1B6Abl5sqebc_509HgQNoOn98919cl0SRwKL2fkdA=.a7fe6de2-c664-4289-80c3-759f9d9a04a9@github.com>

On Fri, 21 Feb 2025 09:30:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 1170:
>> 
>>> 1168:                 " with arg: <" + s + ">";
>>> 1169:             throw new XMLParseException(e, msg);
>>> 1170:             // XMLParseException is deprecated for removal.
>> 
>> Q: Non-deprecated method will be using the deprecated class `XMLParseException`. What is the plan for replacement? Should this be fixed now? The same question for the line 1160.
>
> Aside from the public deprecated API, the only places where this exception is used is in private static methods that support the implementation of the deprecated constructor, so these will go away when the constructor is eventually removed.

But the question is interesting. There could be code out there that instantiate and throws this exception for its own purpose. Or that tries to catch it, or instanceof it... Maybe we should let it linger longer than the associated API that throws it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1965166254

From kvn at openjdk.org  Fri Feb 21 18:31:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 21 Feb 2025 18:31:59 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v5]
In-Reply-To: <MlWig0TFj-P1lEmXY02h3pXpUizN-4WSJz8fi3Q1wBY=.2ff71fae-ba10-485d-bdb3-3c7872af58f9@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <MlWig0TFj-P1lEmXY02h3pXpUizN-4WSJz8fi3Q1wBY=.2ff71fae-ba10-485d-bdb3-3c7872af58f9@github.com>
Message-ID: <xxRa8y59QowesVv03rgSOVwbP576-DOs3mXnpQ3QOJA=.b4129f55-1ee4-4cf6-b03e-80d144e00acf@github.com>

On Fri, 21 Feb 2025 06:19:55 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
>> 
>> Passed tiers 1 - 5 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename classes and add vm_exit_during_initialization call

Thank you for renaming classes.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23476#pullrequestreview-2633908080

From cjplummer at openjdk.org  Fri Feb 21 19:09:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Feb 2025 19:09:54 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <6c5zel9raqIdkgXvw0LqZbqYKHQfFcpRuqo8rUmH_7I=.3870c21d-7c90-4ab8-b125-2b921de883f8@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

When minimalVM support was added, before the current configure based build system, choosing minmalVM did two things: it omitted some hotspot features from the JVM (like JVMTI, and libjdwp.so as a consequence) and it compiled many files with Os instead of O2 or O3. I think it still works like that with the current build system, but I'm not certain. A lot of benchmarking was done to avoid using Os for files that were important for overall performance, but some performance impact was allowed. After all, choosing minimalVM was in part a size vs performance choice, so having some performance hit in order to reduce the size was acceptable. We just tried to minimize the performance lost by being smart about which files were compiled with -Os.

My point here is that if you want small footprint, you can choose that, and expect some performance hit as a result, but this footprint/performance choice should be just that, a choice (like choosing minimalVM). You are suggesting potentially sacrificing some performance for reduced footprint (and a tiny footprint reduction at that) without it being a choice.

Yes, Liberica does care about footprint, but they are making sacrifices to reduce the footprint because they have small footprint goals that in part outweigh some performance or functionality goals. This is akin to the minimalVM approach. If anything, useful build system support for Liberica would come in the way of making it configurable whether libjdwp.so (and other libs) are built for size or built for performance.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2675333759

From cjplummer at openjdk.org  Fri Feb 21 19:12:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Feb 2025 19:12:00 GMT
Subject: Integrated: 8350287: Cleanup SA's support for CodeBlob subclasses
In-Reply-To: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
Message-ID: <qnFL9ekI6jkDpMSLi_ISHWOUyxs8yK5UQzsZWm5Z86c=.0de83886-7328-4cba-abd5-cea79660c862@github.com>

On Wed, 19 Feb 2025 02:08:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also.
> 
> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. 
> 
> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone):
> 
> 
>   public String getName() {
>     return "AdapterBlob: " + super.getName();
>   }
> 
> 
> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type.  I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it.

This pull request has now been integrated.

Changeset: b45c32cd
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b45c32cd4fb55fac4fc5161b9cd76415c69b203b
Stats:     698 lines in 15 files changed: 13 ins; 680 del; 5 mod

8350287: Cleanup SA's support for CodeBlob subclasses

Reviewed-by: kvn, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/23684

From cjplummer at openjdk.org  Fri Feb 21 19:12:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 21 Feb 2025 19:12:00 GMT
Subject: RFR: 8350287: Cleanup SA's support for CodeBlob subclasses [v2]
In-Reply-To: <k2NwhUstKFzIbzXfe4SJAmFAlxyaPIjwkkLkxZY48Yo=.c90111cb-d4ee-42dd-8f7c-0e44336351c5@github.com>
References: <trzGnHyHfge8VkS_pnyq7vJ-sG4gBQIwSSZ7tPGn-mI=.8312f39a-dc7e-4b7f-a9f8-eabc18825821@github.com>
 <k2NwhUstKFzIbzXfe4SJAmFAlxyaPIjwkkLkxZY48Yo=.c90111cb-d4ee-42dd-8f7c-0e44336351c5@github.com>
Message-ID: <3R9wsUs6rIJPcbg5Rwd2zBfc-PcAur1HquvuL52jh9I=.4896d421-78f9-4dbd-91b4-52c39075cf9d@github.com>

On Wed, 19 Feb 2025 05:49:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There is a lot of subclassing of CodeBlob types done in SA to mimic hotspot, but most of it is unnecessary. The generic CodeBlob class can handle all support needed by most of the subclasses. The only subclasses we need to keep around around NMethod, RuntimeStub, and UpcallStub, since they all have special support in SA. I also kept around RuntimeBlob so RuntimeStub can continue to inherit from it and be consistent with hotspot, but it's not actually necessary, and I'm more than happy to remove it also.
>> 
>> I also cleaned up the PStack support for CodeBlobs. It can just use CodeBlob.getName() rather than trying to figure out the type of the CodeBlob instance to print out type name. This allows us to get rid of most isXXX() APIs. It also provides more useful output in some cases. 
>> 
>> There is some minor loss of functionality in some of the CodeBlob subtypes I removed. For example this is what AdapterBlob.getName() looked like (it is now gone):
>> 
>> 
>>   public String getName() {
>>     return "AdapterBlob: " + super.getName();
>>   }
>> 
>> 
>> So now we just use the default CodeBlob.getName(), which is what super.getName() would up execute. I think for AdapterBlob this always returns "I2C/C2I adapters", so now you only get this rather than "AdapterBlob: I2C/C2I adapters". We have a similar loss of getName() detail with MethodHandlesAdapterBlob (now returns "MethodHandles adapters") and VtableBlob (now returns "vtable chunks"). Basically for these 3 CodeBlob types getName() will no longer include the CodeBlob type.  I could special case them in CodeBlob.getName() by fetching the kind to determine what the proper name should be. Let me know if you think it is worth it.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor improvements.

Thanks for the reviews Vladimir and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/23684#issuecomment-2675336648

From schernyshev at openjdk.org  Fri Feb 21 19:56:16 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 21 Feb 2025 19:56:16 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v14]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <wA6p1_QAZNYebosD6c32cGb5MisP3UOxLub-gnSo4-w=.12387827-c8ca-4c09-be08-370f1d758c7c@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  fix the tests to address the review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/8e8ab869..28122ff9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=12-13

  Stats: 27 lines in 2 files changed: 5 ins; 6 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Fri Feb 21 19:56:17 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 21 Feb 2025 19:56:17 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
Message-ID: <Q-hAI75CokWDYr2bdgBE5Ud-9xdFBMs57eRqYkASvcE=.2c9fd89a-1a24-4b0a-93e4-6c7f5e40414e@github.com>

On Mon, 17 Feb 2025 11:28:38 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added details in the log message
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 60:
> 
>> 58: 
>> 59:             Common.prepareWhiteBox();
>> 60:             DockerTestUtils.buildJdkContainerImage(imageName);
> 
> This can be moved out of the condition. It's there in both cases.

Done

> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 85:
> 
>> 83:         } else {
>> 84:             System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now.");
>> 85:         }
> 
> Suggestion:
> 
>         throw new RuntimeException("cgroup version not known? was: " + metrics.getProvider());

I made it with `jtreg.SkippedException`

> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 98:
> 
>> 96:         opts.addDockerOpts("--privileged")
>> 97:             .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host"))
>> 98:             .addDockerOpts("--memory", "1g");
> 
> Please extract this "larger" memory limit out of this function. The expectation is to have:
> 
> 
> Container memory limit => X
> Some lower limit in a moved path => Y
> 
> Expect that the lower limit of Y is being detected.
> 
> 
> For example:
> 
> 
> testMemoryLimitSubgroupV1("1g", "100m", "104857600", false);

done.

> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 118:
> 
>> 116:         opts.addDockerOpts("--privileged")
>> 117:             .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host"))
>> 118:             .addDockerOpts("--memory", "1g");
> 
> Same here with the `1g` container memory limit. Move it to a parameter.

done. extracted the parameter.

> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 72:
> 
>> 70:         } else {
>> 71:             System.out.println("Metrics are from neither cgroup v1 nor v2, skipped for now.");
>> 72:         }
> 
> Please `throw` here.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966094564
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966094301
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966093295
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966092984
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966092288

From schernyshev at openjdk.org  Fri Feb 21 20:07:58 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 21 Feb 2025 20:07:58 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <OObfj4QWk_Q3Fk2-mDJbpfeFNhOAbgEmDB-IBehjR4c=.672abfeb-fc3f-4c68-ad0d-693ac0eb7bcd@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
 <OObfj4QWk_Q3Fk2-mDJbpfeFNhOAbgEmDB-IBehjR4c=.672abfeb-fc3f-4c68-ad0d-693ac0eb7bcd@github.com>
Message-ID: <E4B7c1WLUyhHGmEaox71qVNbypKMw_Hdo1dKU_RQcMY=.db21dfe9-e676-4ac6-b954-19bc40b64268@github.com>

On Thu, 20 Feb 2025 17:32:54 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 73:
>> 
>>> 71:                                 break;
>>> 72:                             }
>>> 73:                             cgp = (cgp.getNameCount() > 1) ? cgp.subpath(1, cgp.getNameCount()) : Path.of("");
>> 
>> Suggestion:
>> 
>>                             cgp = (nameCount > 1) ? cgp.subpath(1, nameCount) : Path.of("");
>
> Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take.

How about this?

int currentNameCount = cgp.getNameCount();
cgp = (currentNameCount > 1) ? cgp.subpath(1, currentNameCount) : Path.of("");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1966107031

From jiangli at openjdk.org  Sat Feb 22 03:37:34 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 22 Feb 2025 03:37:34 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1 tests
 fail on static JDK
Message-ID: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>

Please review the fix in following tests to not check for shared libraries when running on static JDK:

test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java

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

Commit messages:
 - Update copyright headers.
 - Remove unneeded `import jdk.test.whitebox.WhiteBox;`
 - Don't look for shared libraries on static JDK.

Changes: https://git.openjdk.org/jdk/pull/23734/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23734&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350524
  Stats: 67 lines in 4 files changed: 46 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/23734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23734/head:pull/23734

PR: https://git.openjdk.org/jdk/pull/23734

From syan at openjdk.org  Sun Feb 23 12:20:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Feb 2025 12:20:02 GMT
Subject: RFR: 8350545: Several sun/management/jdp tests fails
 java.net.SocketException
Message-ID: <W6YRK1OCz5bYdl5z5ju2SzkNFt4lDNnAnMYQJApCAYw=.78276d1a-f154-43cb-aab0-c893bbd14209@github.com>

Hi all,

Four sun/management/jdp tests fails "java.net.SocketException: No such device" on some machines. The machine cannot connect to the Internet directly and needs to be connected to the Internet through a jump machine. The sun/management/jdp tests report "java.net.SocketException: No such device" failure do not caused by JVM bug but environmentalk issue, so this PR match the output and throw `jtreg.SkippedException` instead of report test fails.

Change has been verified locally, test-fix only and make tests more robustness, no risk.

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

Commit messages:
 - 8350545: Several sun/management/jdp tests fails java.net.SocketException

Changes: https://git.openjdk.org/jdk/pull/23738/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23738&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350545
  Stats: 13 lines in 5 files changed: 4 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23738/head:pull/23738

PR: https://git.openjdk.org/jdk/pull/23738

From alanb at openjdk.org  Sun Feb 23 12:50:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 23 Feb 2025 12:50:06 GMT
Subject: RFR: 8350545: Several sun/management/jdp tests fails
 java.net.SocketException
In-Reply-To: <W6YRK1OCz5bYdl5z5ju2SzkNFt4lDNnAnMYQJApCAYw=.78276d1a-f154-43cb-aab0-c893bbd14209@github.com>
References: <W6YRK1OCz5bYdl5z5ju2SzkNFt4lDNnAnMYQJApCAYw=.78276d1a-f154-43cb-aab0-c893bbd14209@github.com>
Message-ID: <4aYtU0MSCFd-32URhOyyhwoq_dKUqY10eGiEzV6oDLM=.8e8fde62-b9c6-4510-bb8e-18de975daa4e@github.com>

On Sun, 23 Feb 2025 12:15:13 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Four sun/management/jdp tests fails "java.net.SocketException: No such device" on some machines. The machine cannot connect to the Internet directly and needs to be connected to the Internet through a jump machine. The sun/management/jdp tests report "java.net.SocketException: No such device" failure do not caused by JVM bug but environmentalk issue, so this PR match the output and throw `jtreg.SkippedException` instead of report test fails.
> 
> Change has been verified locally, test-fix only and make tests more robustness, no risk.

test/jdk/sun/management/jdp/DynamicLauncher.java line 66:

> 64:         if (output.contains("java.net.SocketException: No such device")) {
> 65:             throw new SkippedException("Network setup issue, skip this test");
> 66:         }

Something else isn't right if you are getting this error so I think further investigation is required to see if the issue is the test choosing the wrong interface or address, or a configuration issue on the test system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23738#discussion_r1966769914

From syan at openjdk.org  Sun Feb 23 13:24:00 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Feb 2025 13:24:00 GMT
Subject: Withdrawn: 8350545: Several sun/management/jdp tests fails
 java.net.SocketException
In-Reply-To: <W6YRK1OCz5bYdl5z5ju2SzkNFt4lDNnAnMYQJApCAYw=.78276d1a-f154-43cb-aab0-c893bbd14209@github.com>
References: <W6YRK1OCz5bYdl5z5ju2SzkNFt4lDNnAnMYQJApCAYw=.78276d1a-f154-43cb-aab0-c893bbd14209@github.com>
Message-ID: <JYJR3HZfx84n3h82XjnQdkGGFILeE3m0KX6PkXIbhr4=.b4d6caf2-0ed3-4ab6-8941-1e8b1121a07d@github.com>

On Sun, 23 Feb 2025 12:15:13 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Four sun/management/jdp tests fails "java.net.SocketException: No such device" on some machines. The machine cannot connect to the Internet directly and needs to be connected to the Internet through a jump machine. The sun/management/jdp tests report "java.net.SocketException: No such device" failure do not caused by JVM bug but environmentalk issue, so this PR match the output and throw `jtreg.SkippedException` instead of report test fails.
> 
> Change has been verified locally, test-fix only and make tests more robustness, no risk.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/23738

From syan at openjdk.org  Sun Feb 23 13:35:56 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Feb 2025 13:35:56 GMT
Subject: RFR: 8350545: Several sun/management/jdp tests fails
 java.net.SocketException
In-Reply-To: <4aYtU0MSCFd-32URhOyyhwoq_dKUqY10eGiEzV6oDLM=.8e8fde62-b9c6-4510-bb8e-18de975daa4e@github.com>
References: <W6YRK1OCz5bYdl5z5ju2SzkNFt4lDNnAnMYQJApCAYw=.78276d1a-f154-43cb-aab0-c893bbd14209@github.com>
 <4aYtU0MSCFd-32URhOyyhwoq_dKUqY10eGiEzV6oDLM=.8e8fde62-b9c6-4510-bb8e-18de975daa4e@github.com>
Message-ID: <pMHWaPeYaTFK7mdhcB3q0wg4OUOb-9ZYZgcKSN_4L6I=.aac29057-aded-42a7-8383-3e0cd3a02c78@github.com>

On Sun, 23 Feb 2025 12:46:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi all,
>> 
>> Four sun/management/jdp tests fails "java.net.SocketException: No such device" on some machines. The machine cannot connect to the Internet directly and needs to be connected to the Internet through a jump machine. The sun/management/jdp tests report "java.net.SocketException: No such device" failure do not caused by JVM bug but environmentalk issue, so this PR match the output and throw `jtreg.SkippedException` instead of report test fails.
>> 
>> Change has been verified locally, test-fix only and make tests more robustness, no risk.
>
> test/jdk/sun/management/jdp/DynamicLauncher.java line 66:
> 
>> 64:         if (output.contains("java.net.SocketException: No such device")) {
>> 65:             throw new SkippedException("Network setup issue, skip this test");
>> 66:         }
> 
> Something else isn't right if you are getting this error so I think further investigation is required to see if the issue is the test choosing the wrong interface or address, or a configuration issue on the test system.

The tested address:port is hard code to '224.0.23.178:7095' by file test/jdk/sun/management/jdp/ClientConnection.java. This address:port work normally on most machines, but cannot work on machine which can not connect to the internet directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23738#discussion_r1966784435

From kevinw at openjdk.org  Sun Feb 23 20:52:58 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Sun, 23 Feb 2025 20:52:58 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v2]
In-Reply-To: <rYBB2a46pNGzfXv47lsnd8DovngQpgqjj6qnwx6X_FA=.2fb759c4-949b-41e1-b9ae-9e31b8d3d3dd@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
 <rYBB2a46pNGzfXv47lsnd8DovngQpgqjj6qnwx6X_FA=.2fb759c4-949b-41e1-b9ae-9e31b8d3d3dd@github.com>
Message-ID: <ovp8giXxERRn2mwCiw4hDEc6dVqaR9QQOxHHDMTocmU=.d4a49a3c-ba6a-4344-b1eb-a6d8e9b9945f@github.com>

On Fri, 21 Feb 2025 06:19:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - comments
>>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>>  - (c)
>>  - typo
>>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>>  - Also XMLParseException
>>  - RMMB comment update
>>  - Deprecate XML interchange in DescriptorSupport
>
> src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 977:
> 
>> 975:      * construction fails for any reason, this exception will be
>> 976:      * thrown.
>> 977:      * @deprecated This constructor exists for historical reasons.  If
> 
> Q: This is not constructor, right?

ah right, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1966884163

From dholmes at openjdk.org  Mon Feb 24 00:07:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Feb 2025 00:07:02 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v5]
In-Reply-To: <MlWig0TFj-P1lEmXY02h3pXpUizN-4WSJz8fi3Q1wBY=.2ff71fae-ba10-485d-bdb3-3c7872af58f9@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <MlWig0TFj-P1lEmXY02h3pXpUizN-4WSJz8fi3Q1wBY=.2ff71fae-ba10-485d-bdb3-3c7872af58f9@github.com>
Message-ID: <ckmS6PNp3cFdpiz4plQOkzWGNywUdADWYnZaM6ncBlU=.15f96d6b-52a5-448f-912f-c5e097fc3a1b@github.com>

On Fri, 21 Feb 2025 06:19:55 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
>> 
>> Passed tiers 1 - 5 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename classes and add vm_exit_during_initialization call

A couple of minor suggestions, but otherwise nothing further from me.

Thanks

src/hotspot/share/cds/aotClassLocation.cpp line 53:

> 51: const AOTClassLocationConfig* AOTClassLocationConfig::_runtime_instance = nullptr;
> 52: 
> 53: // A ClassLocationStream represents a list of code sources, which can be iterated using

Suggestion:

// A ClassLocationStream represents a list of code locations, which can be iterated using

src/hotspot/share/cds/aotClassLocation.cpp line 133:

> 131: };
> 132: 
> 133: // AllClassLocationStreams is used to iterate over all the code sources that

Suggestion:

// AllClassLocationStreams is used to iterate over all the code locations that

src/hotspot/share/cds/aotClassLocation.hpp line 122:

> 120: // AOTClassLocations (subjected to AOTClassLocationConfig::validate()).
> 121: //
> 122: // In general, validation is performed on the AOTClassLocations to ensure the code sources used

Suggestion:

// In general, validation is performed on the AOTClassLocations to ensure the code locations used

src/hotspot/share/classfile/classLoaderDataShared.cpp line 157:

> 155: }
> 156: 
> 157: void ClassLoaderDataShared::ensure_module_entry_table_exist(oop class_loader) {

Suggestion:

void ClassLoaderDataShared::ensure_module_entry_table_exists(oop class_loader) {

Tables exist, but a single table exists.

src/hotspot/share/classfile/classLoaderDataShared.hpp line 37:

> 35: class ClassLoaderDataShared : AllStatic {
> 36:   static bool _full_module_graph_loaded;
> 37:   static void ensure_module_entry_table_exist(oop class_loader);

Suggestion:

  static void ensure_module_entry_table_exists(oop class_loader);

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23476#pullrequestreview-2635829484
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1966936547
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1966936586
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1966936262
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1966939280
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1966939500

From mbaesken at openjdk.org  Mon Feb 24 08:15:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Feb 2025 08:15:55 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <zO5fnlrk_INx_PHArYZNxoj1u6u9AfYwlShYl0b8TeE=.ffa81119-043d-43b6-a243-aceff9686c80@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

Hi Chris, thanks for the explanation and details of the minimal-vm .

> My point here is that if you want small footprint, you can choose that, and expect some performance hit as a result

Unfortunately , the JDK native libs are always compiled with the default settings (mostly LOW, for a few HIGH(EST))  so I cannot choose much. The minimal vm is interesting but as it is, it is not really a good choice.
Maybe we need better configure support to influence how the JDK libs are built.

On the other hand , most JDK libs have optimization LOW set, that does not look like they care too much about best performance.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2677689127

From rcastanedalo at openjdk.org  Mon Feb 24 08:59:54 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 24 Feb 2025 08:59:54 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <0wHGNSlwe7cWb7Plad2n8Swy8rayYTAf5IETuw9zl4U=.a4d6a129-aebc-4639-aaef-92ee6c4552c7@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
 <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
 <0wHGNSlwe7cWb7Plad2n8Swy8rayYTAf5IETuw9zl4U=.a4d6a129-aebc-4639-aaef-92ee6c4552c7@github.com>
Message-ID: <NfX5WX4NU_kD7dQcZjpaN3z28TDcsg2OIJjXjpZv_-s=.34848957-da62-430c-ae40-a57f32f10cfb@github.com>

On Thu, 20 Feb 2025 13:59:57 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> > @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
> > With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.
> 
> Great, thanks! Will re-run benchmarking and report results early next week.

Functional test results (Oracle tier1-5) still look good for the latest commit (dd7a06ad). I can confirm that the C2 speed regression on our linux-x64 machines is almost fully mitigated. The 2-3% regression on our macosx-aarch64 machines does not seem to be addressed by the latest changes though, but as I mentioned before I think it is in the acceptable range (and only affects one benchmark).

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2677775924

From iwalulya at openjdk.org  Mon Feb 24 09:53:55 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Feb 2025 09:53:55 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v4]
In-Reply-To: <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
Message-ID: <eJN6RdcBSOSeIb_XY0vH3ON2MuDOxp0IENawN6fycuU=.6ffa6969-49c5-461d-b38c-b6ea6320ff24@github.com>

On Tue, 18 Feb 2025 09:20:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2636497189

From kevinw at openjdk.org  Mon Feb 24 09:59:15 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Feb 2025 09:59:15 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v3]
In-Reply-To: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
Message-ID: <8RA6woqoHj8ww-8iByQhCARsURNi5fWbLd7qR2by07E=.aef766be-2dad-4959-9451-6bcc8f508c8e@github.com>

> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
> 
> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.

Kevin Walls 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 10 additional commits since the last revision:

 - constructor->method in deprecated tag
 - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
 - comments
 - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
 - (c)
 - typo
 - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
 - Also XMLParseException
 - RMMB comment update
 - Deprecate XML interchange in DescriptorSupport

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23038/files
  - new: https://git.openjdk.org/jdk/pull/23038/files/1d236064..04d627c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23038&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23038&range=01-02

  Stats: 11461 lines in 363 files changed: 7066 ins; 3185 del; 1210 mod
  Patch: https://git.openjdk.org/jdk/pull/23038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23038/head:pull/23038

PR: https://git.openjdk.org/jdk/pull/23038

From syan at openjdk.org  Mon Feb 24 10:02:52 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 24 Feb 2025 10:02:52 GMT
Subject: RFR: 8350545: Several sun/management/jdp tests fails
 java.net.SocketException
In-Reply-To: <pMHWaPeYaTFK7mdhcB3q0wg4OUOb-9ZYZgcKSN_4L6I=.aac29057-aded-42a7-8383-3e0cd3a02c78@github.com>
References: <W6YRK1OCz5bYdl5z5ju2SzkNFt4lDNnAnMYQJApCAYw=.78276d1a-f154-43cb-aab0-c893bbd14209@github.com>
 <4aYtU0MSCFd-32URhOyyhwoq_dKUqY10eGiEzV6oDLM=.8e8fde62-b9c6-4510-bb8e-18de975daa4e@github.com>
 <pMHWaPeYaTFK7mdhcB3q0wg4OUOb-9ZYZgcKSN_4L6I=.aac29057-aded-42a7-8383-3e0cd3a02c78@github.com>
Message-ID: <RPEI8NzqCDQRpe60_KfVNtcI__dgpE7wYuP8XCQEk9Y=.6fc99ec4-82a7-4102-a0b1-dc45c6edb594@github.com>

On Sun, 23 Feb 2025 13:31:00 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/sun/management/jdp/DynamicLauncher.java line 66:
>> 
>>> 64:         if (output.contains("java.net.SocketException: No such device")) {
>>> 65:             throw new SkippedException("Network setup issue, skip this test");
>>> 66:         }
>> 
>> Something else isn't right if you are getting this error so I think further investigation is required to see if the issue is the test choosing the wrong interface or address, or a configuration issue on the test system.
>
> The tested address:port is hard code to '224.0.23.178:7095' by file test/jdk/sun/management/jdp/ClientConnection.java. This address:port work normally on most machines, but cannot work on machine which can not connect to the internet directly.

Seems that the exception from src/java.base/unix/native/libnio/ch/Net.c:679.
I'm not familiar with jdp feature, Could you give me some advices how to make check is the test choosing the wrong interface or address.

The information test system which report test failure shows below:


> ifconfig 
enP2p129s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.50.12  netmask 255.255.255.0  broadcast 192.168.50.255
        inet6 fe80::1163:1d10:87a:6be4  prefixlen 64  scopeid 0x20<link>
        ether a0:36:9f:53:17:f6  txqueuelen 1000  (Ethernet)
        RX packets 22678271  bytes 28824464370 (26.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9400465  bytes 7501254087 (6.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 26485240  bytes 221859212049 (206.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 26485240  bytes 221859212049 (206.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

> ip r
192.168.50.0/24 dev enP2p129s0f1 proto kernel scope link src 192.168.50.12 metric 100 


Command wget shows that it should connect internet through a jumper machine(192.168.50.1:10991):


> wget www.bing.com
--2025-02-24 17:56:25--  http://www.bing.com/
Connecting to 192.168.50.1:10991... connected.
Proxy request sent, awaiting response... 301 Moved Permanently
Location: http://cn.bing.com/ [following]
--2025-02-24 17:56:25--  http://cn.bing.com/
Reusing existing connection to 192.168.50.1:10991.
Proxy request sent, awaiting response... 200 OK
Length: 13006 (13K) [text/html]
Saving to: ?index.html?

index.html                                        100%[=============================================================================================================>]  12.70K  --.-KB/s    in 0s      

2025-02-24 17:56:25 (28.7 MB/s) - ?index.html? saved [13006/13006]

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23738#discussion_r1967322056

From rcastanedalo at openjdk.org  Mon Feb 24 10:13:54 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 24 Feb 2025 10:13:54 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
Message-ID: <tWs8dyZ9EEBoAO9VWb5gLXUCuFqn4RUY9H3GmaCOQTc=.8b17bb77-7556-43dd-bf29-5d177acd893a@github.com>

On Thu, 20 Feb 2025 13:14:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   avoid Thread::current in high traffic chunk alloc path

src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 255:

> 253:   char tmp[1024];
> 254:   _k->as_C_string(tmp, sizeof(tmp));
> 255: if (UseNewCode){ printf("%s\n",tmp); fflush(stdout);}

I guess this use of `UseNewCode` is not meant to be integrated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967340962

From rcastanedalo at openjdk.org  Mon Feb 24 10:33:02 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 24 Feb 2025 10:33:02 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
Message-ID: <_oNuzx4YepRchoguAnBbXw-31T14WgK8oQpC47FAJOc=.6edd8fcc-6757-448b-992d-b13b94af7c59@github.com>

On Thu, 20 Feb 2025 13:14:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   avoid Thread::current in high traffic chunk alloc path

A few naming/documentation comments so far.

src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 1093:

> 1091:       Compile::TracePhase tp(Phase::_t_testTimer1);
> 1092:       Arena ar(MemTag::mtCompiler, Arena::Tag::tag_reglive);
> 1093:       ar.Amalloc(2 * M); // phase-local peak, should show up at MY-TESTPHASE-2

The reference to `MY-TESTPHASE-2` seems obsolete.

test/hotspot/jtreg/compiler/print/CompileCommandMemLimit.java line 105:

> 103:         // by phase end. So, in the phase timeline these 2MB must show up as "significant temporary peak".
> 104:         // In testPhase2, we allocate 32MB from resource area, which is leaked until the end of the compilation. This
> 105:         // means that these 32MB will show up as permanent memory increase in the phasetimeline.

The references to `testPhase` seem obsolete, do you mean `Phase::_t_testTimer1` and `Phase::_t_testTimer2`?

test/hotspot/jtreg/compiler/print/CompileCommandMemLimit.java line 105:

> 103:         // by phase end. So, in the phase timeline these 2MB must show up as "significant temporary peak".
> 104:         // In testPhase2, we allocate 32MB from resource area, which is leaked until the end of the compilation. This
> 105:         // means that these 32MB will show up as permanent memory increase in the phasetimeline.

Suggestion:

        // means that these 32MB will show up as permanent memory increase in the phase timeline.

test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java line 27:

> 25: /*
> 26:  * @test id=c2
> 27:  * @summary Checks that -XX:CompileCommand=PrintMemStat,... works

Suggestion:

 * @summary Checks that -XX:CompileCommand=MemStat,... works

test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java line 35:

> 33: /*
> 34:  * @test id=c1
> 35:  * @summary Checks that -XX:CompileCommand=PrintMemStat,... works

Suggestion:

 * @summary Checks that -XX:CompileCommand=MemStat,... works

test/hotspot/jtreg/compiler/print/CompileCommandPrintMemStat.java line 86:

> 84:         oa.reportDiagnosticSummary();
> 85: 
> 86:         // We expect two printouts for "PrintMemStat". A line at compilation time, and a line in a summary report

Suggestion:

        // We expect two printouts for "MemStat". A line at compilation time, and a line in a summary report

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

Changes requested by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23530#pullrequestreview-2636581034
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967354177
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967350305
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967355138
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967358896
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967357706
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967359828

From dholmes at openjdk.org  Mon Feb 24 11:28:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Feb 2025 11:28:01 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v4]
In-Reply-To: <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
Message-ID: <LZweVXYhnIpZ5u4rBgMkRHnqFae4kkl2DNjtbxG5VlE=.3ff220a3-eade-4b2c-b82c-fc1dcf062e1b@github.com>

On Tue, 18 Feb 2025 09:20:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

Nothing further from me. Thanks

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

PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2636773637

From kevinw at openjdk.org  Mon Feb 24 11:45:05 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Feb 2025 11:45:05 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
Message-ID: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>

Trivial removal of confusing "Tonga" references in comments within a few JMX tests.

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

Commit messages:
 - 8350571: Remove mention of Tonga test suite from JMX tests

Changes: https://git.openjdk.org/jdk/pull/23747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350571
  Stats: 27 lines in 5 files changed: 0 ins; 20 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23747/head:pull/23747

PR: https://git.openjdk.org/jdk/pull/23747

From dfuchs at openjdk.org  Mon Feb 24 12:35:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Feb 2025 12:35:56 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v2]
In-Reply-To: <FOc8v3PBORFB-TU5MUqgmsWkHc-OJrIXB7nqZgyEyfg=.bc16df33-c61f-4850-9817-dafce3ee6fda@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <ZIcXKsC1ip_dtaDfv12mU0ssmvFM4nHMbQ9ZdAvQJzc=.7ac015af-382f-4508-a2f6-4adfc0c7f035@github.com>
 <mAnzfi73_tAi4R593t0bPfeE8Jog_0GGyT3mzCxdjes=.c5136d73-482d-4c2c-b0c8-ba4507fd2ef5@github.com>
 <ktNPuQIEuqRFlY-5b36M-q6696Xazlev7hYfjkWFB3s=.30a2c551-03e9-4d3c-b98a-a01c04acd0ea@github.com>
 <Vt1B6Abl5sqebc_509HgQNoOn98919cl0SRwKL2fkdA=.a7fe6de2-c664-4289-80c3-759f9d9a04a9@github.com>
 <FOc8v3PBORFB-TU5MUqgmsWkHc-OJrIXB7nqZgyEyfg=.bc16df33-c61f-4850-9817-dafce3ee6fda@github.com>
Message-ID: <ot9lTQRpurcNRRptZpfhJGLvD6dPy2jLRRgT9buDPas=.a65d9317-c63a-4d10-918f-60704586dec5@github.com>

On Sun, 23 Feb 2025 20:58:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> But the question is interesting. There could be code out there that instantiate and throws this exception for its own purpose. Or that tries to catch it, or instanceof it... Maybe we should let it linger longer than the associated API that throws it.
>
> If we wanted to be really cautious, we could hold off removal of the exception class.  But we should still deprecate it for removal now.
> Code out there using specifically javax/management/modelmbean/XMLParseException would most likely be a mistake, it most likely meant some other XMLParseException class...  There really should not be any external usage...

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1967559781

From mbaesken at openjdk.org  Mon Feb 24 12:42:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Feb 2025 12:42:53 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

To be sure, I did a minimal build on Linux x86_64.  I set `--with-jvm-features=minimal --with-jvm-variants=minimal`  for this.
This leads to 
`JVM_FEATURES_minimal='compiler1 minimal opt-size serialgc'`
So no jvmti, to GCs except serialgc . Just C1, no C2.  The 'opt-size' flag is set so the libjvm is compiled with size optimization (on Linux -Os).  The other native libs (JDK native libs) still use the opt-flags they always use, as I thought.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2678301414

From mbaesken at openjdk.org  Mon Feb 24 13:59:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Feb 2025 13:59:52 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <6c5zel9raqIdkgXvw0LqZbqYKHQfFcpRuqo8rUmH_7I=.3870c21d-7c90-4ab8-b125-2b921de883f8@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <6c5zel9raqIdkgXvw0LqZbqYKHQfFcpRuqo8rUmH_7I=.3870c21d-7c90-4ab8-b125-2b921de883f8@github.com>
Message-ID: <J35iTpnRtZgWhlPCQ0PWQjGGqoC0eicvO6JBSu6ny4g=.9c95dd07-30bd-41b9-b8ae-ba66034d84ae@github.com>

On Fri, 21 Feb 2025 19:07:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> You are suggesting potentially sacrificing some performance for reduced footprint (and a tiny footprint reduction at that) without it being a choice

On some platforms we might have a (small)  performance impact when going from LOW/NORM to SIZE  (e.g. with MSVC it is the same settings anyways). But without benchmarks it is hard to say if there really is a decline in performance (and if so, how much).
My assumption (after talking to our leading debugging expert) was that libjdwp is not very performance critical but maybe this was wrong.
On the other hand we can achieve good performance _and_ smaller binaries with lto (at least with gcc).

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2678491013

From rcastanedalo at openjdk.org  Mon Feb 24 14:51:07 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 24 Feb 2025 14:51:07 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
Message-ID: <uaO94n1tFzdMsjuaTzU4mPjBR2HLmH4D3B84n1YFdvQ=.aebd0237-d188-43ea-a011-6cb40100bcbd@github.com>

On Thu, 20 Feb 2025 13:14:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   avoid Thread::current in high traffic chunk alloc path

I reviewed the C2-specific code and have a couple of comments, otherwise looks good. While reviewing, I found a few more C2 arenas that could be tagged for higher accuracy:

- matcher states arena,
- superword (auto-vectorizer) arenas,
- `Compile::_Compile_types`, and
- `OptoRegScheduling` liveness arena.

Here is a patch that adds tags for these: https://github.com/openjdk/jdk/commit/d501bd8a674229904358fb168a9c347004efeea3. I think these changes are within the scope of this RFE, because the original changeset includes similar ones. If you agree, feel free to merge the patch into this RFE.

src/hotspot/share/memory/arena.hpp line 99:

> 97:   FN(comp,        C2 Compile arena) \
> 98:   FN(type,        C2 Type arena) \
> 99:   FN(index,       C2 Index arena) \

`tag_index` is not used and can be removed, it seems to be subsumed by `tag_reglive`.

src/hotspot/share/opto/chaitin.cpp line 370:

> 368: 
> 369:   ResourceArea split_arena(mtCompiler, Arena::Tag::tag_reglive);     // Arena for Split local resources
> 370:   ResourceArea live_arena(mtCompiler, Arena::Tag::tag_regsplit);     // Arena for liveness & IFG info

Suggestion:

  ResourceArea split_arena(mtCompiler, Arena::Tag::tag_regsplit);     // Arena for Split local resources
  ResourceArea live_arena(mtCompiler, Arena::Tag::tag_reglive);     // Arena for liveness & IFG info

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

Changes requested by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23530#pullrequestreview-2637314247
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967765880
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1967761886

From ccheung at openjdk.org  Mon Feb 24 18:43:27 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 24 Feb 2025 18:43:27 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v6]
In-Reply-To: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
Message-ID: <dX3rqEpG00SEjU8Hb5_gzz06Q0aAlHdH9xV_wmY9nck=.e0ddc6f7-7bf1-4533-8017-d88ed4250ff5@github.com>

> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
> 
> Passed tiers 1 - 5 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @dholmes-ora comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23476/files
  - new: https://git.openjdk.org/jdk/pull/23476/files/9e4e33dd..70f3efb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23476&range=04-05

  Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23476/head:pull/23476

PR: https://git.openjdk.org/jdk/pull/23476

From ccheung at openjdk.org  Mon Feb 24 18:43:28 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 24 Feb 2025 18:43:28 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v5]
In-Reply-To: <ckmS6PNp3cFdpiz4plQOkzWGNywUdADWYnZaM6ncBlU=.15f96d6b-52a5-448f-912f-c5e097fc3a1b@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <MlWig0TFj-P1lEmXY02h3pXpUizN-4WSJz8fi3Q1wBY=.2ff71fae-ba10-485d-bdb3-3c7872af58f9@github.com>
 <ckmS6PNp3cFdpiz4plQOkzWGNywUdADWYnZaM6ncBlU=.15f96d6b-52a5-448f-912f-c5e097fc3a1b@github.com>
Message-ID: <7cqil6gxusrEIf8DOQJDncbJSbYd7uzgd0i92GX-EUY=.b446ab76-3e0a-4aab-8eb5-0e028a940a44@github.com>

On Sun, 23 Feb 2025 23:52:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename classes and add vm_exit_during_initialization call
>
> src/hotspot/share/cds/aotClassLocation.cpp line 53:
> 
>> 51: const AOTClassLocationConfig* AOTClassLocationConfig::_runtime_instance = nullptr;
>> 52: 
>> 53: // A ClassLocationStream represents a list of code sources, which can be iterated using
> 
> Suggestion:
> 
> // A ClassLocationStream represents a list of code locations, which can be iterated using

Fixed

> src/hotspot/share/cds/aotClassLocation.cpp line 133:
> 
>> 131: };
>> 132: 
>> 133: // AllClassLocationStreams is used to iterate over all the code sources that
> 
> Suggestion:
> 
> // AllClassLocationStreams is used to iterate over all the code locations that

Fixed

> src/hotspot/share/cds/aotClassLocation.hpp line 122:
> 
>> 120: // AOTClassLocations (subjected to AOTClassLocationConfig::validate()).
>> 121: //
>> 122: // In general, validation is performed on the AOTClassLocations to ensure the code sources used
> 
> Suggestion:
> 
> // In general, validation is performed on the AOTClassLocations to ensure the code locations used

Fixed

> src/hotspot/share/classfile/classLoaderDataShared.cpp line 157:
> 
>> 155: }
>> 156: 
>> 157: void ClassLoaderDataShared::ensure_module_entry_table_exist(oop class_loader) {
> 
> Suggestion:
> 
> void ClassLoaderDataShared::ensure_module_entry_table_exists(oop class_loader) {
> 
> Tables exist, but a single table exists.

Fixed

> src/hotspot/share/classfile/classLoaderDataShared.hpp line 37:
> 
>> 35: class ClassLoaderDataShared : AllStatic {
>> 36:   static bool _full_module_graph_loaded;
>> 37:   static void ensure_module_entry_table_exist(oop class_loader);
> 
> Suggestion:
> 
>   static void ensure_module_entry_table_exists(oop class_loader);

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1968212961
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1968213029
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1968212846
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1968213106
PR Review Comment: https://git.openjdk.org/jdk/pull/23476#discussion_r1968213193

From cjplummer at openjdk.org  Mon Feb 24 19:21:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 24 Feb 2025 19:21:52 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
Message-ID: <QWVsaClj1o7pXQ_7lNOIDIcWcQ9TweFTFNtInBL88tA=.37963343-689a-401b-9934-0f6571d732cd@github.com>

On Mon, 24 Feb 2025 11:40:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial removal of confusing "Tonga" references in comments within a few JMX tests.

Looks good. I'd like for @lmesnik to comment on this.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23747#pullrequestreview-2638207454

From iklam at openjdk.org  Mon Feb 24 19:52:03 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 24 Feb 2025 19:52:03 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v6]
In-Reply-To: <dX3rqEpG00SEjU8Hb5_gzz06Q0aAlHdH9xV_wmY9nck=.e0ddc6f7-7bf1-4533-8017-d88ed4250ff5@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <dX3rqEpG00SEjU8Hb5_gzz06Q0aAlHdH9xV_wmY9nck=.e0ddc6f7-7bf1-4533-8017-d88ed4250ff5@github.com>
Message-ID: <N1HHwpyYmwR3ofl0cvpRDDeR7aLzdorq8nJ2lLdbblA=.bbdea1d4-9907-4c63-9a2b-0e92dddcafec@github.com>

On Mon, 24 Feb 2025 18:43:27 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
>> 
>> Passed tiers 1 - 5 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23476#pullrequestreview-2638290020

From ccheung at openjdk.org  Mon Feb 24 19:58:13 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 24 Feb 2025 19:58:13 GMT
Subject: RFR: 8280682: Refactor AOT code source validation checks [v5]
In-Reply-To: <ckmS6PNp3cFdpiz4plQOkzWGNywUdADWYnZaM6ncBlU=.15f96d6b-52a5-448f-912f-c5e097fc3a1b@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
 <MlWig0TFj-P1lEmXY02h3pXpUizN-4WSJz8fi3Q1wBY=.2ff71fae-ba10-485d-bdb3-3c7872af58f9@github.com>
 <ckmS6PNp3cFdpiz4plQOkzWGNywUdADWYnZaM6ncBlU=.15f96d6b-52a5-448f-912f-c5e097fc3a1b@github.com>
Message-ID: <WQ7AidK5SqhuCP4PyU2jlMFEgPM96Q8_Z6MRq2D9Qhg=.e3e332eb-2cf0-456a-b944-5a2d4188ee9b@github.com>

On Mon, 24 Feb 2025 00:04:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename classes and add vm_exit_during_initialization call
>
> A couple of minor suggestions, but otherwise nothing further from me.
> 
> Thanks

@dholmes-ora, @ashu-mehra, @vnkozlov, @iklam Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23476#issuecomment-2679500022

From ccheung at openjdk.org  Mon Feb 24 19:58:14 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 24 Feb 2025 19:58:14 GMT
Subject: Integrated: 8280682: Refactor AOT code source validation checks
In-Reply-To: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
References: <Z2V1zfnQCb9SlJIVJPg1rqHVSa0CZAU3IDgWN3Z44A8=.845f0aff-b88e-44dd-8616-9fc5675acf04@github.com>
Message-ID: <kUrN3l5bZeL8DCXjThSgkvuB2IQwX5X3xqCCjraODxE=.cb7d0540-98f9-455e-8fad-95980efb6ae6@github.com>

On Wed, 5 Feb 2025 22:32:58 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This changset refactors CDS class paths and module paths validation code into a new class `AOTCodeSource` and related class `AOTCodeSourceConfig`. Code has been moved from filemap.[c|h]pp, classLoader.[c|h]pp, and classLoaderExt.[c|h]pp to aotCodeSource.[c|h]pp. CDS dependencies have been removed from `classLoader.cpp`. More refactoring could be done, such as removing `classLoaderExt.cpp`, in a future RFE.
> 
> Passed tiers 1 - 5 testing.

This pull request has now been integrated.

Changeset: ddb25691
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ddb256911032cd7e6fae17c342261276066d8d25
Stats:     3153 lines in 40 files changed: 1359 ins; 1615 del; 179 mod

8280682: Refactor AOT code source validation checks

Co-authored-by: Ioi Lam <iklam at openjdk.org>
Reviewed-by: iklam, asmehra, dholmes, kvn

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

PR: https://git.openjdk.org/jdk/pull/23476

From lmesnik at openjdk.org  Mon Feb 24 20:55:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 24 Feb 2025 20:55:52 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
Message-ID: <PA1a0wuLn0EVpPwIZN_Zl7fA1rZJ5_posVSqq7t0ZRI=.02c0ed34-ffc0-44e2-8322-665e130ed73e@github.com>

On Mon, 24 Feb 2025 11:40:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial removal of confusing "Tonga" references in comments within a few JMX tests.

Changes requested by lmesnik (Reviewer).

test/jdk/javax/management/MBeanServer/ExceptionTest.java line 227:

> 225:          * Reproduces the original parsing and collection of test parameters
> 226:          * from the DTonga JMX test suite.
> 227:          *

There are few similar methods
        static Map<String, Object> parseParameters(String args[])
in different Utils classes. 
Have you considered the removal of duplication code?
Also, the comment like 
" Reproduces the original parsing and collection of test parameters from legacy test suite"
might explain why this logic is needed. But it is up to you.

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

PR Review: https://git.openjdk.org/jdk/pull/23747#pullrequestreview-2638415485
PR Review Comment: https://git.openjdk.org/jdk/pull/23747#discussion_r1968403429

From schernyshev at openjdk.org  Mon Feb 24 21:20:49 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 24 Feb 2025 21:20:49 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
Message-ID: <QV8_TSQ8Ym5RE65TyC3cIlyTsB-vNxO5oRpnCvkRCwU=.cb32334b-6d40-4801-9a4b-1521756cbadf@github.com>

On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening.
> 

Done, added

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2679664923

From schernyshev at openjdk.org  Mon Feb 24 21:20:49 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 24 Feb 2025 21:20:49 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:

 - added high level comment to CgroupV1Controller::set_subsystem_path
 - fix minor issue calling .getNameCount() twice

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/28122ff9..3568c138

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=13-14

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Mon Feb 24 21:20:50 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 24 Feb 2025 21:20:50 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <E4B7c1WLUyhHGmEaox71qVNbypKMw_Hdo1dKU_RQcMY=.db21dfe9-e676-4ac6-b954-19bc40b64268@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
 <OObfj4QWk_Q3Fk2-mDJbpfeFNhOAbgEmDB-IBehjR4c=.672abfeb-fc3f-4c68-ad0d-693ac0eb7bcd@github.com>
 <E4B7c1WLUyhHGmEaox71qVNbypKMw_Hdo1dKU_RQcMY=.db21dfe9-e676-4ac6-b954-19bc40b64268@github.com>
Message-ID: <V7oEjruvb8foydYDCIvuupWtILQUk2S13hK5y5FWqys=.b32faff6-fb66-44eb-be04-656edf02f7ae@github.com>

On Fri, 21 Feb 2025 20:05:07 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Good catch, but as long as cgp#nameCount may change in the loop, this exact patch i cannot take.
>
> How about this?
> 
> int currentNameCount = cgp.getNameCount();
> cgp = (currentNameCount > 1) ? cgp.subpath(1, currentNameCount) : Path.of("");

I tested the builds with the above change. It seems to be doing the thing. Please see the updated PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1968429793

From kevinw at openjdk.org  Mon Feb 24 21:32:02 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Feb 2025 21:32:02 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <PA1a0wuLn0EVpPwIZN_Zl7fA1rZJ5_posVSqq7t0ZRI=.02c0ed34-ffc0-44e2-8322-665e130ed73e@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
 <PA1a0wuLn0EVpPwIZN_Zl7fA1rZJ5_posVSqq7t0ZRI=.02c0ed34-ffc0-44e2-8322-665e130ed73e@github.com>
Message-ID: <PDaz4s5MylQAL9IL8c4JdaNEGYIPuubY7N47rhzQuSs=.4a00e692-e7b8-44df-b925-e633da7d94be@github.com>

On Mon, 24 Feb 2025 20:53:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Trivial removal of confusing "Tonga" references in comments within a few JMX tests.
>
> test/jdk/javax/management/MBeanServer/ExceptionTest.java line 227:
> 
>> 225:          * Reproduces the original parsing and collection of test parameters
>> 226:          * from the DTonga JMX test suite.
>> 227:          *
> 
> There are few similar methods
>         static Map<String, Object> parseParameters(String args[])
> in different Utils classes. 
> Have you considered the removal of duplication code?
> Also, the comment like 
> " Reproduces the original parsing and collection of test parameters from legacy test suite"
> might explain why this logic is needed. But it is up to you.

Thanks -
For the paseParameters(arg) method, I think if I remove the reference to the mysterious legacy test suite, there is nothing left in that line worth saying.

The comment goes on to say "Collects passed args and returns them in a map..etc..." which seems worthwhile.

There probably is much further tidyup that we can do here, yes maybe the methods are the same, and maybe so may "Utils" classes is not great.  But I just wanted to remove this one point of confusion today!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23747#discussion_r1968442691

From lmesnik at openjdk.org  Mon Feb 24 21:36:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 24 Feb 2025 21:36:54 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
Message-ID: <KlZGPCLPzIEcG6YGcBA5iQEwS3wvwosxe2BMAsUbXsk=.604f5eef-9dc0-4486-b705-d816e3c4884f@github.com>

On Mon, 24 Feb 2025 11:40:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial removal of confusing "Tonga" references in comments within a few JMX tests.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23747#pullrequestreview-2638493231

From lmesnik at openjdk.org  Mon Feb 24 21:36:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 24 Feb 2025 21:36:56 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <PDaz4s5MylQAL9IL8c4JdaNEGYIPuubY7N47rhzQuSs=.4a00e692-e7b8-44df-b925-e633da7d94be@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
 <PA1a0wuLn0EVpPwIZN_Zl7fA1rZJ5_posVSqq7t0ZRI=.02c0ed34-ffc0-44e2-8322-665e130ed73e@github.com>
 <PDaz4s5MylQAL9IL8c4JdaNEGYIPuubY7N47rhzQuSs=.4a00e692-e7b8-44df-b925-e633da7d94be@github.com>
Message-ID: <v3CK4dDckXSofMRUh9Fs-KPFVj0Hz66u6SKARBvwSx0=.37a1d8b8-baaf-4de6-84b9-7b81dbf8866e@github.com>

On Mon, 24 Feb 2025 21:28:57 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/javax/management/MBeanServer/ExceptionTest.java line 227:
>> 
>>> 225:          * Reproduces the original parsing and collection of test parameters
>>> 226:          * from the DTonga JMX test suite.
>>> 227:          *
>> 
>> There are few similar methods
>>         static Map<String, Object> parseParameters(String args[])
>> in different Utils classes. 
>> Have you considered the removal of duplication code?
>> Also, the comment like 
>> " Reproduces the original parsing and collection of test parameters from legacy test suite"
>> might explain why this logic is needed. But it is up to you.
>
> Thanks -
> For the paseParameters(arg) method, I think if I remove the reference to the mysterious legacy test suite, there is nothing left in that line worth saying.
> 
> The comment goes on to say "Collects passed args and returns them in a map..etc..." which seems worthwhile.
> 
> There probably is much further tidyup that we can do here, yes maybe the methods are the same, and maybe so may "Utils" classes is not great.  But I just wanted to remove this one point of confusion today!

The link to legacy is a just good explanation why this method is realized in such way. Like note, "There is might be no logic in this method, just legacy."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23747#discussion_r1968448707

From kevinw at openjdk.org  Mon Feb 24 21:48:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Feb 2025 21:48:53 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <v3CK4dDckXSofMRUh9Fs-KPFVj0Hz66u6SKARBvwSx0=.37a1d8b8-baaf-4de6-84b9-7b81dbf8866e@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
 <PA1a0wuLn0EVpPwIZN_Zl7fA1rZJ5_posVSqq7t0ZRI=.02c0ed34-ffc0-44e2-8322-665e130ed73e@github.com>
 <PDaz4s5MylQAL9IL8c4JdaNEGYIPuubY7N47rhzQuSs=.4a00e692-e7b8-44df-b925-e633da7d94be@github.com>
 <v3CK4dDckXSofMRUh9Fs-KPFVj0Hz66u6SKARBvwSx0=.37a1d8b8-baaf-4de6-84b9-7b81dbf8866e@github.com>
Message-ID: <IrNLtzg-RdCJDDsDE0Z6B-Kg7g6OYiGIp_fZp4TN2xM=.a0b9cd51-2bc4-448f-921f-cbf6606871ae@github.com>

On Mon, 24 Feb 2025 21:34:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Thanks -
>> For the paseParameters(arg) method, I think if I remove the reference to the mysterious legacy test suite, there is nothing left in that line worth saying.
>> 
>> The comment goes on to say "Collects passed args and returns them in a map..etc..." which seems worthwhile.
>> 
>> There probably is much further tidyup that we can do here, yes maybe the methods are the same, and maybe so may "Utils" classes is not great.  But I just wanted to remove this one point of confusion today!
>
> The link to legacy is a just good explanation why this method is realized in such way. Like note, "There is might be no logic in this method, just legacy."

That's a bit harsh, I wasn't going to say there was no logic to this! 8-)
Code this old and quirky (and duplicated...) is kind of legacy by definition. 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23747#discussion_r1968461046

From lmesnik at openjdk.org  Mon Feb 24 21:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 24 Feb 2025 21:55:54 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <IrNLtzg-RdCJDDsDE0Z6B-Kg7g6OYiGIp_fZp4TN2xM=.a0b9cd51-2bc4-448f-921f-cbf6606871ae@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
 <PA1a0wuLn0EVpPwIZN_Zl7fA1rZJ5_posVSqq7t0ZRI=.02c0ed34-ffc0-44e2-8322-665e130ed73e@github.com>
 <PDaz4s5MylQAL9IL8c4JdaNEGYIPuubY7N47rhzQuSs=.4a00e692-e7b8-44df-b925-e633da7d94be@github.com>
 <v3CK4dDckXSofMRUh9Fs-KPFVj0Hz66u6SKARBvwSx0=.37a1d8b8-baaf-4de6-84b9-7b81dbf8866e@github.com>
 <IrNLtzg-RdCJDDsDE0Z6B-Kg7g6OYiGIp_fZp4TN2xM=.a0b9cd51-2bc4-448f-921f-cbf6606871ae@github.com>
Message-ID: <cXCJQZEdTwoIwh2pYkMwE6zsCI1DWsV_V6AX8JhyMOw=.a571ed08-5ee7-4f29-a81c-5ae77c8799ab@github.com>

On Mon, 24 Feb 2025 21:46:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The link to legacy is a just good explanation why this method is realized in such way. Like note, "There is might be no logic in this method, just legacy."
>
> That's a bit harsh, I wasn't going to say there was no logic to this! 8-)
> Code this old and quirky (and duplicated...) is kind of legacy by definition. 8-)

Yes, better to rewrite it of course, but now it becomes unclear why it was written at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23747#discussion_r1968469210

From kevinw at openjdk.org  Mon Feb 24 22:02:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Feb 2025 22:02:56 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <cXCJQZEdTwoIwh2pYkMwE6zsCI1DWsV_V6AX8JhyMOw=.a571ed08-5ee7-4f29-a81c-5ae77c8799ab@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
 <PA1a0wuLn0EVpPwIZN_Zl7fA1rZJ5_posVSqq7t0ZRI=.02c0ed34-ffc0-44e2-8322-665e130ed73e@github.com>
 <PDaz4s5MylQAL9IL8c4JdaNEGYIPuubY7N47rhzQuSs=.4a00e692-e7b8-44df-b925-e633da7d94be@github.com>
 <v3CK4dDckXSofMRUh9Fs-KPFVj0Hz66u6SKARBvwSx0=.37a1d8b8-baaf-4de6-84b9-7b81dbf8866e@github.com>
 <IrNLtzg-RdCJDDsDE0Z6B-Kg7g6OYiGIp_fZp4TN2xM=.a0b9cd51-2bc4-448f-921f-cbf6606871ae@github.com>
 <cXCJQZEdTwoIwh2pYkMwE6zsCI1DWsV_V6AX8JhyMOw=.a571ed08-5ee7-4f29-a81c-5ae77c8799ab@github.com>
Message-ID: <CBool9UaXs5HnlU8-2D2wyacTex8wbEVWzbKapPdlkE=.ffa20027-f83a-4554-ab7e-97e706c4dc1e@github.com>

On Mon, 24 Feb 2025 21:53:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> That's a bit harsh, I wasn't going to say there was no logic to this! 8-)
>> Code this old and quirky (and duplicated...) is kind of legacy by definition. 8-)
>
> Yes, better to rewrite it of course, but now it becomes unclear why it was written at all.

I will go with this change for now, maybe we can come back here!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23747#discussion_r1968476603

From kevinw at openjdk.org  Mon Feb 24 22:02:55 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Feb 2025 22:02:55 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
Message-ID: <aBq2NBxzvO7lFWIa-3U95Mq1ANGX-TLzjwb3E8_svjA=.6ae784d3-0ff3-4fbe-b273-03a58c5843e2@github.com>

On Mon, 24 Feb 2025 11:40:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial removal of confusing "Tonga" references in comments within a few JMX tests.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23747#issuecomment-2679752104

From sspitsyn at openjdk.org  Mon Feb 24 22:54:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 24 Feb 2025 22:54:56 GMT
Subject: RFR: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
Message-ID: <8MUZf1VSJtsosbJf34azIYpMFtRUSDOafdXI9IoAaL0=.92773edb-0fbc-4924-b5cd-ac7bce1afb08@github.com>

On Mon, 24 Feb 2025 11:40:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial removal of confusing "Tonga" references in comments within a few JMX tests.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23747#pullrequestreview-2638631761

From schernyshev at openjdk.org  Mon Feb 24 23:35:58 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 24 Feb 2025 23:35:58 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
Message-ID: <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>

On Mon, 17 Feb 2025 14:04:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.

The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`.

========== NEW TEST CASE:      Cgroup V1 subgroup memory limit: 100m
[COMMAND]
docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version
[2025-02-24T22:33:28.049656218Z] Gathering output for process 23369
[ELAPSED: 5385 ms]
[STDERR]

[STDOUT]
[0.002s][trace][os,container] OSContainer::init: Initializing Container Support
[0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
[0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.

With additional logging added before line 77, this could be looking like

[STDOUT]
[0.002s][trace][os,container] OSContainer::init: Initializing Container Support
[0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
[0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
[0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
[0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.

Before the fix, the current path adjustment scheme would produce the following order:

/sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test
/sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370
/sys/fs/cgroup/memory/docker
/sys/fs/cgroup/memory

Only the last path is valid in the container, others are non-existent. The result will be 200m, while the correct is 100m.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2679936058

From cjplummer at openjdk.org  Tue Feb 25 02:33:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Feb 2025 02:33:53 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
Message-ID: <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>

On Mon, 24 Feb 2025 12:39:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> To be sure, I did a minimal build on Linux x86_64. I set `--with-jvm-features=minimal --with-jvm-variants=minimal` for this.
> This leads to
> `JVM_FEATURES_minimal='compiler1 minimal opt-size serialgc'`
> So no jvmti, to GCs except serialgc . Just C1, no C2. The 'opt-size' flag is set so the libjvm is compiled with size optimization (on Linux -Os). The other native libs (JDK native libs) still use the opt-flags they always use, as I thought.

"minimal" if a very specific footprint reducing build configuration. However, I believe what it does is enable a bunch of other individual footprint reduction features. For example, even without configuring specifically for minimal, you can optionally exclude JVMTI, or extra GCs, or C2, and I think you can optionally configure libjvm.so to be built for small size, not performance. It's not "all or none", but we don't really encourage (or officially support) selectively choosing what to exclude because it is not well tested.

> On the other hand we can achieve good performance and smaller binaries with lto (at least with gcc).

Absence of benchmarking and given the relatively small footprint savings, I don't think we should switch to SIZE. LTO seems fine. I don't know of any negative impacts with using it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2680236696

From asmehra at openjdk.org  Tue Feb 25 06:37:57 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 25 Feb 2025 06:37:57 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
Message-ID: <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>

On Thu, 20 Feb 2025 13:14:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   avoid Thread::current in high traffic chunk alloc path

src/hotspot/share/compiler/compilationMemStatInternals.hpp line 92:

> 90: 
> 91: // A very simple fixed-width FIFO buffer, used for the phase timeline
> 92: template <typename T, int max>

Would `size` be a better name than `max`?

src/hotspot/share/compiler/compilationMemStatInternals.hpp line 160:

> 158:     void init(T v)        { start = cur = peak = v; }
> 159:     void update(T v)      { cur = v; if (v > peak) peak = v; }
> 160:     dT end_delta() const  { return (dT)cur - (dT)start; }

Should it be `return (dT)(cur - start); }`

src/hotspot/share/compiler/compilationMemStatInternals.hpp line 161:

> 159:     void update(T v)      { cur = v; if (v > peak) peak = v; }
> 160:     dT end_delta() const  { return (dT)cur - (dT)start; }
> 161:     size_t temporary_peak_size() const { return MIN2(peak - cur, peak - start); }

shouldn't it be `MAX2(peak - cur, peak - start)`? Why not just `peak - start`?

src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 149:

> 147:       int col = start_indent;
> 148:       check_phase_trace_id(e.info.id);
> 149:       if (omit_empty_phases && e._bytes.end_delta() == 0 && e._bytes.temporary_peak_size() == 0) {

`omit_empty_phases` is always false. Can it be just removed?

src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 205:

> 203:     // seed current entry
> 204:     Entry& e = _fifo.current();
> 205:     e._bytes.start = e._bytes.cur = e._bytes.peak = cur_abs;

This can be replaced by `e._bytes.init(cur_abs)`.
Same for the next statement.
On same lines I would suggest to add `Entry::init()` and call it here.

src/hotspot/share/memory/arena.hpp line 48:

> 46:   const size_t _len;      // Size of this Chunk
> 47:   // Used for Compilation Memory Statistic
> 48:   uint64_t _stamp;

This is wasted space if compilation memory stats is not enabled. One way to avoid this is to subclass `Chunk` as a `StampedChunk` and use that if compilation memory stats is enabled. Is this complexity worth the space saving?

src/hotspot/share/opto/phase.hpp line 125:

> 123:     f(   _t_temporaryTimer1,         "tempTimer1")               \
> 124:     f(   _t_temporaryTimer2,         "tempTimer2")               \
> 125:     f(   _t_testTimer1,              "testTimer1")               \

Would `_t_testPhase1` and `_t_testPhase2` be a better name?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1968993551
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1968993720
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1968993803
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1968994072
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1968994121
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1968999519
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1969041777

From mbaesken at openjdk.org  Tue Feb 25 09:17:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Feb 2025 09:17:00 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
Message-ID: <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>

On Tue, 25 Feb 2025 02:31:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Absence of benchmarking and given the relatively small footprint savings, I don't think we should switch to SIZE. LTO seems fine.  I don't know of any negative impacts with using it.

@TheShermanTanker , @magicus  what do you think ? Should we additionally offer  LTO on library level ?
See
https://github.com/openjdk/jdk/blob/master/make/common/native/Flags.gmk#L43

Currently we only have it as an additional option for libjvm and not the other native libs .

>  I think you can optionally configure libjvm.so to be built for small size, not performance

Yes true for libjvm this is possible, it is the opt-size  part of the minimal features set
`JVM_FEATURES_minimal='compiler1 minimal opt-size serialgc'`

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2681231574
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2681239626

From jwaters at openjdk.org  Tue Feb 25 09:36:54 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Feb 2025 09:36:54 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
Message-ID: <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>

On Tue, 25 Feb 2025 09:12:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Absence of benchmarking and given the relatively small footprint savings, I don't think we should switch to SIZE. LTO seems fine.  I don't know of any negative impacts with using it.
> 
> @TheShermanTanker , @magicus what do you think ? Should we additionally offer LTO on library level ? See https://github.com/openjdk/jdk/blob/master/make/common/native/Flags.gmk#L43
> 
> Currently we only have it as an additional option for libjvm and not the other native libs .

I'm not sure what that line in Flags.gmk has to do with LTO support, since it's setting the optimization levels. That said, while I'm in favour of an option that you can set to enable LTO for native JDK code (Like I have in my fork), I don't think we should do it piece by piece like this, as Kim mentioned. This probably needs to be part of a more focused effort

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2681314114

From stuefe at openjdk.org  Tue Feb 25 10:03:09 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 10:03:09 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <tWs8dyZ9EEBoAO9VWb5gLXUCuFqn4RUY9H3GmaCOQTc=.8b17bb77-7556-43dd-bf29-5d177acd893a@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
 <tWs8dyZ9EEBoAO9VWb5gLXUCuFqn4RUY9H3GmaCOQTc=.8b17bb77-7556-43dd-bf29-5d177acd893a@github.com>
Message-ID: <dk99VBAt7zP6MyC7BRDKxptsKKyknBtVxjY4SQvhxZU=.d8ac8105-7c84-4dc1-b09e-4da03c77bebf@github.com>

On Mon, 24 Feb 2025 10:10:50 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   avoid Thread::current in high traffic chunk alloc path
>
> src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 255:
> 
>> 253:   char tmp[1024];
>> 254:   _k->as_C_string(tmp, sizeof(tmp));
>> 255: if (UseNewCode){ printf("%s\n",tmp); fflush(stdout);}
> 
> I guess this use of `UseNewCode` is not meant to be integrated?

Yes, that was an error . I'll remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1969430129

From stuefe at openjdk.org  Tue Feb 25 10:23:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 10:23:00 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <_oNuzx4YepRchoguAnBbXw-31T14WgK8oQpC47FAJOc=.6edd8fcc-6757-448b-992d-b13b94af7c59@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
 <_oNuzx4YepRchoguAnBbXw-31T14WgK8oQpC47FAJOc=.6edd8fcc-6757-448b-992d-b13b94af7c59@github.com>
Message-ID: <_DyA72zJiCDj4xhjrKurD_l533AuXJk4fsLac4KR6Ww=.e8b40eac-da62-48ee-b2c5-c74a15d358c0@github.com>

On Mon, 24 Feb 2025 10:19:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   avoid Thread::current in high traffic chunk alloc path
>
> src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 1093:
> 
>> 1091:       Compile::TracePhase tp(Phase::_t_testTimer1);
>> 1092:       Arena ar(MemTag::mtCompiler, Arena::Tag::tag_reglive);
>> 1093:       ar.Amalloc(2 * M); // phase-local peak, should show up at MY-TESTPHASE-2
> 
> The reference to `MY-TESTPHASE-2` seems obsolete.

Removed

> test/hotspot/jtreg/compiler/print/CompileCommandMemLimit.java line 105:
> 
>> 103:         // by phase end. So, in the phase timeline these 2MB must show up as "significant temporary peak".
>> 104:         // In testPhase2, we allocate 32MB from resource area, which is leaked until the end of the compilation. This
>> 105:         // means that these 32MB will show up as permanent memory increase in the phasetimeline.
> 
> The references to `testPhase` seem obsolete, do you mean `Phase::_t_testTimer1` and `Phase::_t_testTimer2`?

Right you are

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1969475279
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1969475077

From ayang at openjdk.org  Tue Feb 25 11:17:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Feb 2025 11:17:06 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME [v4]
In-Reply-To: <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
 <rDK-Paj3qg0kA9UEg3fw5ZuWTYOXdrZLCsYLwCEDyKQ=.2ebbcc30-b222-4653-815a-8ed304554d02@github.com>
Message-ID: <AV6q11HT532OG2K9O-4wL5UpMwHe7_EvVeVfEiIrgME=.cd184d47-da60-407e-8862-065eef4a9526@github.com>

On Tue, 18 Feb 2025 09:20:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
>> 
>> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
>> 
>> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
>> 
>> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - review
>  - Merge branch 'master' into gclocker
>  - gclocker

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2681608369

From ayang at openjdk.org  Tue Feb 25 11:17:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Feb 2025 11:17:07 GMT
Subject: Integrated: 8192647: GClocker induced GCs can starve threads requiring
 memory leading to OOME
In-Reply-To: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
References: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>
Message-ID: <SMx3DDDejcz7_yIQKEGQJQVWXKbnEIjSjCJ3shuJR9Y=.452f1f35-47a5-4009-90db-3fb672f5e32f@github.com>

On Thu, 30 Jan 2025 12:12:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Here is an attempt to simplify GCLocker implementation for Serial and Parallel.
> 
> GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.
> 
> The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.
> 
> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.
> 
> Test: tier1-8

This pull request has now been integrated.

Changeset: a9c9f7f0
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9c9f7f0cbb2f2395fef08348bf867ffa8875d73
Stats:     985 lines in 41 files changed: 50 ins; 822 del; 113 mod

8192647: GClocker induced GCs can starve threads requiring memory leading to OOME

Reviewed-by: tschatzl, iwalulya, egahlin

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

PR: https://git.openjdk.org/jdk/pull/23367

From kevinw at openjdk.org  Tue Feb 25 12:57:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Feb 2025 12:57:01 GMT
Subject: Integrated: 8350571: Remove mention of Tonga test suite from JMX tests
In-Reply-To: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
References: <f4Z5yQWmvQ0xSbqT83qymnHeS6YyBpkLLakh5BfXZz8=.e127dbce-6d73-407d-a77d-e4e428466dfd@github.com>
Message-ID: <be4lAM-LfOs6ymXCcZvFPG761-rBGcIfrwAJ-LGZap4=.d325bde7-882d-4833-b5b0-00971ddfeb0f@github.com>

On Mon, 24 Feb 2025 11:40:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Trivial removal of confusing "Tonga" references in comments within a few JMX tests.

This pull request has now been integrated.

Changeset: 8cfebc41
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8cfebc41dc8ec7b0d24d9c467b91de82d28b73fc
Stats:     27 lines in 5 files changed: 0 ins; 20 del; 7 mod

8350571: Remove mention of Tonga test suite from JMX tests

Reviewed-by: cjplummer, lmesnik, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/23747

From mbaesken at openjdk.org  Tue Feb 25 13:11:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Feb 2025 13:11:56 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
 <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>
Message-ID: <IysDv8wYLav6qy--70_RuInWK9CxnwuW6PfcHybdG1o=.b996ae42-763b-422e-afdd-450fe7a80bb3@github.com>

On Tue, 25 Feb 2025 09:33:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I'm not sure what that line in Flags.gmk has to do with LTO support, since it's setting the optimization levels.

We could offer there another option LTO, additionally to LOW, HIGH, HIGHEST, SIZE etc.  .

> I don't think we should do it piece by piece like this, as Kim mentioned.

I am not sure if it is currently a good idea to set LTO for all  JDK native libs; but for some it might work well and be beneficial.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2681932988

From jwaters at openjdk.org  Tue Feb 25 13:16:00 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Feb 2025 13:16:00 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <IysDv8wYLav6qy--70_RuInWK9CxnwuW6PfcHybdG1o=.b996ae42-763b-422e-afdd-450fe7a80bb3@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
 <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>
 <IysDv8wYLav6qy--70_RuInWK9CxnwuW6PfcHybdG1o=.b996ae42-763b-422e-afdd-450fe7a80bb3@github.com>
Message-ID: <BFPjw8r0kjzH9JVM7oLQGSzPxZKT3UcZ3m3pMKHIl4Q=.31040bca-a1a9-4643-9d24-abbbaf9cf668@github.com>

On Tue, 25 Feb 2025 13:09:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I'm not sure what that line in Flags.gmk has to do with LTO support, since it's setting the optimization levels.
> 
> We could offer there another option LTO, additionally to LOW, HIGH, HIGHEST, SIZE etc. .
> 
> > I don't think we should do it piece by piece like this, as Kim mentioned.
> 
> I am not sure if it is currently a good idea to set LTO for all JDK native libs; but for some it might work well and be beneficial.

Maybe I can prepare a changeset for this and send the diff just to get a cursory review on the changes, and see where to go from there. In my fork I have an --enable-linktime-opt option that enables LTO, so it would be an opt in change, and not an immediate change to the default linking behaviour, which I think is a no go as you mentioned

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2681943267

From mbaesken at openjdk.org  Tue Feb 25 13:19:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Feb 2025 13:19:01 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <BFPjw8r0kjzH9JVM7oLQGSzPxZKT3UcZ3m3pMKHIl4Q=.31040bca-a1a9-4643-9d24-abbbaf9cf668@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
 <cpQAO47YRpYHbJ-FHR9bQPGlqXGRC5bdPVEqEvOPkJw=.a7ae0c35-dc98-4078-9753-151a370ac490@github.com>
 <IysDv8wYLav6qy--70_RuInWK9CxnwuW6PfcHybdG1o=.b996ae42-763b-422e-afdd-450fe7a80bb3@github.com>
 <BFPjw8r0kjzH9JVM7oLQGSzPxZKT3UcZ3m3pMKHIl4Q=.31040bca-a1a9-4643-9d24-abbbaf9cf668@github.com>
Message-ID: <V019J5n2eX_4A-VkpxGzUTmfHhrJ_eO9i8S2Qg0r1uw=.c99dd335-3187-4350-b74e-9c7345a63f5d@github.com>

On Tue, 25 Feb 2025 13:13:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > 
> > I am not sure if it is currently a good idea to set LTO for all JDK native libs; but for some it might work well and be beneficial.
> 
> Maybe I can prepare a changeset for this and send the diff just to get a cursory review on the changes, and see where to go from there. In my fork I have an --enable-linktime-opt option that enables LTO, so it would be an opt in change, and not an immediate change to the default linking behaviour, which I think is a no go as you mentioned

Would be good !

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2681951282

From sgehwolf at openjdk.org  Tue Feb 25 14:04:20 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Feb 2025 14:04:20 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
 <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>
Message-ID: <M36QkeYGfvJTfI8SSdGW6wSzUCq_8HBcI6JDCAqEvdg=.3f426fc5-bbc9-473a-a229-3cb48dc95d46@github.com>

On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening.
>> 
>> Testing:
>>>>And after the patch this would become this, right?
>>>>```
>>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>>>/sys/fs/cgroup/cpu,cpuacct/
>>>>```
>>>
>>>It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be
>>>
>>>```
>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>>/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c
>>>/sys/fs/cgroup/cpu,cpuacct/bad
>>>/sys/fs/cgroup/cpu,cpuacct/
>>>```
>> 
>> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.
>
>> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.
> 
> The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`.
> 
> ========== NEW TEST CASE:      Cgroup V1 subgroup memory limit: 100m
> [COMMAND]
> docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version
> [2025-02-24T22:33:28.049656218Z] Gathering output for process 23369
> [ELAPSED: 5385 ms]
> [STDERR]
> 
> [STDOUT]
> [0.002s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.
> 
> With additional logging added before line 77, this could be looking like
> 
> [STDOUT]
> [0.002s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
> [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
> [0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.
> 
> Before the fix, the current path adjustment scheme would produce the following order:
> 
> /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test
> /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370
> /sys/fs/cgroup/memory/docker
> /sys/fs/cgroup/memory
> 
> Only the last path is valid in the conta...

@sercher As far as I can see this is a fairly simple case which would be covered by a simpler patch. My comment was in regards to my comment [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865630320). Where you replied with [this answer](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436). I don't see where anything you've described in your answer is being tested, covering this new code:

https://github.com/openjdk/jdk/pull/21808/files#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9R63-R77

That is, some sub-group without a match, but some with one.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2682078012

From sgehwolf at openjdk.org  Tue Feb 25 14:09:03 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Feb 2025 14:09:03 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
Message-ID: <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>

On Mon, 24 Feb 2025 21:20:49 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - added high level comment to CgroupV1Controller::set_subsystem_path
>  - fix minor issue calling .getNameCount() twice

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 42:

> 40:  * When runs in a container, the method handles the case
> 41:  * when a process is moved between cgroups.
> 42:  */

This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1969851316

From ihse at openjdk.org  Tue Feb 25 15:03:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 15:03:55 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <2sWUsIrECG5F5g_fAVosUBjFRqFrGpcVc9xZkW0qqKQ=.abdf14dd-973b-4865-9593-5bbb36634284@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

Hi, sorry for my absence. Some general comments based on the discussions here:

1) As Matthias has correctly understood, there is very little known about the reasoning of the current optimization levels. They were all done much prior to me joining the build team, and the rewriting of the build system. The current "optimization levels" where the result of trying to reverse-engineering what was de facto done in the old build system, and trying to make some kind of sense out of it. I think we can safely assume that there are no real well-founded reasons for any of the current optimization flags, except for specific exceptions like Hotspot.

2) We have been very cautious in changing these flags (including how we copied the old flags precisely from the old build system), but I've more and more come to the conclusion that this conversative approach is not really helpful. Changing optimization flags is most likely not more likely to provoke unforeseen problems than upgrading the compiler, and that is something we do regularly.

3) Furthermore, it is not by any means clear that e.g. -Os on gcc 5 means even close to the same thing, in terms of generated code, as -Os on gcc 14. The *intention* is clear -- i.e. optimize for size, but I think it would be a reasonable assumption that the actually generated code (which is what we care about in the end) will not share much similarities between now and the time at which the specific compiler optimization flag was chosen.

So, in essence, I highly support Matthias's work on updating these flags. More specifically, I think it will make sense for the most cases to use SIZE instead of LOW. My general feeling, from working with other optimization efforts in the past, is that optimizing for size in most cases also renders a benefit in speed, most likely arising from the code fitting better in caches, and perhaps doing shorter jumps, so it is typically a win-win scenario.

Otoh, we could probably raise the bar and optimize for performance (HIGH or HIGHEST) on several libraries that are currently LOW, even if the consequences are less clear. Most such libraries are only heavily used in specialized scenarios. If these scenarios are *only* microbenchmarks, then we should not care. But if there is some chance that a real application has a real payload that involves stressing some native library, then I see no reason *not* to increase the optimization level, if we can prove (with microbenchmarks) that this does indeed help performance.

Then finally there is a third aspect, on top of end-user application performance and JDK footprint, and that is the build time. More optimization tend to mean longer build times. In particular, LTO has been known to be very time consuming. (This might have changed with some of the recent efforts in improving LTO; I'm not fully up to speed in that area, but in any case, we're not using any new fancy methods in the JDK as of now.)

I don't doubt that LTO will make wonders for the size, and probably performance, of any native library. But it is also likely to come at a significant increase in build time for these libraries. How much that matters on the whole -- if there are no build dependencies waiting for the library, and we can parallelize the build reasonably, and given that we do a lot more than just compile and link native libraries -- I don't know.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2682282702

From ihse at openjdk.org  Tue Feb 25 15:11:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Feb 2025 15:11:57 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

I think it might be worth trying to take a more structured approach to the optimizations used. Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead. Ideally, we would also have some kind of microbenchmark associated with each library that could say anything about the performance of the library, but that is probably not realistic in most cases. But I guess that people familiar with the library can make some educated guess about the performance sensitivity of the libraries, and what would stress them.

Furthermore, I think we can definitely consider changes in the build system to support some of the requests that have arisen here, like allowing JDK libraries (apart from Hotspot) to allow LTO, or to have a way to override optimization levels for JDK libraries from the configure command line, similar to the JVM feature `opt-size`.

I am also open to reconsidering the entire idea of "optimization levels" the way it is currently implemented. Developers tend to think in terms of `-O2`, and our named optimization levels just inserts an extra layer of uncertainty ("what does `HIGHEST` really mean?). A problem is of course that different compilers have different ways of expressing optimization (most clearly how the Microsoft VS compiler differs from gcc/clang), but then again, maybe that just means that we should express this as:


   OPT_gcc_clang := -O1, \
   OPT_microsoft := -O2. \


since it is not obvious that there really is a good way to package different optimization flags for different compilers that make sense for all libraries. Our current code assumes this is the case, but this does not necessarily have to be true.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2682315156

From stuefe at openjdk.org  Tue Feb 25 15:49:32 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 15:49:32 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v5]
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <nwgrljO8AxcINf9s5IiZGEFMXfSc_BMl3STAEX65orU=.6f850ac8-4ca0-4313-9533-1086a01afd37@github.com>

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/opto/chaitin.cpp
  
  Co-authored-by: Roberto Casta?eda Lozano <robcasloz at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23530/files
  - new: https://git.openjdk.org/jdk/pull/23530/files/dd7a06ad..2c56b216

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/23530

From stuefe at openjdk.org  Tue Feb 25 16:18:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 16:18:57 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
 <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
Message-ID: <ICOrVtN9o06dHWoN92q2Pi5aEsUdPYgZhMiBBYL9onk=.3d6d843b-f173-4512-b98a-6f54c0bb0c95@github.com>

On Tue, 25 Feb 2025 05:57:28 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   avoid Thread::current in high traffic chunk alloc path
>
> src/hotspot/share/compiler/compilationMemStatInternals.hpp line 92:
> 
>> 90: 
>> 91: // A very simple fixed-width FIFO buffer, used for the phase timeline
>> 92: template <typename T, int max>
> 
> Would `size` be a better name than `max`?

ok changed

> src/hotspot/share/compiler/compilationMemStatInternals.hpp line 160:
> 
>> 158:     void init(T v)        { start = cur = peak = v; }
>> 159:     void update(T v)      { cur = v; if (v > peak) peak = v; }
>> 160:     dT end_delta() const  { return (dT)cur - (dT)start; }
> 
> Should it be `return (dT)(cur - start); }`

hmm, I like to avoid the inner overflow is cur < start (if the phase released more memory than it allocated)

> src/hotspot/share/compiler/compilationMemStatInternals.hpp line 161:
> 
>> 159:     void update(T v)      { cur = v; if (v > peak) peak = v; }
>> 160:     dT end_delta() const  { return (dT)cur - (dT)start; }
>> 161:     size_t temporary_peak_size() const { return MIN2(peak - cur, peak - start); }
> 
> shouldn't it be `MAX2(peak - cur, peak - start)`? Why not just `peak - start`?

We are only interested in a rise that rose significantly above **both** the start and end point of the measurements. 

E.g.:
- if we have this: start = 0, end = 20MB, peak = 20MB, this is not a temporary peak and we already know that the end usage is 20MB.
- if we have this: start = 20MB, end = 0, peak = 20MB, this is not a temporary peak either, because we already know the starting footprint was 20MB.
- but if we have start = 0, end = 0, peak = 20MB, this is interesting since if we just print start and end we will miss the fact that in between those times we had temporarily allocated 20MB.

> src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 149:
> 
>> 147:       int col = start_indent;
>> 148:       check_phase_trace_id(e.info.id);
>> 149:       if (omit_empty_phases && e._bytes.end_delta() == 0 && e._bytes.temporary_peak_size() == 0) {
> 
> `omit_empty_phases` is always false. Can it be just removed?

I hesitated to throw this out because the timeline can get very wordy; but I got used to the more expressive timeline with the 0 entries, so okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970105585
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970105238
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970103141
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970110006

From stuefe at openjdk.org  Tue Feb 25 16:29:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 16:29:02 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
 <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
Message-ID: <FDB-rS9R-SncsgDtKiVqh9RA0gZMaPSD6rC5ZjBTezo=.dd54b6f7-fce5-440c-b074-c2b42f0195c5@github.com>

On Tue, 25 Feb 2025 06:03:21 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   avoid Thread::current in high traffic chunk alloc path
>
> src/hotspot/share/memory/arena.hpp line 48:
> 
>> 46:   const size_t _len;      // Size of this Chunk
>> 47:   // Used for Compilation Memory Statistic
>> 48:   uint64_t _stamp;
> 
> This is wasted space if compilation memory stats is not enabled. One way to avoid this is to subclass `Chunk` as a `StampedChunk` and use that if compilation memory stats is enabled. Is this complexity worth the space saving?

I'd like to avoid that complexity. Arena coding is already needlessly complex. Note that a chunk is variable-sized and typically 1Kb in size or larger, and we should not have that many chunks in live arenas at any given moment (some hundred maybe). Note also that using 8 bytes seems wasteful, but the payload section has to be aligned to void* anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970128193

From schernyshev at openjdk.org  Tue Feb 25 16:34:04 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 25 Feb 2025 16:34:04 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
 <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>
Message-ID: <pK7gXk5Nv6_6EMQS-sqQprcMMz_v6y305aUNaal7EWA=.3a1033fe-867a-439d-9041-683be9e83019@github.com>

On Tue, 25 Feb 2025 14:06:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?

Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970137041

From stuefe at openjdk.org  Tue Feb 25 16:43:21 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 16:43:21 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v6]
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Thomas Stuefe has updated the pull request incrementally with five additional commits since the last revision:

 - feedback ashu
 - feedback roberto
 - final-statistics-switch
 - performance fix
 - remove test code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23530/files
  - new: https://git.openjdk.org/jdk/pull/23530/files/2c56b216..3052ddf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23530&range=04-05

  Stats: 66 lines in 11 files changed: 9 ins; 22 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/23530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23530/head:pull/23530

PR: https://git.openjdk.org/jdk/pull/23530

From stuefe at openjdk.org  Tue Feb 25 16:43:21 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 16:43:21 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <NfX5WX4NU_kD7dQcZjpaN3z28TDcsg2OIJjXjpZv_-s=.34848957-da62-430c-ae40-a57f32f10cfb@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
 <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
 <0wHGNSlwe7cWb7Plad2n8Swy8rayYTAf5IETuw9zl4U=.a4d6a129-aebc-4639-aaef-92ee6c4552c7@github.com>
 <NfX5WX4NU_kD7dQcZjpaN3z28TDcsg2OIJjXjpZv_-s=.34848957-da62-430c-ae40-a57f32f10cfb@github.com>
Message-ID: <5UAbfNQNxn--W_diVazFvldvScMGE59vVfpWJ4GUziA=.24361d75-77c9-418d-830e-797cac10f4b9@github.com>

On Mon, 24 Feb 2025 08:56:51 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>>> @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
>>> 
>>> With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.
>> 
>> Great, thanks! Will re-run benchmarking and report results early next week.
>
>> > @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
>> > With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.
>> 
>> Great, thanks! Will re-run benchmarking and report results early next week.
> 
> Functional test results (Oracle tier1-5) still look good for the latest commit (dd7a06ad). I can confirm that the C2 speed regression on our linux-x64 machines is almost fully mitigated. The 2-3% regression on our macosx-aarch64 machines does not seem to be addressed by the latest changes though, but as I mentioned before I think it is in the acceptable range (and only affects one benchmark).

@robcasloz, @ashu-mehra thanks a lot for your reviews. I incorporated most of them into the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2682609306

From stuefe at openjdk.org  Tue Feb 25 16:43:22 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 16:43:22 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <ICOrVtN9o06dHWoN92q2Pi5aEsUdPYgZhMiBBYL9onk=.3d6d843b-f173-4512-b98a-6f54c0bb0c95@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
 <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
 <ICOrVtN9o06dHWoN92q2Pi5aEsUdPYgZhMiBBYL9onk=.3d6d843b-f173-4512-b98a-6f54c0bb0c95@github.com>
Message-ID: <wIQaL7hFTI_wwFe4uQr54Bycz-H1ENV7mPpgze7lGVE=.d22708e9-2bdc-4720-89b8-4e7a54046c3f@github.com>

On Tue, 25 Feb 2025 16:13:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/compiler/compilationMemStatInternals.hpp line 92:
>> 
>>> 90: 
>>> 91: // A very simple fixed-width FIFO buffer, used for the phase timeline
>>> 92: template <typename T, int max>
>> 
>> Would `size` be a better name than `max`?
>
> ok changed

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970154273

From stuefe at openjdk.org  Tue Feb 25 16:43:22 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Feb 2025 16:43:22 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
 <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
Message-ID: <LRTjK-k_5ZF4gh01VpqcxuVrxMgCzdqpkuJUvHmPWks=.a24cc8e2-07c3-46b2-9b55-c6e54a080e25@github.com>

On Tue, 25 Feb 2025 06:34:29 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   avoid Thread::current in high traffic chunk alloc path
>
> src/hotspot/share/opto/phase.hpp line 125:
> 
>> 123:     f(   _t_temporaryTimer1,         "tempTimer1")               \
>> 124:     f(   _t_temporaryTimer2,         "tempTimer2")               \
>> 125:     f(   _t_testTimer1,              "testTimer1")               \
> 
> Would `_t_testPhase1` and `_t_testPhase2` be a better name?

okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970155311

From sgehwolf at openjdk.org  Tue Feb 25 17:14:10 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 25 Feb 2025 17:14:10 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <pK7gXk5Nv6_6EMQS-sqQprcMMz_v6y305aUNaal7EWA=.3a1033fe-867a-439d-9041-683be9e83019@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
 <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>
 <pK7gXk5Nv6_6EMQS-sqQprcMMz_v6y305aUNaal7EWA=.3a1033fe-867a-439d-9041-683be9e83019@github.com>
Message-ID: <IburxTbm543dAyzexBk6JLRSB98aV9Gi7yi38FsrKog=.2a2bced5-4319-4aff-9eb1-67ee4448c695@github.com>

On Tue, 25 Feb 2025 16:31:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 42:
>> 
>>> 40:  * When runs in a container, the method handles the case
>>> 41:  * when a process is moved between cgroups.
>>> 42:  */
>> 
>> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?
>
>> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?
> 
> Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means.

A high level description that mentions what the function does. The inline comments are not very self describing for anyone not having written the patch.

Example:

Sets the subsystem path for a controller. The common container case is
handled by XXX. When a process has been moved from a cgroup to another
the following happens:
 - A
 - B
 - C


I believe this is desperately needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970211567

From schernyshev at openjdk.org  Tue Feb 25 17:23:00 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 25 Feb 2025 17:23:00 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
 <o8a1PCfdqJfAVMLKqa4_fq2i77wInIKOVo-xT4h5Nwg=.0ba6a7b8-fb79-4bd1-a275-ef0fac0d9d23@github.com>
 <tJ3zjnmJ1lKiQR8c6dhE_kGUR9qr75rWZmvsnMh-_8w=.5a75cd5c-fd8d-4336-a0e6-7d98fe69c0ae@github.com>
Message-ID: <1dczYd447I2XbdYWyDWOceZH6YjiJIM7rmsM2l2kAMM=.ea796f48-3ac2-412f-badd-46e08942c9bd@github.com>

On Mon, 24 Feb 2025 23:33:01 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> `CgroupV1Controller::set_subsystem_path` needs high level comment update to describe the logic happening.
>> 
>> Testing:
>>>>And after the patch this would become this, right?
>>>>```
>>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>>>/sys/fs/cgroup/cpu,cpuacct/
>>>>```
>>>
>>>It depends on whether it was a subgroup in the initial path. If bad/2f57368b-0eda-4e52-64d8-af5c is the subgroup, the reduction will be
>>>
>>>```
>>>/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>>>/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c
>>>/sys/fs/cgroup/cpu,cpuacct/bad
>>>/sys/fs/cgroup/cpu,cpuacct/
>>>```
>> 
>> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.
>
>> The above case, doesn't seem to be reflected by any gtest test case (or others), please add those.
> 
> The subgroup path reduction is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` (it wouldn't be possible in gtests as it requires touching cgroup tree on a host system). It actually checks that the subgroup directory exists and skips non-existent directories, that is reflected in the test log below. The bottom line comes from `CgroupV1Controller::set_subsystem_path`.
> 
> ========== NEW TEST CASE:      Cgroup V1 subgroup memory limit: 100m
> [COMMAND]
> docker run --tty=true --rm --privileged --cgroupns=host --memory 200m jdk-internal:test-containers-docker-TestMemoryWithSubgroups-subgroup sh -c mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version
> [2025-02-24T22:33:28.049656218Z] Gathering output for process 23369
> [ELAPSED: 5385 ms]
> [STDERR]
> 
> [STDOUT]
> [0.002s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.003s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.004s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.004s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.
> 
> With additional logging added before line 77, this could be looking like
> 
> [STDOUT]
> [0.002s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.002s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.003s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
> [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
> [0.004s][trace][os,container] set_subsystem_path: skipped non existent directory: /cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test.
> [0.005s][trace][os,container] set_subsystem_path: cgroup v1 path reduced to: /test.
> 
> Before the fix, the current path adjustment scheme would produce the following order:
> 
> /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test
> /sys/fs/cgroup/memory/docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370
> /sys/fs/cgroup/memory/docker
> /sys/fs/cgroup/memory
> 
> Only the last path is valid in the conta...

> @sercher As far as I can see this is a fairly simple case which would be covered by a simpler patch. My comment was in regards to my comment [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865630320). Where you replied with [this answer](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436). I don't see where anything you've described in your answer is being tested, covering this new code:
> 
> https://github.com/openjdk/jdk/pull/21808/files#diff-8910f554ed4a7bc465e01679328b3e9bd64ceaa6c85f00f0c575670e748ebba9R63-R77

The code fragment you mentioned is executed under condition at line 62, that is, `_root` and `cgroup_path` are not equal. This happens exactly when a process PID is written to `cgroup.procs` file in the directory, belonging to a certain control group G, i.e. the process PID is moved to the control group G. Now that we have `_root` and `cgroup_path` non-equal, such as in my response [here](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436), i.e.


_root: /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c
cgroup_path: /system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c

the loop at lines 67-77 is determining the "subgroup" part of the above `cgroup_path` , producing the debug message at line 73. The above case is CloudFoundry specific, while in the default docker setup it will be

_root: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370
cgroup_path: /docker/cc32e455402a8c98d1df6a81c685a540e7e528e714c981b10845c31b64d8a370/test

In both cases it needs to be determined what (trailing) part of `cgroup_path` is an actual subgroup path, because this is how we find a directory that exists in the container. It's not known whether the subgroup path is

/bad/2f57368b-0eda-4e52-64d8-af5c

or

/garden/bad/2f57368b-0eda-4e52-64d8-af5c

and then the cgroup files path is either 

/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c

or

/sys/fs/cgroup/cpu,cpuacct/garden/bad/2f57368b-0eda-4e52-64d8-af5c

The docker case is not any different from the CF case. I therefore suggest [this](https://github.com/openjdk/jdk/pull/21808#discussion_r1865663436) case is covered by `TestMemoryWithSubgroups#testMemoryLimitSubgroupV1` as noted previously. Hope this helps.
> 
> That is, some sub-group without a match, but some with one.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2682721738

From cjplummer at openjdk.org  Tue Feb 25 21:03:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Feb 2025 21:03:54 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <tj1JwQqMvGC1TAXkI3bZiv1Hta-44RkpB1Nyo-blJWA=.af565952-2cdc-4df9-9037-4fe1db4d7a55@github.com>
 <o4bcb4Lknxh2Aei2NO3v6D2lLR6MujWgNmUqvH1HODM=.89c4acbf-0df0-4a06-bfa7-666c9b20c1d9@github.com>
 <SuiVlVsZaLW66gs8_oqbpJY03mCggoBTh1FcsdAom_I=.cd450641-0024-4c88-b402-ab0327ef54a2@github.com>
Message-ID: <F1iK5FJBnNn2irywrtbWqTLlm-l4ii4lpRiLUNl0hQY=.c4fa7715-95ba-49b2-b2fa-6b44ccf76285@github.com>

On Tue, 25 Feb 2025 09:14:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > I think you can optionally configure libjvm.so to be built for small size, not performance
> 
> Yes true for libjvm this is possible, it is the opt-size part of the minimal features set `JVM_FEATURES_minimal='compiler1 minimal opt-size serialgc'`

I wouldn't object to using -Os with the debug agent during opt-size builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2683284756

From schernyshev at openjdk.org  Wed Feb 26 00:52:41 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 26 Feb 2025 00:52:41 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  updated comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/3568c138..c9391dd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=14-15

  Stats: 42 lines in 1 file changed: 40 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Wed Feb 26 00:52:41 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 26 Feb 2025 00:52:41 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v15]
In-Reply-To: <IburxTbm543dAyzexBk6JLRSB98aV9Gi7yi38FsrKog=.2a2bced5-4319-4aff-9eb1-67ee4448c695@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <jPiUQFkkA_7ELb36w5iT9aI0SZyW67azvVcO_Y6kpmA=.43bd87a6-8e61-40a3-ac47-938ef992784d@github.com>
 <qv-d4q9Dgg1oGp0dQyvix_ss8iGon0XqKAa07hS_f2g=.e3318903-fd78-415e-8f87-75c755da92f1@github.com>
 <pK7gXk5Nv6_6EMQS-sqQprcMMz_v6y305aUNaal7EWA=.3a1033fe-867a-439d-9041-683be9e83019@github.com>
 <IburxTbm543dAyzexBk6JLRSB98aV9Gi7yi38FsrKog=.2a2bced5-4319-4aff-9eb1-67ee4448c695@github.com>
Message-ID: <Mds-9UWXepummBUMvAJQt88hAEbXpinJcVuIQXa5UyQ=.ab62dbbf-850c-45bb-9663-d4d67a909097@github.com>

On Tue, 25 Feb 2025 17:11:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> This needs to explain exactly what is happening when. The current comment isn't even remotely explaining in detail what it does. What does "... handles the case when a process is moved between cgroups" mean exactly?
>> 
>> Either it shall be a high level comment such as in your suggestion [here](https://github.com/openjdk/jdk/pull/21808#pullrequestreview-2620718790), or a deeper description in detail what happens where. Could you please be more specific on what kind of description is required and where? Please note the method has inline comments that are fairly self describing. In the meanwhile I'll try to add a description of what "a process is moved between cgroups" exactly means.
>
> A high level description that mentions what the function does. The inline comments are not very self describing for anyone not having written the patch.
> 
> Example:
> 
> Sets the subsystem path for a controller. The common container case is
> handled by XXX. When a process has been moved from a cgroup to another
> the following happens:
>  - A
>  - B
>  - C
> 
> 
> I believe this is desperately needed.

Please see the updated comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1970739677

From duke at openjdk.org  Wed Feb 26 01:36:58 2025
From: duke at openjdk.org (Dustin4444)
Date: Wed, 26 Feb 2025 01:36:58 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <vZw_vPmBI2DH_U4CkbHYnqqu2wCqCXBU7AtAYQAO6Do=.9e493748-bb46-4f69-81a7-0fb9de340d7c@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Marked as reviewed by Dustin4444 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2642819217

From syan at openjdk.org  Wed Feb 26 01:44:55 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Feb 2025 01:44:55 GMT
Subject: RFR: 8350545: Several sun/management/jdp tests fails
 java.net.SocketException
In-Reply-To: <RPEI8NzqCDQRpe60_KfVNtcI__dgpE7wYuP8XCQEk9Y=.6fc99ec4-82a7-4102-a0b1-dc45c6edb594@github.com>
References: <W6YRK1OCz5bYdl5z5ju2SzkNFt4lDNnAnMYQJApCAYw=.78276d1a-f154-43cb-aab0-c893bbd14209@github.com>
 <4aYtU0MSCFd-32URhOyyhwoq_dKUqY10eGiEzV6oDLM=.8e8fde62-b9c6-4510-bb8e-18de975daa4e@github.com>
 <pMHWaPeYaTFK7mdhcB3q0wg4OUOb-9ZYZgcKSN_4L6I=.aac29057-aded-42a7-8383-3e0cd3a02c78@github.com>
 <RPEI8NzqCDQRpe60_KfVNtcI__dgpE7wYuP8XCQEk9Y=.6fc99ec4-82a7-4102-a0b1-dc45c6edb594@github.com>
Message-ID: <wo2S-uQGqnCwXze_ku_NSnCNuPlPVo5iXNavnGkr9Pc=.355cc4a3-4faa-4c08-a572-2d97e063481c@github.com>

On Mon, 24 Feb 2025 09:58:47 GMT, SendaoYan <syan at openjdk.org> wrote:

>> The tested address:port is hard code to '224.0.23.178:7095' by file test/jdk/sun/management/jdp/ClientConnection.java. This address:port work normally on most machines, but cannot work on machine which can not connect to the internet directly.
>
> Seems that the exception from src/java.base/unix/native/libnio/ch/Net.c:679.
> I'm not familiar with jdp feature, Could you give me some advices how to make check is the test choosing the wrong interface or address.
> 
> The information test system which report test failure shows below:
> 
> 
>> ifconfig 
> enP2p129s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet 192.168.50.12  netmask 255.255.255.0  broadcast 192.168.50.255
>         inet6 fe80::1163:1d10:87a:6be4  prefixlen 64  scopeid 0x20<link>
>         ether a0:36:9f:53:17:f6  txqueuelen 1000  (Ethernet)
>         RX packets 22678271  bytes 28824464370 (26.8 GiB)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 9400465  bytes 7501254087 (6.9 GiB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
>         inet 127.0.0.1  netmask 255.0.0.0
>         inet6 ::1  prefixlen 128  scopeid 0x10<host>
>         loop  txqueuelen 1000  (Local Loopback)
>         RX packets 26485240  bytes 221859212049 (206.6 GiB)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 26485240  bytes 221859212049 (206.6 GiB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
>> ip r
> 192.168.50.0/24 dev enP2p129s0f1 proto kernel scope link src 192.168.50.12 metric 100 
> 
> 
> Command wget shows that it should connect to internet through a jumper machine(192.168.50.1:10991):
> 
> 
>> wget www.bing.com
> --2025-02-24 17:56:25--  http://www.bing.com/
> Connecting to 192.168.50.1:10991... connected.
> Proxy request sent, awaiting response... 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25--  http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ?index.html?
> 
> index.html                                        100%[=============================================================================================================>]  12.70K  --.-KB/s    in 0s      
> 
> 2025-02-24 17:56:25 (28.7 MB/s) - ?index.html? saved [13006/13006]

The test test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java will report "MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.UnknownHostException: example.com]" failure on the same machine. If I add argument " -Dhttp.proxyHost=192.168.50.1 -Dhttp.proxyPort=10991 -Dhttps.proxyHost=192.168.50.1 -Dhttps.proxyPort=10991 -DsocksProxyHost=192.168.50.1 -DsocksProxyPort=10991" to jtreg, this test will run passes. Maybe we need to investigate why the proxy do not work for sun/management/jdp tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23738#discussion_r1970775057

From asmehra at openjdk.org  Wed Feb 26 04:20:57 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 26 Feb 2025 04:20:57 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <ICOrVtN9o06dHWoN92q2Pi5aEsUdPYgZhMiBBYL9onk=.3d6d843b-f173-4512-b98a-6f54c0bb0c95@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
 <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
 <ICOrVtN9o06dHWoN92q2Pi5aEsUdPYgZhMiBBYL9onk=.3d6d843b-f173-4512-b98a-6f54c0bb0c95@github.com>
Message-ID: <AfMTXz_qIv9YtPNcDE8LPIIu0ulaa-bXLsXnkP6LAi4=.c1ed59e0-29d8-410a-a78e-6997b24d9fa2@github.com>

On Tue, 25 Feb 2025 16:13:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/compiler/compilationMemStatInternals.hpp line 160:
>> 
>>> 158:     void init(T v)        { start = cur = peak = v; }
>>> 159:     void update(T v)      { cur = v; if (v > peak) peak = v; }
>>> 160:     dT end_delta() const  { return (dT)cur - (dT)start; }
>> 
>> Should it be `return (dT)(cur - start); }`
>
> hmm, I like to avoid the inner overflow is cur < start (if the phase released more memory than it allocated)

right, I missed that.

>> src/hotspot/share/compiler/compilationMemStatInternals.hpp line 161:
>> 
>>> 159:     void update(T v)      { cur = v; if (v > peak) peak = v; }
>>> 160:     dT end_delta() const  { return (dT)cur - (dT)start; }
>>> 161:     size_t temporary_peak_size() const { return MIN2(peak - cur, peak - start); }
>> 
>> shouldn't it be `MAX2(peak - cur, peak - start)`? Why not just `peak - start`?
>
> We are only interested in a rise that rose significantly above **both** the start and end point of the measurements. 
> 
> E.g.:
> - if we have this: start = 0, end = 20MB, peak = 20MB, this is not a temporary peak and we already know that the end usage is 20MB.
> - if we have this: start = 20MB, end = 0, peak = 20MB, this is not a temporary peak either, because we already know the starting footprint was 20MB.
> - but if we have start = 0, end = 0, peak = 20MB, this is interesting since if we just print start and end we will miss the fact that in between those times we had temporarily allocated 20MB.

Thanks for the explanation. It would be great if some comment can be added, possibly along with some example like the one in the previous comment, to explain the meaning of `temporary_peak_size` and the corresponding calculation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970880396
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1970880439

From asmehra at openjdk.org  Wed Feb 26 04:29:54 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 26 Feb 2025 04:29:54 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v6]
In-Reply-To: <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
Message-ID: <fokR_X2PppYVLCZKnGAnapCL-5bY3NUkEqq3w7U75JA=.747e383f-6033-426b-ab52-fc8d2bc6ccfb@github.com>

On Tue, 25 Feb 2025 16:43:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - feedback ashu
>  - feedback roberto
>  - final-statistics-switch
>  - performance fix
>  - remove test code

Marked as reviewed by asmehra (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23530#pullrequestreview-2643027285

From asmehra at openjdk.org  Wed Feb 26 04:29:55 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 26 Feb 2025 04:29:55 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <5UAbfNQNxn--W_diVazFvldvScMGE59vVfpWJ4GUziA=.24361d75-77c9-418d-830e-797cac10f4b9@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
 <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
 <0wHGNSlwe7cWb7Plad2n8Swy8rayYTAf5IETuw9zl4U=.a4d6a129-aebc-4639-aaef-92ee6c4552c7@github.com>
 <NfX5WX4NU_kD7dQcZjpaN3z28TDcsg2OIJjXjpZv_-s=.34848957-da62-430c-ae40-a57f32f10cfb@github.com>
 <5UAbfNQNxn--W_diVazFvldvScMGE59vVfpWJ4GUziA=.24361d75-77c9-418d-830e-797cac10f4b9@github.com>
Message-ID: <NATEI7CElhsnunX283lEW_0yI2jZw3RdSTr6B4JZ8tw=.b61df5f9-1be6-430b-aa14-92ba6d7d073c@github.com>

On Tue, 25 Feb 2025 16:39:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> > @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
>>> > With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.
>>> 
>>> Great, thanks! Will re-run benchmarking and report results early next week.
>> 
>> Functional test results (Oracle tier1-5) still look good for the latest commit (dd7a06ad). I can confirm that the C2 speed regression on our linux-x64 machines is almost fully mitigated. The 2-3% regression on our macosx-aarch64 machines does not seem to be addressed by the latest changes though, but as I mentioned before I think it is in the acceptable range (and only affects one benchmark).
>
> @robcasloz, @ashu-mehra thanks a lot for your reviews. I incorporated most of them into the PR.

Changes look good to me. Thanks @tstuefe  for addressing the comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2683863222

From kbarrett at openjdk.org  Wed Feb 26 12:28:29 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 26 Feb 2025 12:28:29 GMT
Subject: RFR: 8350771: Fix -Wzero-as-null-pointer-constant warning in
 nsk/monitoring ThreadController utilitiy
Message-ID: <8XY_mw7_i4bOOUHUB2QUPWIddYAXGNFl5gH92SfIEVA=.6c943b2e-8a7f-4b3e-bcce-33010be89f05@github.com>

Please review this trivial change to remove a use of literal zero as a null
pointer constant in an nsk test utility.

Testing: mach5 tier1
Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
verify the warnings associated with this code were removed.

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

Commit messages:
 - fix nsk/monitoring ThreadController.cpp

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

PR: https://git.openjdk.org/jdk/pull/23800

From rcastanedalo at openjdk.org  Wed Feb 26 12:36:10 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 26 Feb 2025 12:36:10 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v6]
In-Reply-To: <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
Message-ID: <aDVfrInJddv5fFYbNkGQc__nSsw0jiQZk4fbkEC4BmM=.aa5caef9-756c-43e5-aa86-3330185d2f00@github.com>

On Tue, 25 Feb 2025 16:43:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - feedback ashu
>  - feedback roberto
>  - final-statistics-switch
>  - performance fix
>  - remove test code

src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 306:

> 304:   if (_comp_type == compiler_c2) {
> 305:     // Update C2 node count
> 306:     // Careful, Compile::current() may be NULL in a short time window when Compile itself

The recently added `sources/TestNoNULL.java` test fails due to this occurrence of `NULL`.
Suggestion:

    // Careful, Compile::current() may be null in a short time window when Compile itself

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1971506973

From rcastanedalo at openjdk.org  Wed Feb 26 13:03:55 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 26 Feb 2025 13:03:55 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <NfX5WX4NU_kD7dQcZjpaN3z28TDcsg2OIJjXjpZv_-s=.34848957-da62-430c-ae40-a57f32f10cfb@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
 <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
 <0wHGNSlwe7cWb7Plad2n8Swy8rayYTAf5IETuw9zl4U=.a4d6a129-aebc-4639-aaef-92ee6c4552c7@github.com>
 <NfX5WX4NU_kD7dQcZjpaN3z28TDcsg2OIJjXjpZv_-s=.34848957-da62-430c-ae40-a57f32f10cfb@github.com>
Message-ID: <P0R02Qxn6MxYrUWAP-sHxzIQUOXXMLmrOFbpPmkmWDQ=.2486a05d-a9f9-44b2-ab7e-0d60e15fcf3b@github.com>

On Mon, 24 Feb 2025 08:56:51 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>>> @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
>>> 
>>> With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.
>> 
>> Great, thanks! Will re-run benchmarking and report results early next week.
>
>> > @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
>> > With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.
>> 
>> Great, thanks! Will re-run benchmarking and report results early next week.
> 
> Functional test results (Oracle tier1-5) still look good for the latest commit (dd7a06ad). I can confirm that the C2 speed regression on our linux-x64 machines is almost fully mitigated. The 2-3% regression on our macosx-aarch64 machines does not seem to be addressed by the latest changes though, but as I mentioned before I think it is in the acceptable range (and only affects one benchmark).

> @robcasloz, @ashu-mehra thanks a lot for your reviews. I incorporated most of them into the PR.

Thanks, Thomas! I see that the changes suggested in https://github.com/openjdk/jdk/commit/d501bd8a674229904358fb168a9c347004efeea3 are not incorporated, is it because you find them out of the scope of this PR? I would argue that at least tagging `Compile::_Compile_types` with `tag_type` is relevant and in line with the other changes included in this PR, e.g. [this one](https://github.com/openjdk/jdk/pull/23530/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R443).

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2684893025

From mbaesken at openjdk.org  Wed Feb 26 13:27:53 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Feb 2025 13:27:53 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>
Message-ID: <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>

On Tue, 25 Feb 2025 15:09:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>  Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead.

Hi @magicus  I can collect some info from our builds (gcc13, xlc17, Xcode15, VS2022).
Should we place the wiki here ?  https://wiki.openjdk.org/display/Build  
Seems I can edit the pages there but not create a new one , can you !?

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2684951886

From stuefe at openjdk.org  Wed Feb 26 15:30:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Feb 2025 15:30:57 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <P0R02Qxn6MxYrUWAP-sHxzIQUOXXMLmrOFbpPmkmWDQ=.2486a05d-a9f9-44b2-ab7e-0d60e15fcf3b@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
 <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
 <0wHGNSlwe7cWb7Plad2n8Swy8rayYTAf5IETuw9zl4U=.a4d6a129-aebc-4639-aaef-92ee6c4552c7@github.com>
 <NfX5WX4NU_kD7dQcZjpaN3z28TDcsg2OIJjXjpZv_-s=.34848957-da62-430c-ae40-a57f32f10cfb@github.com>
 <P0R02Qxn6MxYrUWAP-sHxzIQUOXXMLmrOFbpPmkmWDQ=.2486a05d-a9f9-44b2-ab7e-0d60e15fcf3b@github.com>
Message-ID: <_2PWpcAQigB_MY6KkK1avnTz5vdr5qmIICXP5M_jWN0=.48821f49-c7c4-4d45-8758-edc652837119@github.com>

On Wed, 26 Feb 2025 13:00:51 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>>> > @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
>>> > With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.
>>> 
>>> Great, thanks! Will re-run benchmarking and report results early next week.
>> 
>> Functional test results (Oracle tier1-5) still look good for the latest commit (dd7a06ad). I can confirm that the C2 speed regression on our linux-x64 machines is almost fully mitigated. The 2-3% regression on our macosx-aarch64 machines does not seem to be addressed by the latest changes though, but as I mentioned before I think it is in the acceptable range (and only affects one benchmark).
>
>> @robcasloz, @ashu-mehra thanks a lot for your reviews. I incorporated most of them into the PR.
> 
> Thanks, Thomas! I see that the changes suggested in https://github.com/openjdk/jdk/commit/d501bd8a674229904358fb168a9c347004efeea3 are not incorporated, is it because you find them out of the scope of this PR? I would argue that at least tagging `Compile::_Compile_types` with `tag_type` is relevant and in line with the other changes included in this PR, e.g. [this one](https://github.com/openjdk/jdk/pull/23530/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R443).

> > @robcasloz, @ashu-mehra thanks a lot for your reviews. I incorporated most of them into the PR.
> 
> Thanks, Thomas! I see that the changes suggested in [d501bd8](https://github.com/openjdk/jdk/commit/d501bd8a674229904358fb168a9c347004efeea3) are not incorporated, is it because you find them out of the scope of this PR? I would argue that at least tagging `Compile::_Compile_types` with `tag_type` is relevant and in line with the other changes included in this PR, e.g. [this one](https://github.com/openjdk/jdk/pull/23530/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R443).

Sorry, this was an oversight. Will do this, no reason not to.

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2685412110

From rcastanedalo at openjdk.org  Thu Feb 27 10:15:07 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 27 Feb 2025 10:15:07 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v6]
In-Reply-To: <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
Message-ID: <q8f16tTi4UhRGTjPDrYDBpqKfiSxqDvPyxT5XdLN_qg=.373a7164-f2f3-48d5-874a-765e1ea6fba3@github.com>

On Tue, 25 Feb 2025 16:43:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - feedback ashu
>  - feedback roberto
>  - final-statistics-switch
>  - performance fix
>  - remove test code

Changes requested by rcastanedalo (Reviewer).

src/hotspot/share/compiler/compilationMemStatInternals.hpp line 243:

> 241:   int retrieve_live_node_count() const;
> 242: 
> 243:   DEBUG_ONLY(void verify() const;)

Unused. I suggest to either call this function from some appropriate point (in debug mode only) or just remove it.

src/hotspot/share/runtime/globals.hpp line 1402:

> 1400:           "Print metaspace statistics upon VM exit.")                       \
> 1401:                                                                             \
> 1402:   product(bool, PrintCompilerMemoryStatisticsAtExit, false, DIAGNOSTIC,     \

Would it be possible to add a test for this new flag, perhaps by extending the existing test logic in `CompileCommandPrintMemStat`?

src/hotspot/share/utilities/globalDefinitions.hpp line 371:

> 369: 
> 370: #define PROPERFMT             "%zu%s"
> 371: #define PROPERFMT_W(width)    "%" #width "zu%s"

Unused, please remove.

src/hotspot/share/utilities/ostream.cpp line 225:

> 223:   while (count > 0) {
> 224:     int nw = (count > 8) ? 8 : count;
> 225:     this->write(tmp, nw);

Are these changes essential for the rest of the changeset? If not, I would suggest to leave them to a separate RFE, for simplicity.

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

PR Review: https://git.openjdk.org/jdk/pull/23530#pullrequestreview-2647251550
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1973265196
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1973277216
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1973266713
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1973272906

From kevinw at openjdk.org  Thu Feb 27 16:48:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Feb 2025 16:48:13 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <w7EwNH5soJlrUBiMZGGF7pFQ98SMY_NxP-jlSPf1K-E=.9f33d393-b78b-44e4-b7fa-d47b054638d3@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

This change is implicated in the regression JDK-8350820 in the Windows management/cpu usage functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688528615

From jwaters at openjdk.org  Thu Feb 27 16:57:05 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Feb 2025 16:57:05 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <Ew21DejHpQXKCoI4QoT9qZcPpTJbhVJmxyS1-FURJTE=.719d0640-0fa5-4fd0-a7e8-19e9e31f66bf@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

That's not good. I cannot view JDK-8350820 however

Is the issue in HotSpot, or another component?

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

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688552358
PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688554610

From kevinw at openjdk.org  Thu Feb 27 17:00:25 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Feb 2025 17:00:25 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <Xfa55gXs5qXMaifp0YRrFKLZzAdldbbUDa4yUeDdtps=.1457e6a0-ef90-408a-bca4-212b91e393df@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Issue recently logged, was marked confidential, will update...

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

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688560132

From coleenp at openjdk.org  Thu Feb 27 17:37:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Feb 2025 17:37:22 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v2]
In-Reply-To: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
Message-ID: <OeV4bcJ6virNG9B-WbJ-BYynrhaH_JGBVJHkxl420cs=.9ff4b4a6-ece5-40b0-ab7b-2fc5baff581c@github.com>

> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Forgot to remove some includes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23782/files
  - new: https://git.openjdk.org/jdk/pull/23782/files/8435f98b..0a86d6fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=00-01

  Stats: 24 lines in 1 file changed: 0 ins; 24 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23782/head:pull/23782

PR: https://git.openjdk.org/jdk/pull/23782

From coleenp at openjdk.org  Thu Feb 27 17:28:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Feb 2025 17:28:42 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with hotspot
 ciReplay support
Message-ID: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>

This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
Tested with tier1-4.

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

Commit messages:
 - Remove unused declarations in vmStructs.
 - Remove doc
 - Remove the test.
 - more unused code.
 - Remove SA compiler replay facility that nobody uses.

Changes: https://git.openjdk.org/jdk/pull/23782/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315488
  Stats: 5529 lines in 69 files changed: 1 ins; 5521 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23782/head:pull/23782

PR: https://git.openjdk.org/jdk/pull/23782

From coleenp at openjdk.org  Thu Feb 27 17:59:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Feb 2025 17:59:42 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v3]
In-Reply-To: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
Message-ID: <b8KaLeK9a-jTvXRZpoPVayTSKVyOpPWmEOpn3g81KLk=.89e47959-3056-4aea-b570-ebe2650ea035@github.com>

> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove friends.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23782/files
  - new: https://git.openjdk.org/jdk/pull/23782/files/0a86d6fe..fb673eb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=01-02

  Stats: 31 lines in 8 files changed: 0 ins; 26 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23782/head:pull/23782

PR: https://git.openjdk.org/jdk/pull/23782

From coleenp at openjdk.org  Thu Feb 27 18:06:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Feb 2025 18:06:19 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v4]
In-Reply-To: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
Message-ID: <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>

> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  More friends.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23782/files
  - new: https://git.openjdk.org/jdk/pull/23782/files/fb673eb4..fca987a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=02-03

  Stats: 9 lines in 4 files changed: 0 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23782/head:pull/23782

PR: https://git.openjdk.org/jdk/pull/23782

From jiangli at openjdk.org  Thu Feb 27 21:09:59 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Feb 2025 21:09:59 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK
In-Reply-To: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
Message-ID: <AemE3AQRhrYVlLMRpCQS8uRnAbINNLL4Kp6XoRItzgc=.408dac75-3fc2-4f57-9acb-b4c4533a1dcc@github.com>

On Sat, 22 Feb 2025 03:31:53 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in following tests to not check for shared libraries when running on static JDK:
> 
> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java

@tstuefe Could you please help review these test changes? Looking at the file history, I see you added the `SystemDumpMapTest.java` and `SystemMapTest.java`. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23734#issuecomment-2689112739

From lmesnik at openjdk.org  Fri Feb 28 00:09:31 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 28 Feb 2025 00:09:31 GMT
Subject: RFR: 8350820: The OperatingSystemMXBean cpuLoad() methods return -1.0
 in Windows
Message-ID: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>

The problem was introduced by the 
https://bugs.openjdk.org/browse/JDK-8336289

This pr just revert changes in src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c

The test fix is going to be pushed separately (for easy backporting) bug https://bugs.openjdk.org/browse/JDK-8350818

I verified that updated tests failed (bean returns -1.0) and now passed, also run tier1-5 testing.

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

Commit messages:
 - 8350820

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

PR: https://git.openjdk.org/jdk/pull/23832

From lmesnik at openjdk.org  Fri Feb 28 00:10:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 28 Feb 2025 00:10:42 GMT
Subject: RFR: 8350818: Improve OperatingSystemMXBean cpu load tests to don't
 accept -1.0 by default
Message-ID: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>

The cpuLoad tests were updated to fail if -1.0 returns to catch bugs like https://bugs.openjdk.org/browse/JDK-8350820

The -1.0 means that JDK can't obtain cpu load. It shouldn't be returned.
If this functionality doesn't work on certain configurations then they should be excluded.

The fix should be pushed after https://bugs.openjdk.org/browse/JDK-8350820
I filed separate PR to backport fix easier.
Also, I haven't changed indentation and didn't change getSystemCpuLoad to getCpuLoad. They return same. 
Might be it would be better. just to rename the whole test later.

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

Commit messages:
 - testfix

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

PR: https://git.openjdk.org/jdk/pull/23833

From cjplummer at openjdk.org  Fri Feb 28 01:19:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Feb 2025 01:19:58 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v4]
In-Reply-To: <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
Message-ID: <U-DHUSP6eOSi6B1N2JaEO6HGfFO1yVZe4kANq3OYK0g=.3280ef6a-afac-4973-8c66-31e1736c0508@github.com>

On Thu, 27 Feb 2025 18:06:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More friends.

src/jdk.hotspot.agent/doc/index.html line 43:

> 41: </p>
> 42: 
> 43: <h3>Compilation Replay</h3>

clhsdb.html also needs to be updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23782#discussion_r1974577106

From jiangli at openjdk.org  Fri Feb 28 01:45:34 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 28 Feb 2025 01:45:34 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
Message-ID: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>

Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.

Tested on static JDK locally
GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

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

Commit messages:
 - Remove unused `nVMs` variable.
 - Remove JNI_GetCreatedJavaVMs call.

Changes: https://git.openjdk.org/jdk/pull/23835/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23835&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350903
  Stats: 10 lines in 2 files changed: 0 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23835/head:pull/23835

PR: https://git.openjdk.org/jdk/pull/23835

From kvn at openjdk.org  Fri Feb 28 02:42:57 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 28 Feb 2025 02:42:57 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v4]
In-Reply-To: <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
Message-ID: <y0DUpLB2QbUjpYot5FiOwYFPWBrBczDcD-MdR3MlQJQ=.14071eab-88ed-40ea-9e09-ad81c436524c@github.com>

On Thu, 27 Feb 2025 18:06:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More friends.

src/hotspot/share/runtime/vmStructs.cpp line 706:

> 704:   volatile_nonstatic_field(MonitorList,        _head,                                         ObjectMonitor*)                        \
> 705:                                                                                                                                      \
> 706:   unchecked_c2_static_field(Matcher,           _regEncode,                          sizeof(Matcher::_regEncode)) /* NOTE: no type */ \

I don't see usage in SA of `VMReg::regEncode()` which access this field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23782#discussion_r1974673849

From cjplummer at openjdk.org  Fri Feb 28 04:15:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Feb 2025 04:15:58 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v4]
In-Reply-To: <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
Message-ID: <JR6UQNTjsp6lS6ZLKnnzYFTm-tc69hT255VJlPakQcc=.1becb950-0cac-41bb-b2d3-00f8895688d0@github.com>

On Thu, 27 Feb 2025 18:06:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More friends.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/CompilerThread.java line 48:

> 46:   private static synchronized void initialize(TypeDataBase db) throws WrongTypeException {
> 47:     Type type      = db.lookupType("CompilerThread");
> 48: 

Line 47 above is no longer needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23782#discussion_r1974736433

From duke at openjdk.org  Fri Feb 28 07:25:52 2025
From: duke at openjdk.org (mScott224)
Date: Fri, 28 Feb 2025 07:25:52 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <xNDfNtxTIJEpH26bCh0qKskX3T5mwuzQ7nPUaIXyRL4=.faeac4f1-49d7-4e34-a8ca-8db44f84d30f@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

Marked as reviewed by mScott224 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23835#pullrequestreview-2649953250

From duke at openjdk.org  Fri Feb 28 07:30:53 2025
From: duke at openjdk.org (mScott224)
Date: Fri, 28 Feb 2025 07:30:53 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <rCUWN8zzq8Ktyu1LGumKox3U51_f-JETLA-2bdcUhuY=.51cbd0a7-da5e-4cc7-b2f2-bd9c1c867b47@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

Marked as reviewed by mScott224 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23835#pullrequestreview-2649962832

From kevinw at openjdk.org  Fri Feb 28 09:39:52 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Feb 2025 09:39:52 GMT
Subject: RFR: 8350820: The OperatingSystemMXBean cpuLoad() methods return
 -1.0 in Windows
In-Reply-To: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>
References: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>
Message-ID: <WV4IhEjvgTQxFJkNSnTH7K1_Vht-v_Nfonu00hgBCeE=.34610560-5c86-4845-9da0-cf65b012cd6c@github.com>

On Thu, 27 Feb 2025 23:23:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem was introduced by the 
> https://bugs.openjdk.org/browse/JDK-8336289
> 
> This pr just revert changes in src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c
> 
> The test fix is going to be pushed separately (for easy backporting) bug https://bugs.openjdk.org/browse/JDK-8350818
> 
> I verified that updated tests failed (bean returns -1.0) and now passed, also run tier1-5 testing.

Yes this looks good.  I also built and verified in JConsole we get good data from the cpu usage monitors.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23832#pullrequestreview-2650240621

From kevinw at openjdk.org  Fri Feb 28 09:52:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Feb 2025 09:52:01 GMT
Subject: RFR: 8350818: Improve OperatingSystemMXBean cpu load tests to
 don't accept -1.0 by default
In-Reply-To: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
References: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
Message-ID: <UsF1lfUyOnKi-8b95UBa-DbyhvnXziPz5w87ekXMZh0=.130522fa-ad78-4ef7-ad30-da35938ac21f@github.com>

On Fri, 28 Feb 2025 00:05:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The cpuLoad tests were updated to fail if -1.0 returns to catch bugs like https://bugs.openjdk.org/browse/JDK-8350820
> 
> The -1.0 means that JDK can't obtain cpu load. It shouldn't be returned.
> If this functionality doesn't work on certain configurations then they should be excluded.
> 
> The fix should be pushed after https://bugs.openjdk.org/browse/JDK-8350820
> I filed separate PR to backport fix easier.
> Also, I haven't changed indentation and didn't change getSystemCpuLoad to getCpuLoad. They return same. 
> Might be it would be better. just to rename the whole test later.

Looks good, yes ignoring the -1 seems like a historical issue, maybe we had platforms or builds where -1 was expected.  Yes we can exclude the test if we find such configs.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23833#pullrequestreview-2650269373

From ihse at openjdk.org  Fri Feb 28 10:44:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 28 Feb 2025 10:44:58 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>
 <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>
Message-ID: <n-tT5evU9GasQDZUxXYASLUIW_VdSJKwtebQ90qY-h8=.1e7330df-8555-4372-b5d0-ea1ba4159085@github.com>

On Wed, 26 Feb 2025 13:24:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I think it might be worth trying to take a more structured approach to the optimizations used. Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead. Ideally, we would also have some kind of microbenchmark associated with each library that could say anything about the performance of the library, but that is probably not realistic in most cases. But I guess that people familiar with the library can make some educated guess about the performance sensitivity of the libraries, and what would stress them.
>> 
>> Furthermore, I think we can definitely consider changes in the build system to support some of the requests that have arisen here, like allowing JDK libraries (apart from Hotspot) to allow LTO, or to have a way to override optimization levels for JDK libraries from the configure command line, similar to the JVM feature `opt-size`.
>> 
>> I am also open to reconsidering the entire idea of "optimization levels" the way it is currently implemented. Developers tend to think in terms of `-O2`, and our named optimization levels just inserts an extra layer of uncertainty ("what does `HIGHEST` really mean?). A problem is of course that different compilers have different ways of expressing optimization (most clearly how the Microsoft VS compiler differs from gcc/clang), but then again, maybe that just means that we should express this as:
>> 
>> 
>>    OPT_gcc_clang := -O1, \
>>    OPT_microsoft := -O2. \
>> 
>> 
>> since it is not obvious that there really is a good way to package different optimization flags for different compilers that make sense for all libraries. Our current code assumes this is the case, but this does not necessarily have to be true.
>
>>  Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead.
> 
> Hi @magicus  I can collect some info from our builds (gcc13, xlc17, Xcode15, VS2022).
> Should we place the wiki here ?  https://wiki.openjdk.org/display/Build  
> Seems I can edit the pages there but not create a new one , can you !?

@MBaesken I don't know why you could not add new pages (everyone in the Build Group should be able to do that). The UI is a bit strange, I usually create a new page by creating a tentative link from an existing one.

Anyway, I created https://wiki.openjdk.org/display/Build/Native+library+optimization+level+research. It's all yours!

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2690315947

From mbaesken at openjdk.org  Fri Feb 28 11:11:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Feb 2025 11:11:54 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
 <xp7mCmpM-Rp3GhKPdWPBHDgqLICczejbxo45B0_teDs=.7e52be23-a301-4039-8ecc-0530eaaeb9f8@github.com>
 <osxBhHWyA4ub3k-nV5Yma5gxbN51GjA4leJ-WQ0n81M=.23ab9d24-4e80-4d65-ace4-e4739dfa2955@github.com>
Message-ID: <RaH0aEew1LaH3oBPaP9EGf2BLN6BFvdCDKI6tzyLDJc=.fa20ae4c-1b09-491e-9aa7-d0c575026a7d@github.com>

On Wed, 26 Feb 2025 13:24:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I think it might be worth trying to take a more structured approach to the optimizations used. Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead. Ideally, we would also have some kind of microbenchmark associated with each library that could say anything about the performance of the library, but that is probably not realistic in most cases. But I guess that people familiar with the library can make some educated guess about the performance sensitivity of the libraries, and what would stress them.
>> 
>> Furthermore, I think we can definitely consider changes in the build system to support some of the requests that have arisen here, like allowing JDK libraries (apart from Hotspot) to allow LTO, or to have a way to override optimization levels for JDK libraries from the configure command line, similar to the JVM feature `opt-size`.
>> 
>> I am also open to reconsidering the entire idea of "optimization levels" the way it is currently implemented. Developers tend to think in terms of `-O2`, and our named optimization levels just inserts an extra layer of uncertainty ("what does `HIGHEST` really mean?). A problem is of course that different compilers have different ways of expressing optimization (most clearly how the Microsoft VS compiler differs from gcc/clang), but then again, maybe that just means that we should express this as:
>> 
>> 
>>    OPT_gcc_clang := -O1, \
>>    OPT_microsoft := -O2. \
>> 
>> 
>> since it is not obvious that there really is a good way to package different optimization flags for different compilers that make sense for all libraries. Our current code assumes this is the case, but this does not necessarily have to be true.
>
>>  Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead.
> 
> Hi @magicus  I can collect some info from our builds (gcc13, xlc17, Xcode15, VS2022).
> Should we place the wiki here ?  https://wiki.openjdk.org/display/Build  
> Seems I can edit the pages there but not create a new one , can you !?

> @MBaesken I don't know why you could not add new pages (everyone in the Build Group should be able to do that). The UI is a bit strange, I usually create a new page by creating a tentative link from an existing one.
> 
> Anyway, I created https://wiki.openjdk.org/display/Build/Native+library+optimization+level+research. It's all yours!

Thanks ! I'll most likely have some time next week to collect and add some info from our build envs we use at SAP.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2690369940

From kevinw at openjdk.org  Fri Feb 28 11:18:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Feb 2025 11:18:08 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <i_NSaCTA6BLRKBO6QXgjfBijY8RacgjFXR8U7OtcRLE=.c6b2bda7-afa7-4187-800f-e0cd4184ae36@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Quick fix is PR https://github.com/openjdk/jdk/pull/23832 taking care of it in JDK 25, and there should be a backport to JDK 24 first update.  I will come back with a further update in JDK-8350939 to reinstate snprintf.

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

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2690383444

From jwaters at openjdk.org  Fri Feb 28 12:05:52 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 28 Feb 2025 12:05:52 GMT
Subject: RFR: 8350820: The OperatingSystemMXBean cpuLoad() methods return
 -1.0 in Windows
In-Reply-To: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>
References: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>
Message-ID: <mhkQk8YzI5NCfmceu9p2_OUrVk6RDy8g-_0J-emoX6I=.f0ff98b0-296f-4117-a227-1df611ed4c1d@github.com>

On Thu, 27 Feb 2025 23:23:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem was introduced by the 
> https://bugs.openjdk.org/browse/JDK-8336289
> 
> This pr just revert changes in src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c
> 
> The test fix is going to be pushed separately (for easy backporting) bug https://bugs.openjdk.org/browse/JDK-8350818
> 
> I verified that updated tests failed (bean returns -1.0) and now passed, also run tier1-5 testing.

Hopefully the standard snprintf can be reinstated in a fix quickly after this one

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23832#pullrequestreview-2650552996

From mbaesken at openjdk.org  Fri Feb 28 12:23:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Feb 2025 12:23:59 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
Message-ID: <Up2nvImQ0ygo9YKtNTpD1b4YtZFBmvt1d59nmky-ImI=.c7d8b52e-be3c-4533-9435-d3148a26947a@github.com>

On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.

Guess this must be 2025 now ? Same for other files ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975321465

From mbaesken at openjdk.org  Fri Feb 28 12:30:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Feb 2025 12:30:13 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
Message-ID: <IwVJeqTk0HxHxFi4B64nemBTTG0Tq6gDsMA6CmMDMAU=.b28d7564-3af4-44f0-957b-a998cb0f5540@github.com>

On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

test/jdk/jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java line 69:

> 67:     /*
> 68:      * Less common cases: Containers
> 69:      */

Not really sure why this comment was added, is it refering to 'container mode'  mentioned in the comment above in another file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975330669

From coleenp at openjdk.org  Fri Feb 28 15:49:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 15:49:20 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v5]
In-Reply-To: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
Message-ID: <La3v4MB_Avb5yhbnU3F-R_7X-t8VQ0iK48Tmo8LpR2Q=.b1d19746-28c2-4633-93dd-e24ab2b896bf@github.com>

> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Review comments and use COMPILER2 preprocessing macro instead of the presence of Matcher.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23782/files
  - new: https://git.openjdk.org/jdk/pull/23782/files/fca987a4..2d9ab884

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=03-04

  Stats: 50 lines in 6 files changed: 1 ins; 44 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23782/head:pull/23782

PR: https://git.openjdk.org/jdk/pull/23782

From coleenp at openjdk.org  Fri Feb 28 15:59:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 15:59:09 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v6]
In-Reply-To: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
Message-ID: <Uiy5xs3mlmRfYSSCZ2WyB1n2cDklyO4G6YHX3Sgbb7E=.835cde4f-1126-4b99-bc3f-027ffdb42223@github.com>

> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove VM_STRUCTS macro arguments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23782/files
  - new: https://git.openjdk.org/jdk/pull/23782/files/2d9ab884..aa80d2c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=04-05

  Stats: 382 lines in 26 files changed: 1 ins; 218 del; 163 mod
  Patch: https://git.openjdk.org/jdk/pull/23782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23782/head:pull/23782

PR: https://git.openjdk.org/jdk/pull/23782

From coleenp at openjdk.org  Fri Feb 28 15:59:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 15:59:09 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v4]
In-Reply-To: <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
Message-ID: <Pc791xl3nL1r7hpnekRXJdmgq11YKCD4RntG0Opi7Kc=.4d2a0077-b9ec-439e-bd8a-a728d25d38fe@github.com>

On Thu, 27 Feb 2025 18:06:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More friends.

Thanks for looking at the change Chris and Vladimir.

With this change, we can further remove these VM_STRUCTS macros like declare_c1_type, declare_c1_toplevel_type, etc.  It makes for a bigger change, but only more lines and more tedious.

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

PR Review: https://git.openjdk.org/jdk/pull/23782#pullrequestreview-2651124547

From coleenp at openjdk.org  Fri Feb 28 15:59:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 15:59:10 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v6]
In-Reply-To: <U-DHUSP6eOSi6B1N2JaEO6HGfFO1yVZe4kANq3OYK0g=.3280ef6a-afac-4973-8c66-31e1736c0508@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
 <U-DHUSP6eOSi6B1N2JaEO6HGfFO1yVZe4kANq3OYK0g=.3280ef6a-afac-4973-8c66-31e1736c0508@github.com>
Message-ID: <9r7BTy43ljeNbk2n7D320P1DTJNMVD7hWfTfy3Pnx5Q=.c3b42603-6ea8-4d6b-a026-76caf7280889@github.com>

On Fri, 28 Feb 2025 01:01:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove VM_STRUCTS macro arguments.
>
> src/jdk.hotspot.agent/doc/index.html line 43:
> 
>> 41: </p>
>> 42: 
>> 43: <h3>Compilation Replay</h3>
> 
> clhsdb.html also needs to be updated.

Fixed.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/CompilerThread.java line 48:
> 
>> 46:   private static synchronized void initialize(TypeDataBase db) throws WrongTypeException {
>> 47:     Type type      = db.lookupType("CompilerThread");
>> 48: 
> 
> Line 47 above is no longer needed.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23782#discussion_r1975626044
PR Review Comment: https://git.openjdk.org/jdk/pull/23782#discussion_r1975630237

From coleenp at openjdk.org  Fri Feb 28 15:59:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 15:59:09 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v4]
In-Reply-To: <y0DUpLB2QbUjpYot5FiOwYFPWBrBczDcD-MdR3MlQJQ=.14071eab-88ed-40ea-9e09-ad81c436524c@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <ykI6nVcQItjSZKAuLZj5g8aTrS3x5Aj_J_0zjWEeyS8=.93c7fba7-2f0f-489a-91a0-521c5465218c@github.com>
 <y0DUpLB2QbUjpYot5FiOwYFPWBrBczDcD-MdR3MlQJQ=.14071eab-88ed-40ea-9e09-ad81c436524c@github.com>
Message-ID: <AnOFEQg7l9Kk9cAWqO-KKwyFgmggiRuSN0Ww3Z_kZCA=.c92f4b00-acdb-45ab-b073-156bcf1eb591@github.com>

On Fri, 28 Feb 2025 02:40:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More friends.
>
> src/hotspot/share/runtime/vmStructs.cpp line 706:
> 
>> 704:   volatile_nonstatic_field(MonitorList,        _head,                                         ObjectMonitor*)                        \
>> 705:                                                                                                                                      \
>> 706:   unchecked_c2_static_field(Matcher,           _regEncode,                          sizeof(Matcher::_regEncode)) /* NOTE: no type */ \
> 
> I don't see usage in SA of `VMReg::regEncode()` which access this field.

This code isn't used but I thought it was somehow needed for stack dumping in one of the Xcomp/SA tests.  But it was really using the presence of the Matcher type to see if isServerCompiler().  So I added the COMPILER2 preprocessor macro and use that instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23782#discussion_r1975629323

From coleenp at openjdk.org  Fri Feb 28 16:03:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 16:03:00 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v6]
In-Reply-To: <Uiy5xs3mlmRfYSSCZ2WyB1n2cDklyO4G6YHX3Sgbb7E=.835cde4f-1126-4b99-bc3f-027ffdb42223@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <Uiy5xs3mlmRfYSSCZ2WyB1n2cDklyO4G6YHX3Sgbb7E=.835cde4f-1126-4b99-bc3f-027ffdb42223@github.com>
Message-ID: <lPLjHBfNHKKmHFnV_o-DNk80QPJFo0GB-OXZEJxUOTQ=.ab9507b1-8272-4715-b09a-212910bec710@github.com>

On Fri, 28 Feb 2025 15:59:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove VM_STRUCTS macro arguments.

The os_cpu VM_STRUCTS, VM_TYPES, etc have no declarations and should be removed, but I think I should stop here.

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

PR Review: https://git.openjdk.org/jdk/pull/23782#pullrequestreview-2651165490

From kvn at openjdk.org  Fri Feb 28 16:41:11 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 28 Feb 2025 16:41:11 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v6]
In-Reply-To: <lPLjHBfNHKKmHFnV_o-DNk80QPJFo0GB-OXZEJxUOTQ=.ab9507b1-8272-4715-b09a-212910bec710@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <Uiy5xs3mlmRfYSSCZ2WyB1n2cDklyO4G6YHX3Sgbb7E=.835cde4f-1126-4b99-bc3f-027ffdb42223@github.com>
 <lPLjHBfNHKKmHFnV_o-DNk80QPJFo0GB-OXZEJxUOTQ=.ab9507b1-8272-4715-b09a-212910bec710@github.com>
Message-ID: <l4Fgsxj9PPtrUFWXSuCh8RIXJNb9mCyq2EOZWKC7ByQ=.94c15fec-6dd1-45a0-b297-abfbf6bc0a72@github.com>

On Fri, 28 Feb 2025 16:00:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The os_cpu VM_STRUCTS, VM_TYPES, etc have no declarations and should be removed, but I think I should stop here.

File an other "starter" RFE

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

PR Comment: https://git.openjdk.org/jdk/pull/23782#issuecomment-2691088168

From kvn at openjdk.org  Fri Feb 28 16:47:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 28 Feb 2025 16:47:59 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v6]
In-Reply-To: <Uiy5xs3mlmRfYSSCZ2WyB1n2cDklyO4G6YHX3Sgbb7E=.835cde4f-1126-4b99-bc3f-027ffdb42223@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <Uiy5xs3mlmRfYSSCZ2WyB1n2cDklyO4G6YHX3Sgbb7E=.835cde4f-1126-4b99-bc3f-027ffdb42223@github.com>
Message-ID: <ONsgmoq7-1oHQWT7En3VEr9Ybz5bpIKp7AKWHEJFDJ4=.a3839d2c-0692-4f33-b45f-590c2a451ee8@github.com>

On Fri, 28 Feb 2025 15:59:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove VM_STRUCTS macro arguments.

Zero build is broken:

src/hotspot/share/runtime/vmStructs.cpp:1321:46: error: ?COMPILER2? was not declared in this scope; did you mean ?NOT_COMPILER2??
 1321 |   declare_preprocessor_constant("COMPILER2", COMPILER2)                   \
      |                                              ^~~~~~~~~

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

PR Comment: https://git.openjdk.org/jdk/pull/23782#issuecomment-2691102469

From sgehwolf at openjdk.org  Fri Feb 28 17:15:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Feb 2025 17:15:05 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
Message-ID: <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com>

On Wed, 26 Feb 2025 00:52:41 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

OK. I had another look and the Docker test `TestMemoryWithSubgroups.java` does indeed cover this case for cg v1.

Please update copyright years to 2025 and this should be good to go (FYI: I'll be away the next week).

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 80:

> 78:  * The method trims cgroup path from left, until the subgroup
> 79:  * component is found. The subsystem path will be set to
> 80:  * the _mount_point joined with the subgroup path.

Thanks for the comment.

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2024, Oracle and/or its affiliates. All rights reserved.

2025

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 2:

> 1: /*
> 2:  * Copyright (C) 2024, BELLSOFT. All rights reserved.

2025

test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, BELLSOFT. All rights reserved.

2025

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

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2651325697
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975746247
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975747062
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975748210
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975748978

From sgehwolf at openjdk.org  Fri Feb 28 17:15:06 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Feb 2025 17:15:06 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <Up2nvImQ0ygo9YKtNTpD1b4YtZFBmvt1d59nmky-ImI=.c7d8b52e-be3c-4533-9435-d3148a26947a@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
 <Up2nvImQ0ygo9YKtNTpD1b4YtZFBmvt1d59nmky-ImI=.c7d8b52e-be3c-4533-9435-d3148a26947a@github.com>
Message-ID: <v4YkWq0uGypzhC-M3jt8LzuTuAKDWrB_zLqzwRF8v9E=.947b5d5c-8858-44de-b33d-08bdd1f4fb95@github.com>

On Fri, 28 Feb 2025 12:19:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.
> 
> Guess this must be 2025 now ? Same for other files ...

yes indeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975746706

From coleenp at openjdk.org  Fri Feb 28 18:10:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 18:10:26 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v7]
In-Reply-To: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
Message-ID: <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>

> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix COMPILER2 preprocessor constant for SA.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23782/files
  - new: https://git.openjdk.org/jdk/pull/23782/files/aa80d2c6..38041d03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23782&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/23782

From duke at openjdk.org  Fri Feb 28 18:11:07 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Fri, 28 Feb 2025 18:11:07 GMT
Subject: RFR: 8350818: Improve OperatingSystemMXBean cpu load tests to not
 accept -1.0 by default
In-Reply-To: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
References: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
Message-ID: <hQuiweTE1xfcMJz3vHmtzPmswl2qp-gvamOIRSbLQ3k=.96d1632e-62e1-4417-ba32-adf97260c003@github.com>

On Fri, 28 Feb 2025 00:05:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The cpuLoad tests were updated to fail if -1.0 returns to catch bugs like https://bugs.openjdk.org/browse/JDK-8350820
> 
> The -1.0 means that JDK can't obtain cpu load. It shouldn't be returned.
> If this functionality doesn't work on certain configurations then they should be excluded.
> 
> The fix should be pushed after https://bugs.openjdk.org/browse/JDK-8350820
> I filed separate PR to backport fix easier.
> Also, I haven't changed indentation and didn't change getSystemCpuLoad to getCpuLoad. They return same. 
> Might be it would be better. just to rename the whole test later.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23833#pullrequestreview-2651479664

From kevinw at openjdk.org  Fri Feb 28 18:11:10 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Feb 2025 18:11:10 GMT
Subject: RFR: 8350820: OperatingSystemMXBean CpuLoad() methods return -1.0
 on Windows
In-Reply-To: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>
References: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>
Message-ID: <jE64zpH0naQB9W6I9c8odC6USaWQRTxSremq0vj3qP4=.508c2bed-8e8c-4a0d-a137-4b0af0b6dc91@github.com>

On Thu, 27 Feb 2025 23:23:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem was introduced by the 
> https://bugs.openjdk.org/browse/JDK-8336289
> 
> This pr just revert changes in src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c
> 
> The test fix is going to be pushed separately (for easy backporting) bug https://bugs.openjdk.org/browse/JDK-8350818
> 
> I verified that updated tests failed (bean returns -1.0) and now passed, also run tier1-5 testing.

This should be a trivial change.  It is a simple backout.
We have both done some testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/23832#issuecomment-2691260522

From lmesnik at openjdk.org  Fri Feb 28 18:16:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 28 Feb 2025 18:16:59 GMT
Subject: Integrated: 8350820: OperatingSystemMXBean CpuLoad() methods return
 -1.0 on Windows
In-Reply-To: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>
References: <_XIjKdfr3v2O7Wl2A6TsMkxVFSHb4jKZAUcprMSJX70=.0ea99a79-9ea7-4704-af56-51fa8651dd20@github.com>
Message-ID: <3ItEZBRMJOjPnEIeXNXN3cYGFtH6Xvk7EQmIaMWhFsc=.2b22b0d2-e465-43ed-b92f-901c247b7135@github.com>

On Thu, 27 Feb 2025 23:23:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem was introduced by the 
> https://bugs.openjdk.org/browse/JDK-8336289
> 
> This pr just revert changes in src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c
> 
> The test fix is going to be pushed separately (for easy backporting) bug https://bugs.openjdk.org/browse/JDK-8350818
> 
> I verified that updated tests failed (bean returns -1.0) and now passed, also run tier1-5 testing.

This pull request has now been integrated.

Changeset: 197004f4
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/197004f4c621d7ab4c8b9e48362973eaa18156a4
Stats:     30 lines in 1 file changed: 0 ins; 0 del; 30 mod

8350820: OperatingSystemMXBean CpuLoad() methods return -1.0 on Windows

Reviewed-by: kevinw, jwaters

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

PR: https://git.openjdk.org/jdk/pull/23832

From kvn at openjdk.org  Fri Feb 28 19:25:56 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 28 Feb 2025 19:25:56 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v7]
In-Reply-To: <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
Message-ID: <CaMEeeU0MdCZ6ZogI3TVsSiFsd--TIWdK3Uo1IFuLdQ=.02ee01cd-a99f-46d5-8354-56638986747c@github.com>

On Fri, 28 Feb 2025 18:10:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix COMPILER2 preprocessor constant for SA.

Very very nice cleanup!

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23782#pullrequestreview-2651609942

From cjplummer at openjdk.org  Fri Feb 28 19:42:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Feb 2025 19:42:54 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v7]
In-Reply-To: <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
Message-ID: <V7cRAAFsZQRhLrq4dNou4DjT-hp9qFaiqD9p8Z671Mo=.778e76bb-f8ff-406e-9051-a179ef41917f@github.com>

On Fri, 28 Feb 2025 18:10:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix COMPILER2 preprocessor constant for SA.

I wonder if you shouldn't use a new CR for this PR to make it clear to anyone that skims over the title of the PR/CR that (broken) functionality is being removed, not fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23782#issuecomment-2691416497

From kvn at openjdk.org  Fri Feb 28 20:22:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 28 Feb 2025 20:22:55 GMT
Subject: RFR: 8315488: SA ciReplay support is no longer up-to-date with
 hotspot ciReplay support [v7]
In-Reply-To: <V7cRAAFsZQRhLrq4dNou4DjT-hp9qFaiqD9p8Z671Mo=.778e76bb-f8ff-406e-9051-a179ef41917f@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
 <V7cRAAFsZQRhLrq4dNou4DjT-hp9qFaiqD9p8Z671Mo=.778e76bb-f8ff-406e-9051-a179ef41917f@github.com>
Message-ID: <dMaip_X90DKxGGXmHaexKbeO72jXRUySuAPLpwEuj04=.977a5285-ac4a-4062-a28e-797b063965a0@github.com>

On Fri, 28 Feb 2025 19:40:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I wonder if you shouldn't use a new CR for this PR to make it clear to anyone that skims over the title of the PR/CR that (broken) functionality is being removed, not fixed.

Just change title: "Remove outdated and unused ciReplay support from SA"

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

PR Comment: https://git.openjdk.org/jdk/pull/23782#issuecomment-2691478686

From coleenp at openjdk.org  Fri Feb 28 20:34:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 20:34:01 GMT
Subject: RFR: 8315488: Remove outdated and unused ciReplay support from SA
 [v7]
In-Reply-To: <dMaip_X90DKxGGXmHaexKbeO72jXRUySuAPLpwEuj04=.977a5285-ac4a-4062-a28e-797b063965a0@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
 <V7cRAAFsZQRhLrq4dNou4DjT-hp9qFaiqD9p8Z671Mo=.778e76bb-f8ff-406e-9051-a179ef41917f@github.com>
 <dMaip_X90DKxGGXmHaexKbeO72jXRUySuAPLpwEuj04=.977a5285-ac4a-4062-a28e-797b063965a0@github.com>
Message-ID: <io0Ts8JYG0ILDfBmK1p7JvDRtHEqa1Z5OWPs5YUe66s=.7665915b-3f18-44d6-8d9e-7156c341d4b4@github.com>

On Fri, 28 Feb 2025 20:19:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I wonder if you shouldn't use a new CR for this PR to make it clear to anyone that skims over the title of the PR/CR that (broken) functionality is being removed, not fixed.

> Just change title: "Remove outdated and unused ciReplay support from SA"

Yes, I'll do this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23782#issuecomment-2691495918

From coleenp at openjdk.org  Fri Feb 28 20:37:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 20:37:57 GMT
Subject: RFR: 8315488: Remove outdated and unused ciReplay support from SA
 [v7]
In-Reply-To: <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
Message-ID: <2vNU1BcX8FSq7s_iWc6oLtaQn14mK17MNGue6p_EWS4=.f0892f74-4abb-4313-88ad-df1d4e7853b2@github.com>

On Fri, 28 Feb 2025 18:10:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix COMPILER2 preprocessor constant for SA.

Thank you for reviewing Vladimir.  I'll file the other issue but not a "starter".  New people should do more interesting things :)

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

PR Comment: https://git.openjdk.org/jdk/pull/23782#issuecomment-2691502362

From schernyshev at openjdk.org  Fri Feb 28 20:40:38 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 28 Feb 2025 20:40:38 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
 <9BhHiBHy6g34Uq67jJQb4J2vnCl7rksMT0aSFJTZss0=.16c54e0f-7306-4cde-8d7c-6c0b2ee425a3@github.com>
Message-ID: <d2YBoS1QSE3F0IT5bxvDk_Gav5regN3-ee6fNcMkwQk=.7f460d0b-7dbe-497a-8eda-d5c9f3fcefd5@github.com>

On Fri, 28 Feb 2025 17:08:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> 2025

thanks. done.

> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (C) 2024, BELLSOFT. All rights reserved.
> 
> 2025

fixed.

> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, BELLSOFT. All rights reserved.
> 
> 2025

done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975981433
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975980784
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975980336

From schernyshev at openjdk.org  Fri Feb 28 20:40:38 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 28 Feb 2025 20:40:38 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <v4YkWq0uGypzhC-M3jt8LzuTuAKDWrB_zLqzwRF8v9E=.947b5d5c-8858-44de-b33d-08bdd1f4fb95@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
 <Up2nvImQ0ygo9YKtNTpD1b4YtZFBmvt1d59nmky-ImI=.c7d8b52e-be3c-4533-9435-d3148a26947a@github.com>
 <v4YkWq0uGypzhC-M3jt8LzuTuAKDWrB_zLqzwRF8v9E=.947b5d5c-8858-44de-b33d-08bdd1f4fb95@github.com>
Message-ID: <I2JqMAlGL8F-Aht1YRm4mjZmVr_rpjjSRdSi7AVLvLQ=.7b23dafc-dbb6-4e82-bc38-58b9375aa6dc@github.com>

On Fri, 28 Feb 2025 17:07:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2020, 2024, Red Hat Inc.
>> 
>> Guess this must be 2025 now ? Same for other files ...
>
> yes indeed.

indeed, updated the copyright headers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975983416

From schernyshev at openjdk.org  Fri Feb 28 20:40:37 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 28 Feb 2025 20:40:37 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/c9391dd4..bae78ff7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=15-16

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From schernyshev at openjdk.org  Fri Feb 28 20:47:08 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 28 Feb 2025 20:47:08 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v16]
In-Reply-To: <IwVJeqTk0HxHxFi4B64nemBTTG0Tq6gDsMA6CmMDMAU=.b28d7564-3af4-44f0-957b-a998cb0f5540@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <3jmigJ5lOjLiEq7l5cKc6lj4wU_6vRoH-qSHniQmhFk=.f4706001-274a-4d9e-bda5-37e5f4be29b1@github.com>
 <IwVJeqTk0HxHxFi4B64nemBTTG0Tq6gDsMA6CmMDMAU=.b28d7564-3af4-44f0-957b-a998cb0f5540@github.com>
Message-ID: <bBJChknHwVdJDVd9Rr6qRUClSrpSiLRyKQg6vdG6N_M=.a58287c6-8320-4e47-8459-dcf59fb36e82@github.com>

On Fri, 28 Feb 2025 12:27:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> test/jdk/jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java line 69:
> 
>> 67:     /*
>> 68:      * Less common cases: Containers
>> 69:      */
> 
> Not really sure why this comment was added, is it refering to 'container mode'  mentioned in the comment above in another file?

It's because there are already "Common case: Containers" and "Common case: Host". The old test testCgPathSubstring() and the new test testCgPathToMovedPath() do not belong to "Common case: Host" that comes just before them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1975991035

From cjplummer at openjdk.org  Fri Feb 28 22:14:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Feb 2025 22:14:54 GMT
Subject: RFR: 8315488: Remove outdated and unused ciReplay support from SA
 [v7]
In-Reply-To: <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
Message-ID: <0sRMry6CP4Bis6-ALc4UCQzBLOP4sr0Ejcd7hoTolQw=.81937e97-ceb6-43fb-9449-ab49bb307853@github.com>

On Fri, 28 Feb 2025 18:10:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix COMPILER2 preprocessor constant for SA.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23782#pullrequestreview-2651860962

From lmesnik at openjdk.org  Fri Feb 28 22:40:56 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 28 Feb 2025 22:40:56 GMT
Subject: Integrated: 8350818: Improve OperatingSystemMXBean cpu load tests to
 not accept -1.0 by default
In-Reply-To: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
References: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
Message-ID: <bM76JPEHqqsGvm2wZZCql9r9g3NW_hgvWA42wCluawY=.7af00f62-b4cb-4301-a7aa-112e7530d78e@github.com>

On Fri, 28 Feb 2025 00:05:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The cpuLoad tests were updated to fail if -1.0 returns to catch bugs like https://bugs.openjdk.org/browse/JDK-8350820
> 
> The -1.0 means that JDK can't obtain cpu load. It shouldn't be returned.
> If this functionality doesn't work on certain configurations then they should be excluded.
> 
> The fix should be pushed after https://bugs.openjdk.org/browse/JDK-8350820
> I filed separate PR to backport fix easier.
> Also, I haven't changed indentation and didn't change getSystemCpuLoad to getCpuLoad. They return same. 
> Might be it would be better. just to rename the whole test later.

This pull request has now been integrated.

Changeset: 3c72c04d
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c72c04de7a43d265dae7160fe53baaaa8ae6f73
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8350818: Improve OperatingSystemMXBean cpu load tests to not accept -1.0 by default

Reviewed-by: kevinw

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

PR: https://git.openjdk.org/jdk/pull/23833