From iklam at openjdk.org  Sat Mar  1 00:08:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 1 Mar 2025 00:08:56 GMT
Subject: RFR: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled [v2]
In-Reply-To: <kV25ydIvYqE_Q4wwbWgbguFYoAXHNsmLEs6aH-dtsiE=.39f2ee05-308e-4159-8c65-1dd2c368eb17@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
 <pFHeLghBAC2j2_TZs6-FnrGQqoyg99qByXIupZvxvqU=.0859f4f4-a38b-4d7f-b6c9-8887e0acf0dc@github.com>
 <kV25ydIvYqE_Q4wwbWgbguFYoAXHNsmLEs6aH-dtsiE=.39f2ee05-308e-4159-8c65-1dd2c368eb17@github.com>
Message-ID: <LOHsrEp1kTEmRqgtVcwBu7ko3v7owBP35NCHHI-_i3k=.d182ca1f-2c69-4207-a08f-a1023df32beb@github.com>

On Fri, 28 Feb 2025 22:59:22 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/share/cds/cdsConfig.cpp line 618:
>> 
>>> 616: // Archived MethodHandles are required for higher-level optimizations such as AOT resolution of invokedynamic
>>> 617: // and dynamic proxies.
>>> 618: bool CDSConfig::is_dumping_method_handles() {
>> 
>> This looks like it does the same check as `is_initing_classes_at_dump_time() ` and is very similar to `is_dumping_invokedynamic()`. Maybe you can combine these methods to avoid duplicate code?
>
> I removed the `CDSConfig::is_initing_classes_at_dump_time()` since the conditions are the same as `CDSConfig::is_dumping_method_handles()`. All the calls to `CDSConfig::is_initing_classes_at_dump_time()` have been updated accordingly.

I think we should keep `is_initing_classes_at_dump_time()`, because it's used as a precondition for archiving initialized Java mirrors. Putting such code inside `is_dumping_method_handles()` would not make sense.

In fact, archived method handles require the ability to store initialized mirrors (for the hidden classes). So I think we should change `is_dumping_method_handles()` to this:


// When we can dump initialized classes mirrors, we automatically enable the archiving of MethodHandles.
// This will in turn enable the archiving of MethodTypes and hidden classes that are used in the
// implementation of MethodHandles. Note: these hidden classes need to be stored in the initialized state,
// as we don't have a mechanism to trigger their initialization on-demand.
// Archived MethodHandles are required for higher-level optimizations such as AOT resolution of invokedynamic
// and dynamic proxies.
bool CDSConfig::is_dumping_method_handles() {
  return is_initing_classes_at_dump_time();
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1976136046

From ccheung at openjdk.org  Sat Mar  1 00:59:23 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Sat, 1 Mar 2025 00:59:23 GMT
Subject: RFR: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled [v3]
In-Reply-To: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
Message-ID: <oLNZaTNQYF8kw7GbJFfgR77HptD-O981ilO2O5z5g84=.4a074e96-7284-4569-bb50-306fcfc7a9d8@github.com>

> This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled.
> Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation:
> 
> 
> [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
> [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST
> 
> Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function.
> 
> Passed tiers 1 - 3 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23546/files
  - new: https://git.openjdk.org/jdk/pull/23546/files/c41728cc..fdc3836d

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

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

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

From ccheung at openjdk.org  Sat Mar  1 00:59:23 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Sat, 1 Mar 2025 00:59:23 GMT
Subject: RFR: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled [v3]
In-Reply-To: <LOHsrEp1kTEmRqgtVcwBu7ko3v7owBP35NCHHI-_i3k=.d182ca1f-2c69-4207-a08f-a1023df32beb@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
 <pFHeLghBAC2j2_TZs6-FnrGQqoyg99qByXIupZvxvqU=.0859f4f4-a38b-4d7f-b6c9-8887e0acf0dc@github.com>
 <kV25ydIvYqE_Q4wwbWgbguFYoAXHNsmLEs6aH-dtsiE=.39f2ee05-308e-4159-8c65-1dd2c368eb17@github.com>
 <LOHsrEp1kTEmRqgtVcwBu7ko3v7owBP35NCHHI-_i3k=.d182ca1f-2c69-4207-a08f-a1023df32beb@github.com>
Message-ID: <Pbut3uf76u_7MwNZUxanvAj2Jhgb45a6HzFOtpLIhRc=.058c7c7d-0a90-4165-bf58-160a71e51ff7@github.com>

On Sat, 1 Mar 2025 00:06:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I removed the `CDSConfig::is_initing_classes_at_dump_time()` since the conditions are the same as `CDSConfig::is_dumping_method_handles()`. All the calls to `CDSConfig::is_initing_classes_at_dump_time()` have been updated accordingly.
>
> I think we should keep `is_initing_classes_at_dump_time()`, because it's used as a precondition for archiving initialized Java mirrors. Putting such code inside `is_dumping_method_handles()` would not make sense.
> 
> In fact, archived method handles require the ability to store initialized mirrors (for the hidden classes). So I think we should change `is_dumping_method_handles()` to this:
> 
> 
> // When we can dump initialized classes mirrors, we automatically enable the archiving of MethodHandles.
> // This will in turn enable the archiving of MethodTypes and hidden classes that are used in the
> // implementation of MethodHandles. Note: these hidden classes need to be stored in the initialized state,
> // as we don't have a mechanism to trigger their initialization on-demand.
> // Archived MethodHandles are required for higher-level optimizations such as AOT resolution of invokedynamic
> // and dynamic proxies.
> bool CDSConfig::is_dumping_method_handles() {
>   return is_initing_classes_at_dump_time();
> }

I added back the `CDSConfig::is_initing_classes_at_dump_time()` function and reverted most of previous changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1976186871

From dlong at openjdk.org  Sat Mar  1 02:22:32 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 1 Mar 2025 02:22:32 GMT
Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization
 causes crash [v4]
In-Reply-To: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
Message-ID: <Fa9hDpRRHNXS6DyH6G7VJ5YJxa2w7eW5fFMzthVzi64=.2202f767-2ca9-42c2-91ad-5a051b0b2041@github.com>

> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received.  In deoptimization, we check for this in several places, but in one place we had outdated code.  See the bug for the gory details.
> 
> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations.  There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports.
> 
> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee.  The asserts I added compute locals both ways and check that they are still within the frame.  I attempted this on all platforms, but am only able to test x64 and aarch64.  I need help testing those asserts for arm32, ppc, riscv, and s390.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  use new Bytecode_invoke::has_memeber_arg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23557/files
  - new: https://git.openjdk.org/jdk/pull/23557/files/ebf10dae..375f6cfe

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

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

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

From dlong at openjdk.org  Sat Mar  1 02:22:32 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 1 Mar 2025 02:22:32 GMT
Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization
 causes crash [v3]
In-Reply-To: <pJODyiI3BUhPSQxR6cZGzwH6WgsV75iGN0c1DCKGvt8=.952ccb59-fd07-4a93-b471-cd5f7893a466@github.com>
References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
 <pJODyiI3BUhPSQxR6cZGzwH6WgsV75iGN0c1DCKGvt8=.952ccb59-fd07-4a93-b471-cd5f7893a466@github.com>
Message-ID: <SHs5Uw8e8MMwxuhQZRiUwrNPHfi9jky2irMhvS7l-5U=.65239d49-45cb-4a2b-bdbc-f67724d91367@github.com>

On Wed, 19 Feb 2025 00:37:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received.  In deoptimization, we check for this in several places, but in one place we had outdated code.  See the bug for the gory details.
>> 
>> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations.  There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports.
>> 
>> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee.  The asserts I added compute locals both ways and check that they are still within the frame.  I attempted this on all platforms, but am only able to test x64 and aarch64.  I need help testing those asserts for arm32, ppc, riscv, and s390.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stricter assertion on ppc64

Thanks Patricio and Richard for the reviews.  New commit pushed that adds Bytecode_invoke::has_memeber_arg as suggested by Richard.

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

PR Comment: https://git.openjdk.org/jdk/pull/23557#issuecomment-2691853937

From iklam at openjdk.org  Sat Mar  1 04:43:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 1 Mar 2025 04:43:57 GMT
Subject: RFR: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled [v3]
In-Reply-To: <Pbut3uf76u_7MwNZUxanvAj2Jhgb45a6HzFOtpLIhRc=.058c7c7d-0a90-4165-bf58-160a71e51ff7@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
 <pFHeLghBAC2j2_TZs6-FnrGQqoyg99qByXIupZvxvqU=.0859f4f4-a38b-4d7f-b6c9-8887e0acf0dc@github.com>
 <kV25ydIvYqE_Q4wwbWgbguFYoAXHNsmLEs6aH-dtsiE=.39f2ee05-308e-4159-8c65-1dd2c368eb17@github.com>
 <LOHsrEp1kTEmRqgtVcwBu7ko3v7owBP35NCHHI-_i3k=.d182ca1f-2c69-4207-a08f-a1023df32beb@github.com>
 <Pbut3uf76u_7MwNZUxanvAj2Jhgb45a6HzFOtpLIhRc=.058c7c7d-0a90-4165-bf58-160a71e51ff7@github.com>
Message-ID: <4PR8ziZrn7yRPiolUarpUsKKY80v_kdA9Q09mc89NyY=.5084c276-675e-4c60-a1d7-eb2397b122bd@github.com>

On Sat, 1 Mar 2025 00:56:20 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> I think we should keep `is_initing_classes_at_dump_time()`, because it's used as a precondition for archiving initialized Java mirrors. Putting such code inside `is_dumping_method_handles()` would not make sense.
>> 
>> In fact, archived method handles require the ability to store initialized mirrors (for the hidden classes). So I think we should change `is_dumping_method_handles()` to this:
>> 
>> 
>> // When we can dump initialized classes mirrors, we automatically enable the archiving of MethodHandles.
>> // This will in turn enable the archiving of MethodTypes and hidden classes that are used in the
>> // implementation of MethodHandles. Note: these hidden classes need to be stored in the initialized state,
>> // as we don't have a mechanism to trigger their initialization on-demand.
>> // Archived MethodHandles are required for higher-level optimizations such as AOT resolution of invokedynamic
>> // and dynamic proxies.
>> bool CDSConfig::is_dumping_method_handles() {
>>   return is_initing_classes_at_dump_time();
>> }
>
> I added back the `CDSConfig::is_initing_classes_at_dump_time()` function and reverted most of previous changes.

The three changes in aotArtifactFinder.cpp should also be reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1976292331

From rrich at openjdk.org  Sat Mar  1 22:23:56 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Sat, 1 Mar 2025 22:23:56 GMT
Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization
 causes crash [v4]
In-Reply-To: <Fa9hDpRRHNXS6DyH6G7VJ5YJxa2w7eW5fFMzthVzi64=.2202f767-2ca9-42c2-91ad-5a051b0b2041@github.com>
References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
 <Fa9hDpRRHNXS6DyH6G7VJ5YJxa2w7eW5fFMzthVzi64=.2202f767-2ca9-42c2-91ad-5a051b0b2041@github.com>
Message-ID: <TW6xcOuJ2mZv4ranvXMNYeDtQ1JqVSuC7eAa65DY3xk=.e3868b19-b6f1-47a0-90a1-b8b9e44f4639@github.com>

On Sat, 1 Mar 2025 02:22:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received.  In deoptimization, we check for this in several places, but in one place we had outdated code.  See the bug for the gory details.
>> 
>> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations.  There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports.
>> 
>> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee.  The asserts I added compute locals both ways and check that they are still within the frame.  I attempted this on all platforms, but am only able to test x64 and aarch64.  I need help testing those asserts for arm32, ppc, riscv, and s390.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use new Bytecode_invoke::has_memeber_arg

Marked as reviewed by rrich (Reviewer).

src/hotspot/share/runtime/vframeArray.cpp line 616:

> 614:       // invokedynamic instructions don't have a class but obviously don't have a MemberName appendix.
> 615:       // NOTE:  Use machinery here that avoids resolving of any kind.
> 616:       const bool has_member_arg = inv.has_member_arg();

I reckon the comment about invokedynamic isn't needed anymore. It could be moved to has_member_arg if you want to keep it.

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

PR Review: https://git.openjdk.org/jdk/pull/23557#pullrequestreview-2652589555
PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1976500470

From jsjolen at openjdk.org  Sat Mar  1 22:27:10 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Sat, 1 Mar 2025 22:27:10 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32]
In-Reply-To: <qPuuX0ubO3vgpz0W9cNZHrYrr4RxIeaa1R6VgROEKwU=.0e2892cb-fa80-4898-82fd-049d3f9cbac0@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <xeaZcfMg4KxBUN99FHNf86nRMRtlmkQRedFJCzJmH04=.6dfed2c3-ea45-453e-bc7d-53b60934392d@github.com>
 <t9of7J_1WtTHhzVKX2kePpCrMo7bdzdVSrRvIF0nhkI=.bfff6824-e6f1-41c0-8362-55cbb9e3975d@github.com>
 <WoNpmMK-bG1sPLqk7C-VwOSSbeSthZ3YWbbzSsOcgEE=.512b0f16-a68d-49bf-93a0-6f31336e4c39@github.com>
 <_NgwaL7X0Wail8MgHyql0JSLLkPBbHgrnCuuhdDEpzo=.8a272cee-1077-4c68-a018-5df5c867cc68@github.com>
 <qPuuX0ubO3vgpz0W9cNZHrYrr4RxIeaa1R6VgROEKwU=.0e2892cb-fa80-4898-82fd-049d3f9cbac0@github.com>
Message-ID: <7GabYGWGOVewzZ1pVdsSHKBcZjTkMw9OIT3j-AAdEEY=.430b65f8-0f1d-4796-bee4-ecdc92f4a06b@github.com>

On Fri, 28 Feb 2025 19:51:20 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> The `HeapReserver` and `MemoryFileTracker` classes (in different parts of the code and different PRs) also use the same syntax for it. Here the same style is used to keep similarity in Hotspot code.
>
> Right, I didn't like it before, and spoke out against it, and now it is spreading :-)
> 
> Why do we want to have more than one VMT? If we truly do, then I'm not sure there is anything that could be done here.

We want to have many because it makes unit testing easier and more reliable, there is no longer any need to access the global object which the rest of the VM is working with. There are more advantages: Each member does not have to be static and a pointer which is initialized separately, everything is under one call to malloc. That reduces the number of pointers, keeping the lifetimes of the objects trivial. I'll pay some verbosity for that any day :-).

If we find an alternative, can it wait with being implemented until this is integrated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1976500876

From jsjolen at openjdk.org  Sat Mar  1 22:30:05 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Sat, 1 Mar 2025 22:30:05 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v32]
In-Reply-To: <ZOUqs7jgcnSiZ2Ce-oAh17Hx-7HmEGMurBfIrnv3vck=.4f4759f6-4a2f-4cfa-85cc-89558e2d1e3a@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <xeaZcfMg4KxBUN99FHNf86nRMRtlmkQRedFJCzJmH04=.6dfed2c3-ea45-453e-bc7d-53b60934392d@github.com>
 <t9of7J_1WtTHhzVKX2kePpCrMo7bdzdVSrRvIF0nhkI=.bfff6824-e6f1-41c0-8362-55cbb9e3975d@github.com>
 <COx9rY1H7FrfNTK_ntilPVcA0Jp3P2xIIQf8IphM4aQ=.d9e966c6-218d-4835-8734-bed4f719084e@github.com>
 <i90Z7Og-0pJLugzXrwSCuMyP91g-VHPEyTkGTcS_UJg=.4f207e05-70cb-47c5-87e2-5d09a7e26feb@github.com>
 <ZOUqs7jgcnSiZ2Ce-oAh17Hx-7HmEGMurBfIrnv3vck=.4f4759f6-4a2f-4cfa-85cc-89558e2d1e3a@github.com>
Message-ID: <tqzgRuckR1QwcvWFRleIQ-ZfM-92HgNBeNCwgzUqBuU=.340d5951-a8ca-4b0f-b6b7-a807191fe813@github.com>

On Fri, 28 Feb 2025 19:54:48 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> There is coding style that the last enum member counts the number of them, like what we have `mt_number_of_tags` in `MemTag` enum. 
>> So, I renamed the last member to `st_number_of_states`. Would it be OK? Or preferred to use constant separately.
>
> Just because we do something already in Hotspot, doesn't necessarily mean that we should repeat the pattern going forward.
> 
> I flagged it and I really don't like it, if you guys are OK with it, I will let it be.

I'm fine with either

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1976501256

From iklam at openjdk.org  Sun Mar  2 03:46:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 2 Mar 2025 03:46:57 GMT
Subject: Integrated: 8350916: Remove misleading warning
 "Cannot dump shared archive while using shared archive"
In-Reply-To: <w-emwtETpEBW9gBbHO_mivvLV27WcGLn9EESvwujB6w=.c5a75bb9-c6d0-442f-b395-993ca088f7ba@github.com>
References: <w-emwtETpEBW9gBbHO_mivvLV27WcGLn9EESvwujB6w=.c5a75bb9-c6d0-442f-b395-993ca088f7ba@github.com>
Message-ID: <UzwvoalmxXgKK_8QXXcgZpYK5V9M6ekHhbUMbRlBQHw=.de2b25e7-bfd1-4bfa-93bc-ab971c07befd@github.com>

On Fri, 28 Feb 2025 02:10:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change. I replaced an unreachable `warning()` call with an assert and an explanation in comments.
> 
> I verified with running all CDS tests and the assert is never triggered.

This pull request has now been integrated.

Changeset: 157e5ad4
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/157e5ad4a3abc7aea9ec2ec3d2381e42101990b8
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8350916: Remove misleading warning "Cannot dump shared archive while using shared archive"

Reviewed-by: ccheung

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

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

From sgehwolf at openjdk.org  Sun Mar  2 19:10:06 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Sun, 2 Mar 2025 19:10:06 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
Message-ID: <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>

On Fri, 28 Feb 2025 20:40:37 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 copyright headers

OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2652794986

From jsjolen at openjdk.org  Sun Mar  2 20:18:54 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Sun, 2 Mar 2025 20:18:54 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v2]
In-Reply-To: <WjTuC-9gp_g7FaSEN7TU-BnF-uyUANzRc37hNk4D7ok=.de778777-dfd8-4b1e-b02c-6c00528e7b4d@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
 <WjTuC-9gp_g7FaSEN7TU-BnF-uyUANzRc37hNk4D7ok=.de778777-dfd8-4b1e-b02c-6c00528e7b4d@github.com>
Message-ID: <1miELHdDyoRgKM2A-0JWJpY_0y5PBudG75qjwgdJJrg=.7a172ae5-c230-42a7-949e-9dbb5a1f12f9@github.com>

On Thu, 27 Feb 2025 12:37:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - removed extra whitespace.
>>  - unit test added.
>
> test/hotspot/gtest/nmt/test_vmatree.cpp line 728:
> 
>> 726: }
>> 727: 
>> 728: TEST_VM_F(NMTVMATreeTest, CommitUseFlagInplace) {
> 
> Change this test to use `expect_equivalent_form`, see other usages to see what should look like. You can add multiple checks even, so that we get how the range changes over time.

Is the bug actually in the summary accounting? If so, I'd like to see a better test name here that indicates that and *not* change this to `expect_equivalent_form` and so on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1976707081

From jsjolen at openjdk.org  Sun Mar  2 20:18:53 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Sun, 2 Mar 2025 20:18:53 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v2]
In-Reply-To: <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
Message-ID: <UqCZynU3EpRgra-V6L9XhHFT0g-GxRh23h9amtGim7Y=.c4545ef9-f6c7-490e-9446-4caf8acb183f@github.com>

On Thu, 27 Feb 2025 09:38:12 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR.
>> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR.
>> 
>> Tests:
>> linux-x64-debug, gtest:NMT*, runtime/NMT
>
> Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed extra whitespace.
>  - unit test added.

It seems like the actual bug is in the summary diff accounting code and *not*  in the actual reservations, see comments. Is that correct?

src/hotspot/share/nmt/vmatree.cpp line 80:

> 78:       MemTag tag = leqA_n->val().out.mem_tag();
> 79:       stA.out.set_tag(tag);
> 80:       LEQ_A.state.out.set_tag(tag);

Shouldn't `LEQ_A.state.out`'s tag already be `tag`? Is this line really necessary?

src/hotspot/share/nmt/vmatree.cpp line 210:

> 208: 
> 209:   // Finally, we can register the new region [A, B)'s summary data.
> 210:   MemTag tag_to_change = use_tag_inplace ? stA.out.mem_tag() : metadata.mem_tag;

Do we ever change the `stA.out.mem_tag()` ? Can't it always be `stA.out.mem_tag()`?

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

PR Review: https://git.openjdk.org/jdk/pull/23771#pullrequestreview-2652806668
PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1976706349
PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1976706641

From schernyshev at openjdk.org  Sun Mar  2 21:19:58 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Sun, 2 Mar 2025 21:19:58 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
 <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
Message-ID: <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>

On Sun, 2 Mar 2025 19:07:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.

Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2692912180

From dholmes at openjdk.org  Mon Mar  3 04:15:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Mar 2025 04:15:57 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v4]
In-Reply-To: <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
 <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com>
 <lKSu4UoGBLaWqEQbM2lJ0ctU5sDPZNkZtFfVNSJdwXs=.5f5a530f-f4f7-4715-a109-c913d38ad373@github.com>
 <x9aEMsQnMrC5ikLH-pbRzGF6EtkkAXppinbZIswVydI=.2d0d18d8-3af2-4f84-928f-95a384f846c7@github.com>
 <FpigHhXOb9nISzF_4EqAR5fzM6pUhVtpTyz7fXqd7_A=.13e96a32-e426-4ee2-8401-7337ca34367c@github.com>
 <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com>
 <iv39Wpp0MFwwesm5NI3ZvZD-xDnFyk4kZMpd19EZ30w=.b0b26989-7499-4b70-97ae-97e19138fe89@github.com>
 <WPY1X633YLLzKWRGX4RJma0CF983CGb1bSMrMs815jM=.084998ec-5bd2-4df5-8948-2161b4c6dd92@github.com>
 <azWxxjE8kLgJpSAiU4SAOk_E4ggzuN_rdoUHxbKHpE4=.275aa5f2-e7e7-4b6e-ad28-a3f34613b1e2@github.com>
 <DTJzFg5YGxLmof32AHTbpGnbIqUO_ygljkHGzhi0pKY=.c68129f6-dbab-4be9-b286-f5d892be60e6@github.com>
 <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x
 YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com>
 <ATSNFuB3otIkeyutW0m0RZHb_OA6BQPxgVanqPUHcAk=.ea8402a7-7058-4edc-aff8-0d6e48a4cedf@github.com>
 <ghaunIfZWap8c9LPz8jpYA_8KFTUhMkDZ1gkwD8kM2E=.cea3a66a-cb87-4464-a3b3-c5a9110fc75b@github.com>
 <tfNnOivL70wmw5IJ0catb58ef4ssrcmeztdgq_H525k=.432a5a11-afd1-4c6f-b24e-297e912ecb4d@github.com>
 <cZf3RuYW5CuMeRXOiJcepc70WK0eY5DITnZh1Elx4mM=.1a7e9d1d-b4a7-4cbb-b6a2-47b21f7aea52@github.com>
 <Bctrj8H3ZpTmh4JxhPpbEkG5m18Qa0roptqVW9czRKQ=.12d8658b-891c-44f9-8717-454dbecd8927@github.com>
 <uUzETr66Gr6wUUB54oHOJJcjemTcKgLFEwB-AdPp1pg=.5209349d-4fe7-48fa-9459-9f3a4555ff16@github.com>
 <RyyM64wPq5iN-sAEvt6SZidNvW51J4HqVzcTG7bNcwY=.56c40bb7-2974-4e00-9b01-3a99041edbff@github.com>
 <x-bxlwRSaJZdwXbU9zsYvgooLlAu3DX5Cj8kao1G6S0=.17f24dfe-94ef-4738-889d-2daa00e5725b@github.com>
 <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
Message-ID: <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@github.com>

On Fri, 28 Feb 2025 14:20:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Uggghhh - I see. So why isn't this caught at ` ~ThreadBlockInVMPreprocess()`? Sorry I'm struggling to see the complete code.
>
> We only allow suspension at `~ThreadBlockInVMPreprocess()` on very few cases where we know it's safe because there are no VM monitors held (the ones in ObjectMonitor, JvmtiRawMonitor and JavaThread::wait_for_object_deoptimization()). Otherwise the default is to not process suspend requests there.

Can we customise the TBIVM in this case (for the JVMTIThreadState_lock) to allow suspend checks - I would not expect this to be happening when VM locks are held.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1976850275

From dholmes at openjdk.org  Mon Mar  3 05:13:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Mar 2025 05:13:52 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v4]
In-Reply-To: <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
 <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com>
 <lKSu4UoGBLaWqEQbM2lJ0ctU5sDPZNkZtFfVNSJdwXs=.5f5a530f-f4f7-4715-a109-c913d38ad373@github.com>
 <x9aEMsQnMrC5ikLH-pbRzGF6EtkkAXppinbZIswVydI=.2d0d18d8-3af2-4f84-928f-95a384f846c7@github.com>
 <FpigHhXOb9nISzF_4EqAR5fzM6pUhVtpTyz7fXqd7_A=.13e96a32-e426-4ee2-8401-7337ca34367c@github.com>
 <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com>
 <iv39Wpp0MFwwesm5NI3ZvZD-xDnFyk4kZMpd19EZ30w=.b0b26989-7499-4b70-97ae-97e19138fe89@github.com>
 <WPY1X633YLLzKWRGX4RJma0CF983CGb1bSMrMs815jM=.084998ec-5bd2-4df5-8948-2161b4c6dd92@github.com>
 <azWxxjE8kLgJpSAiU4SAOk_E4ggzuN_rdoUHxbKHpE4=.275aa5f2-e7e7-4b6e-ad28-a3f34613b1e2@github.com>
 <DTJzFg5YGxLmof32AHTbpGnbIqUO_ygljkHGzhi0pKY=.c68129f6-dbab-4be9-b286-f5d892be60e6@github.com>
 <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x
 YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com>
 <ATSNFuB3otIkeyutW0m0RZHb_OA6BQPxgVanqPUHcAk=.ea8402a7-7058-4edc-aff8-0d6e48a4cedf@github.com>
 <ghaunIfZWap8c9LPz8jpYA_8KFTUhMkDZ1gkwD8kM2E=.cea3a66a-cb87-4464-a3b3-c5a9110fc75b@github.com>
 <tfNnOivL70wmw5IJ0catb58ef4ssrcmeztdgq_H525k=.432a5a11-afd1-4c6f-b24e-297e912ecb4d@github.com>
 <cZf3RuYW5CuMeRXOiJcepc70WK0eY5DITnZh1Elx4mM=.1a7e9d1d-b4a7-4cbb-b6a2-47b21f7aea52@github.com>
 <Bctrj8H3ZpTmh4JxhPpbEkG5m18Qa0roptqVW9czRKQ=.12d8658b-891c-44f9-8717-454dbecd8927@github.com>
 <uUzETr66Gr6wUUB54oHOJJcjemTcKgLFEwB-AdPp1pg=.5209349d-4fe7-48fa-9459-9f3a4555ff16@github.com>
 <RyyM64wPq5iN-sAEvt6SZidNvW51J4HqVzcTG7bNcwY=.56c40bb7-2974-4e00-9b01-3a99041edbff@github.com>
 <x-bxlwRSaJZdwXbU9zsYvgooLlAu3DX5Cj8kao1G6S0=.17f24dfe-94ef-4738-889d-2daa00e5725b@github.com>
 <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
 <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@
 github.com>
 <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com>
Message-ID: <oloAmS2y0tCsZtUv5kkaEGOOJZqw7FYhfqllwpP36Go=.afb5ad6c-49ac-4481-999d-4219a19aebfa@github.com>

On Mon, 3 Mar 2025 05:09:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Can we customise the TBIVM in this case (for the JVMTIThreadState_lock) to allow suspend checks - I would not expect this to be happening when VM locks are held.
>
> Sorry that wasn't well thought out - we would need to pass this through all the mutex code to allow it to be specialized.
> 
> Do we still have a "suspension disabler" that would prevent the suspend from being processed by the mutex blocking?

For use in ` JvmtiExport::at_single_stepping_point`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1976886110

From dholmes at openjdk.org  Mon Mar  3 05:13:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Mar 2025 05:13:52 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v4]
In-Reply-To: <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
 <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com>
 <lKSu4UoGBLaWqEQbM2lJ0ctU5sDPZNkZtFfVNSJdwXs=.5f5a530f-f4f7-4715-a109-c913d38ad373@github.com>
 <x9aEMsQnMrC5ikLH-pbRzGF6EtkkAXppinbZIswVydI=.2d0d18d8-3af2-4f84-928f-95a384f846c7@github.com>
 <FpigHhXOb9nISzF_4EqAR5fzM6pUhVtpTyz7fXqd7_A=.13e96a32-e426-4ee2-8401-7337ca34367c@github.com>
 <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com>
 <iv39Wpp0MFwwesm5NI3ZvZD-xDnFyk4kZMpd19EZ30w=.b0b26989-7499-4b70-97ae-97e19138fe89@github.com>
 <WPY1X633YLLzKWRGX4RJma0CF983CGb1bSMrMs815jM=.084998ec-5bd2-4df5-8948-2161b4c6dd92@github.com>
 <azWxxjE8kLgJpSAiU4SAOk_E4ggzuN_rdoUHxbKHpE4=.275aa5f2-e7e7-4b6e-ad28-a3f34613b1e2@github.com>
 <DTJzFg5YGxLmof32AHTbpGnbIqUO_ygljkHGzhi0pKY=.c68129f6-dbab-4be9-b286-f5d892be60e6@github.com>
 <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x
 YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com>
 <ATSNFuB3otIkeyutW0m0RZHb_OA6BQPxgVanqPUHcAk=.ea8402a7-7058-4edc-aff8-0d6e48a4cedf@github.com>
 <ghaunIfZWap8c9LPz8jpYA_8KFTUhMkDZ1gkwD8kM2E=.cea3a66a-cb87-4464-a3b3-c5a9110fc75b@github.com>
 <tfNnOivL70wmw5IJ0catb58ef4ssrcmeztdgq_H525k=.432a5a11-afd1-4c6f-b24e-297e912ecb4d@github.com>
 <cZf3RuYW5CuMeRXOiJcepc70WK0eY5DITnZh1Elx4mM=.1a7e9d1d-b4a7-4cbb-b6a2-47b21f7aea52@github.com>
 <Bctrj8H3ZpTmh4JxhPpbEkG5m18Qa0roptqVW9czRKQ=.12d8658b-891c-44f9-8717-454dbecd8927@github.com>
 <uUzETr66Gr6wUUB54oHOJJcjemTcKgLFEwB-AdPp1pg=.5209349d-4fe7-48fa-9459-9f3a4555ff16@github.com>
 <RyyM64wPq5iN-sAEvt6SZidNvW51J4HqVzcTG7bNcwY=.56c40bb7-2974-4e00-9b01-3a99041edbff@github.com>
 <x-bxlwRSaJZdwXbU9zsYvgooLlAu3DX5Cj8kao1G6S0=.17f24dfe-94ef-4738-889d-2daa00e5725b@github.com>
 <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
 <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@
 github.com>
Message-ID: <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com>

On Mon, 3 Mar 2025 04:13:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We only allow suspension at `~ThreadBlockInVMPreprocess()` on very few cases where we know it's safe because there are no VM monitors held (the ones in ObjectMonitor, JvmtiRawMonitor and JavaThread::wait_for_object_deoptimization()). Otherwise the default is to not process suspend requests there.
>
> Can we customise the TBIVM in this case (for the JVMTIThreadState_lock) to allow suspend checks - I would not expect this to be happening when VM locks are held.

Sorry that wasn't well thought out - we would need to pass this through all the mutex code to allow it to be specialized.

Do we still have a "suspension disabler" that would prevent the suspend from being processed by the mutex blocking?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1976885509

From stuefe at openjdk.org  Mon Mar  3 05:35:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 3 Mar 2025 05:35:58 GMT
Subject: RFR: 8350584: Check the usage of LOG_PLEASE
In-Reply-To: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com>
References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com>
Message-ID: <Nql2JE0KVGxNFuNfLud0_9-LsjfhNNDa3lNvbB0myz8=.aceae486-151d-4d0b-9715-f63c2de66c75@github.com>

On Tue, 25 Feb 2025 03:32:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Seen discussion in https://github.com/openjdk/jdk/pull/23290#issuecomment-2678001782. The LOG_PLEASE macro seems currently being defined are debugging leftovers that shouldn't have been committed. It's definition is typically
> commented or uncommented to provide some additional logging for some tests of interest.
> 
> This PR comment out the `#define LOG_PLEASE` same to other gtests. Change has been verified locally, test-fix only, no risk.

This is fine.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23764#pullrequestreview-2653096082

From stuefe at openjdk.org  Mon Mar  3 05:35:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 3 Mar 2025 05:35:59 GMT
Subject: RFR: 8350584: Check the usage of LOG_PLEASE
In-Reply-To: <RUVeWbvgt8PK4tp-bKAUtAdmp0dz4oRxxdtzmJM2ExA=.8b7c4453-1255-4264-b287-ad417bd075d8@github.com>
References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com>
 <PhhMEoMLsfoN60CPlUr8PrpkYCtxMDIzujXxZXrILLU=.ccc8918b-c94e-445a-8fcb-fa8bce7ba5a8@github.com>
 <RUVeWbvgt8PK4tp-bKAUtAdmp0dz4oRxxdtzmJM2ExA=.8b7c4453-1255-4264-b287-ad417bd075d8@github.com>
Message-ID: <5oNJrV4S46S1p7-f2pWmZq2-Hvv19sj0Uey4jZ4HiY4=.2cb6f03e-f6a2-437e-a87d-542c08fc0a8c@github.com>

On Tue, 25 Feb 2025 10:41:12 GMT, SendaoYan <syan at openjdk.org> wrote:

> Having debug logging enabled in some tests is not necessarily an issue that needs to be "fixed". You need to ask the person who enabled it why they did so.
> 
> If it is enabled in some tests then we do need to guard against redefinition incase it is globally enabled (and there is nothing wrong with that either).

That.

Yes, these are mine. I tend to introduce them when I think I may have to look at a failing gtest again, possibly on some weird platform. If people are bothered by it, we can remove the output, but I think they are still slightly useful in their current form. I never actually thought people would globally define the log.

Using UL logging may not work as intended since UL may not be available in some gtests.

While debug output is not bad, it's better to disable it by default, since we need to take care that the output does not overflow and get truncated by the jtreg runner.

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

PR Comment: https://git.openjdk.org/jdk/pull/23764#issuecomment-2693320728

From syan at openjdk.org  Mon Mar  3 07:52:00 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 3 Mar 2025 07:52:00 GMT
Subject: RFR: 8350584: Check the usage of LOG_PLEASE
In-Reply-To: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com>
References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com>
Message-ID: <tS4kKr5AuWcLsREsEeXIOtE0F8x1Ex8cnFzWKH-EJFM=.ec14a170-45b5-46d7-9941-4fd160770e93@github.com>

On Tue, 25 Feb 2025 03:32:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Seen discussion in https://github.com/openjdk/jdk/pull/23290#issuecomment-2678001782. The LOG_PLEASE macro seems currently being defined are debugging leftovers that shouldn't have been committed. It's definition is typically
> commented or uncommented to provide some additional logging for some tests of interest.
> 
> This PR comment out the `#define LOG_PLEASE` same to other gtests. Change has been verified locally, test-fix only, no risk.

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23764#issuecomment-2693532095

From syan at openjdk.org  Mon Mar  3 07:52:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 3 Mar 2025 07:52:01 GMT
Subject: Integrated: 8350584: Check the usage of LOG_PLEASE
In-Reply-To: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com>
References: <_ncoYOIlqlRXQZNDCMrRXd2AlVr-tlkeWVPbsTVHe2Q=.29ffd43b-003d-44e4-bc90-1d589fa9b0da@github.com>
Message-ID: <pBpZEu4nu_jdMod_wWRPGNN4rKzAcH9dpM3hAiSxqi0=.5d32e159-731d-49f4-b6f2-0c0275650dd4@github.com>

On Tue, 25 Feb 2025 03:32:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Seen discussion in https://github.com/openjdk/jdk/pull/23290#issuecomment-2678001782. The LOG_PLEASE macro seems currently being defined are debugging leftovers that shouldn't have been committed. It's definition is typically
> commented or uncommented to provide some additional logging for some tests of interest.
> 
> This PR comment out the `#define LOG_PLEASE` same to other gtests. Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: b054d24d
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b054d24df55a73bae70c784f6e75b3eb56d4be8b
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8350584: Check the usage of LOG_PLEASE

Reviewed-by: stuefe

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

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

From sgehwolf at openjdk.org  Mon Mar  3 07:52:59 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 3 Mar 2025 07:52:59 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
 <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
 <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
Message-ID: <G_wIU-Le8V4pijadumNrxaJbLz2S33YuAyiza5iobm4=.17171ebe-f85e-4795-af6f-445437c86c87@github.com>

On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> > OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
> 
> Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.

OK!

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2693536580

From jsjolen at openjdk.org  Mon Mar  3 10:10:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 3 Mar 2025 10:10:00 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag
In-Reply-To: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
Message-ID: <BtkfaYYX9jJSVlCDPIeP3hPeNrH8I2IPSoWsyNLrzNo=.8c5a6e1a-c6f9-4aa3-b3fd-0d8acde5c584@github.com>

On Tue, 25 Feb 2025 09:49:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
> Tests:
> linux-x64-debug, gtest:NMT* and runtime/NMT*

LGTM

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2653648133

From shade at openjdk.org  Mon Mar  3 10:18:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 3 Mar 2025 10:18:59 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging
In-Reply-To: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
Message-ID: <nXfVCAhQM0lLILh8MYEaOrYi9y2ghJtVFgAj2WuU8BU=.b860eb5a-8e83-47ee-a336-6224d1a3f48a@github.com>

On Fri, 28 Feb 2025 09:16:19 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
> 
> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
> 
> Here is example log output with the change:
> 
> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
> 
> 
> 
> ### Test
> - [x] Tire1
> - [x] Tire2

This looks useful to me, thanks. A lot of times I was scratching my head whether the long safepoint times were due to way too many runnable threads, or a single straggler thread.

Let's see if anyone objects :)

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23838#pullrequestreview-2653670063

From tschatzl at openjdk.org  Mon Mar  3 12:10:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 3 Mar 2025 12:10:57 GMT
Subject: RFR: 8350955: Fix repetitions of the word "the" in runtime component
 comments
Message-ID: <zxlkjqwJPeVuKUop_OnaaRp2mJVPekpGWmvYd2bikW4=.78b00f0b-a14e-421b-a53f-94fc3d29a667@github.com>

Hi all,

  please review this trivial change that fixes "the the" repetitions in the
runtime related sources.

If you think it's not worth fixing, I am okay with that and just retract the change.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8350955

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

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

From azafari at openjdk.org  Mon Mar  3 12:11:19 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 12:11:19 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <MR2dNWe_P5jFZnTOyTPAzsWYEpv0INX3nxPXXn30K8g=.245dd354-dc69-4ec9-85ac-2cccfa37d041@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <bd8Oe4BC5NT-VcrEjeQTtRn4KNH8slvrUmeGdI3xOiI=.ce329064-852f-49e7-90ac-a30e4034d6e7@github.com>
 <MR2dNWe_P5jFZnTOyTPAzsWYEpv0INX3nxPXXn30K8g=.245dd354-dc69-4ec9-85ac-2cccfa37d041@github.com>
Message-ID: <MMVkFjLvq_7AQs13h0yr_7zdDHGOWaB68Q_aVxyUQm8=.d42fe1f5-4f44-42ab-ae6c-9328e70e78c9@github.com>

On Thu, 27 Feb 2025 13:29:01 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> 2 questions:
>> 
>> 1st, I must be misunderstanding something here. Johan asked to change the API from:
>> 
>> `visit_committed_regions(ReservedMemoryRegion& committed_rgn)`
>> 
>> to
>> 
>> `visit_committed_regions(position start, size size)`
>> 
>> but I still see the old way.
>> 
>> 2nd, why are we asking for this change?
>
> We want to remove `ReservedMemoryRegion` in a follow up PR to this one. Another step is to remove the `CommittedMemoryRegion` class as well.

To be more specific, `ReservedMemoryRegion` structure/class will still remain in the code, but the `find_reserved_region(address, size_t)` will be removed. At least, in neither of my PRs it would be removed.
These structs are useful in encapsulating the info about the regions and have been used many times in the code.
Do we have any reason to remove them? 
Anyway, it is better to remove them in the related PRs, if there will be any.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1977368095

From azafari at openjdk.org  Mon Mar  3 12:11:42 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 12:11:42 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v3]
In-Reply-To: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
Message-ID: <-69oy_BLdbhNBOKJB4HqRvM7QVFIg3X5A8s0i5NZCH4=.9c3fc155-b8bc-4ced-86fd-2ac270ada816@github.com>

> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR.
> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR.
> 
> Tests:
> linux-x64-debug, gtest:NMT*, runtime/NMT

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  new test name, removed unnecessary code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23771/files
  - new: https://git.openjdk.org/jdk/pull/23771/files/50a75b22..680c2906

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

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

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

From azafari at openjdk.org  Mon Mar  3 12:11:42 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 12:11:42 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v2]
In-Reply-To: <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
Message-ID: <Tf3npv8lpu-ULeJgjm7V5vBEJO3QwdN-YaAR4VYspEQ=.a391533c-f601-4630-9732-921097eb2bd1@github.com>

On Thu, 27 Feb 2025 09:38:12 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR.
>> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR.
>> 
>> Tests:
>> linux-x64-debug, gtest:NMT*, runtime/NMT
>
> Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed extra whitespace.
>  - unit test added.

> It seems like the actual bug is in the summary diff accounting code and _not_ in the actual reservations, see comments. Is that correct?

By removing the unnecessary line of code, yes the bug is only in summary accounting.

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

PR Comment: https://git.openjdk.org/jdk/pull/23771#issuecomment-2694077236

From azafari at openjdk.org  Mon Mar  3 12:11:42 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 12:11:42 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v2]
In-Reply-To: <UqCZynU3EpRgra-V6L9XhHFT0g-GxRh23h9amtGim7Y=.c4545ef9-f6c7-490e-9446-4caf8acb183f@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
 <UqCZynU3EpRgra-V6L9XhHFT0g-GxRh23h9amtGim7Y=.c4545ef9-f6c7-490e-9446-4caf8acb183f@github.com>
Message-ID: <kjaPo2v_Vsw5HztmX_JmcF7NnW_XpgMaaQOFFD8fEZc=.f7b80476-2a6a-44ee-8a78-540a5368a7ef@github.com>

On Sun, 2 Mar 2025 20:12:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - removed extra whitespace.
>>  - unit test added.
>
> src/hotspot/share/nmt/vmatree.cpp line 80:
> 
>> 78:       MemTag tag = leqA_n->val().out.mem_tag();
>> 79:       stA.out.set_tag(tag);
>> 80:       LEQ_A.state.out.set_tag(tag);
> 
> Shouldn't `LEQ_A.state.out`'s tag already be `tag`? Is this line really necessary?

It's not. Removed.

> src/hotspot/share/nmt/vmatree.cpp line 210:
> 
>> 208: 
>> 209:   // Finally, we can register the new region [A, B)'s summary data.
>> 210:   MemTag tag_to_change = use_tag_inplace ? stA.out.mem_tag() : metadata.mem_tag;
> 
> Do we ever change the `stA.out.mem_tag()` ? Can't it always be `stA.out.mem_tag()`?

Yes, it is changed in line 79 above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1977351075
PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1977350774

From azafari at openjdk.org  Mon Mar  3 12:11:42 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 12:11:42 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v2]
In-Reply-To: <1miELHdDyoRgKM2A-0JWJpY_0y5PBudG75qjwgdJJrg=.7a172ae5-c230-42a7-949e-9dbb5a1f12f9@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
 <WjTuC-9gp_g7FaSEN7TU-BnF-uyUANzRc37hNk4D7ok=.de778777-dfd8-4b1e-b02c-6c00528e7b4d@github.com>
 <1miELHdDyoRgKM2A-0JWJpY_0y5PBudG75qjwgdJJrg=.7a172ae5-c230-42a7-949e-9dbb5a1f12f9@github.com>
Message-ID: <IdSmR25ZJla6U-E8uNBdTijD9UekiGlt7K7SJfJ9ywg=.d864acc8-0be3-489f-89a3-c4bc69e10513@github.com>

On Sun, 2 Mar 2025 20:16:36 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> test/hotspot/gtest/nmt/test_vmatree.cpp line 728:
>> 
>>> 726: }
>>> 727: 
>>> 728: TEST_VM_F(NMTVMATreeTest, CommitUseFlagInplace) {
>> 
>> Change this test to use `expect_equivalent_form`, see other usages to see what should look like. You can add multiple checks even, so that we get how the range changes over time.
>
> Is the bug actually in the summary accounting? If so, I'd like to see a better test name here that indicates that and *not* change this to `expect_equivalent_form` and so on.

New name chosen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1977356624

From jsjolen at openjdk.org  Mon Mar  3 12:23:53 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 3 Mar 2025 12:23:53 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v2]
In-Reply-To: <kjaPo2v_Vsw5HztmX_JmcF7NnW_XpgMaaQOFFD8fEZc=.f7b80476-2a6a-44ee-8a78-540a5368a7ef@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
 <UqCZynU3EpRgra-V6L9XhHFT0g-GxRh23h9amtGim7Y=.c4545ef9-f6c7-490e-9446-4caf8acb183f@github.com>
 <kjaPo2v_Vsw5HztmX_JmcF7NnW_XpgMaaQOFFD8fEZc=.f7b80476-2a6a-44ee-8a78-540a5368a7ef@github.com>
Message-ID: <5dmYIIH0Jlk137WdbxsMSUQjBn7kHQCrzsa8w3q9Wo0=.bab04e27-7778-40f2-a9f3-257c787a81eb@github.com>

On Mon, 3 Mar 2025 11:30:42 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/vmatree.cpp line 210:
>> 
>>> 208: 
>>> 209:   // Finally, we can register the new region [A, B)'s summary data.
>>> 210:   MemTag tag_to_change = use_tag_inplace ? stA.out.mem_tag() : metadata.mem_tag;
>> 
>> Do we ever change the `stA.out.mem_tag()` ? Can't it always be `stA.out.mem_tag()`?
>
> Yes, it is changed in line 79 above.

@afshin-zafari .

Right, but that depends on `use_tag_inplace` being true. So this says:

```c++
MemTag found_memtag; // Assume set
if (use_tag_inplace) {
  stA.mem_tag() =  found_memtag;
} else {
    stA.mem_tag() = metadata.mem_tag;
}
MemTag tag_to_change = use_tag_inplace ? stA.out.mem_tag() : metadata.mem_tag; 


Do you see what I'm saying? You can change the line to `MemTag tag_to_change = stA.out.mem_tag();`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1977426437

From azafari at openjdk.org  Mon Mar  3 13:07:26 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 13:07:26 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v4]
In-Reply-To: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
Message-ID: <RzzuH_2vlybLuEBqsFAGoud_XpjYXeehbI35vpizaRA=.4e740cf6-f615-405e-954d-a85316385d45@github.com>

> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR.
> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR.
> 
> Tests:
> linux-x64-debug, gtest:NMT*, runtime/NMT

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  out tag of the begin node (stA) is used for accounting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23771/files
  - new: https://git.openjdk.org/jdk/pull/23771/files/680c2906..070a91c3

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

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

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

From azafari at openjdk.org  Mon Mar  3 13:07:26 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 13:07:26 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v2]
In-Reply-To: <5dmYIIH0Jlk137WdbxsMSUQjBn7kHQCrzsa8w3q9Wo0=.bab04e27-7778-40f2-a9f3-257c787a81eb@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <dwGf83yh20PU-vHKVOXRgY7KJQhWivdtKHFvRvdsWp4=.07218df3-7bee-4008-b838-daa4b9a863a6@github.com>
 <UqCZynU3EpRgra-V6L9XhHFT0g-GxRh23h9amtGim7Y=.c4545ef9-f6c7-490e-9446-4caf8acb183f@github.com>
 <kjaPo2v_Vsw5HztmX_JmcF7NnW_XpgMaaQOFFD8fEZc=.f7b80476-2a6a-44ee-8a78-540a5368a7ef@github.com>
 <5dmYIIH0Jlk137WdbxsMSUQjBn7kHQCrzsa8w3q9Wo0=.bab04e27-7778-40f2-a9f3-257c787a81eb@github.com>
Message-ID: <BmO2I7EpM2ni5O3EurrO7ycmTZEBn9ogQSyroKhn82o=.bf4f3867-eee3-4da8-ab10-58011841da40@github.com>

On Mon, 3 Mar 2025 12:20:46 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Yes, it is changed in line 79 above.
>
> @afshin-zafari .
> 
> Right, but that depends on `use_tag_inplace` being true. So this says:
> 
> ```c++
> MemTag found_memtag; // Assume set
> if (use_tag_inplace) {
>   stA.mem_tag() =  found_memtag;
> } else {
>     stA.mem_tag() = metadata.mem_tag;
> }
> MemTag tag_to_change = use_tag_inplace ? stA.out.mem_tag() : metadata.mem_tag; 
> 
> 
> Do you see what I'm saying? You can change the line to `MemTag tag_to_change = stA.out.mem_tag();`.

OK. I got it.
Changed. Always `stA.out.mem_tag()` is used for accounting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23771#discussion_r1977484091

From jsjolen at openjdk.org  Mon Mar  3 14:30:58 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 3 Mar 2025 14:30:58 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v4]
In-Reply-To: <RzzuH_2vlybLuEBqsFAGoud_XpjYXeehbI35vpizaRA=.4e740cf6-f615-405e-954d-a85316385d45@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <RzzuH_2vlybLuEBqsFAGoud_XpjYXeehbI35vpizaRA=.4e740cf6-f615-405e-954d-a85316385d45@github.com>
Message-ID: <LHKHCQYIoZLHgMz-eLXvQ8QTvpKezdmwnX3-8NMuN2w=.d0160a46-3336-4d60-a6b4-2050a0b62775@github.com>

On Mon, 3 Mar 2025 13:07:26 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR.
>> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR.
>> 
>> Tests:
>> linux-x64-debug, gtest:NMT*, runtime/NMT
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   out tag of the begin node (stA) is used for accounting.

Thanks!

This LGTM.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23771#pullrequestreview-2654288267

From coleenp at openjdk.org  Mon Mar  3 15:01:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Mar 2025 15:01:04 GMT
Subject: RFR: 8350623: Fix -Wzero-as-null-pointer-constant warnings in nsk
 native test utilities
In-Reply-To: <lAPUJ05uTluh8AfK06g3D1MpgMpcbHCAAcLmAaymd_Y=.f483cfa5-332c-4c4b-b5bc-a9f3e21a7af6@github.com>
References: <lAPUJ05uTluh8AfK06g3D1MpgMpcbHCAAcLmAaymd_Y=.f483cfa5-332c-4c4b-b5bc-a9f3e21a7af6@github.com>
Message-ID: <Dkn876_6xdL9-Aui7jpmpS18IxHY1woS27YCrx6vyGA=.ef769e20-1878-4756-aa11-d17f7f0a5056@github.com>

On Wed, 26 Feb 2025 12:03:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove a use of literal zero as a null
> pointer constant.
> 
> Testing: mach5 tier1
> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
> verify the warnings associated with this code were removed.

Looks good plus trivial.

test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.cpp line 101:

> 99:     thread->status   = thread->procedure(thread->context);
> 100:     thread->finished = 1;
> 101: #ifdef windows

Lower case 'windows' ??  Not an issue for your change, but odd.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23797#pullrequestreview-2654383830
PR Review Comment: https://git.openjdk.org/jdk/pull/23797#discussion_r1977666497

From stuefe at openjdk.org  Mon Mar  3 15:02:03 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 3 Mar 2025 15:02:03 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v4]
In-Reply-To: <RzzuH_2vlybLuEBqsFAGoud_XpjYXeehbI35vpizaRA=.4e740cf6-f615-405e-954d-a85316385d45@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <RzzuH_2vlybLuEBqsFAGoud_XpjYXeehbI35vpizaRA=.4e740cf6-f615-405e-954d-a85316385d45@github.com>
Message-ID: <X5oev_pAlbOUNpXWMC0no2835JO-jRwcn7BA-B5OwrQ=.eff36efa-dcd1-4194-8353-cd1a1130a4b8@github.com>

On Mon, 3 Mar 2025 13:07:26 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR.
>> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR.
>> 
>> Tests:
>> linux-x64-debug, gtest:NMT*, runtime/NMT
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   out tag of the begin node (stA) is used for accounting.

Good

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23771#pullrequestreview-2654385315

From coleenp at openjdk.org  Mon Mar  3 15:02:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Mar 2025 15:02:53 GMT
Subject: RFR: 8350767: Fix -Wzero-as-null-pointer-constant warnings in nsk
 jni stress tests
In-Reply-To: <X8KClyxLSfj1FYUgdIClXCC3IloR0K3voayyy586BNg=.f04c7328-dc95-41aa-95e6-f49b0ad9fd03@github.com>
References: <X8KClyxLSfj1FYUgdIClXCC3IloR0K3voayyy586BNg=.f04c7328-dc95-41aa-95e6-f49b0ad9fd03@github.com>
Message-ID: <43DKDre4V4daHwqLgAMN-km7CMmUe6vw6GlCWlgo-no=.0b03b9f7-b62f-4c5d-ac8e-776a3a6798da@github.com>

On Wed, 26 Feb 2025 12:10:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove uses of literal zero as a null pointer
> constant in nsk jni stress tests.
> 
> Testing: mach5 tier1
> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
> verify the warnings associated with this code were removed.

Looks good (I don't believe test changes like these require 24 hour review perioid).  Also it's a trivial change.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23798#pullrequestreview-2654389578

From matsaave at openjdk.org  Mon Mar  3 15:05:53 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 3 Mar 2025 15:05:53 GMT
Subject: RFR: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled [v3]
In-Reply-To: <oLNZaTNQYF8kw7GbJFfgR77HptD-O981ilO2O5z5g84=.4a074e96-7284-4569-bb50-306fcfc7a9d8@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
 <oLNZaTNQYF8kw7GbJFfgR77HptD-O981ilO2O5z5g84=.4a074e96-7284-4569-bb50-306fcfc7a9d8@github.com>
Message-ID: <ZyjIldWV0L2tRlqVn4dL0bwDN-sXpvuGLo0pOH01osk=.219cffb0-5697-4b1f-b23b-94ec8664db7f@github.com>

On Sat, 1 Mar 2025 00:59:23 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled.
>> Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation:
>> 
>> 
>> [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
>> [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST
>> 
>> Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function.
>> 
>> Passed tiers 1 - 3 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comment

LGTM, thanks!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23546#pullrequestreview-2654397494

From azafari at openjdk.org  Mon Mar  3 15:43:26 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 15:43:26 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v5]
In-Reply-To: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
Message-ID: <C1prBwBBNPG5TWp2O8Yp7yV4wATnqRovRSM85JvTSsc=.105e588e-8836-4387-8f6b-588b6c82978e@github.com>

> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR.
> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR.
> 
> Tests:
> linux-x64-debug, gtest:NMT*, runtime/NMT

Afshin Zafari 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 remote-tracking branch 'origin/master' into _8350567_copy_tag_in_place
 - out tag of the begin node (stA) is used for accounting.
 - new test name, removed unnecessary code
 - removed extra whitespace.
 - unit test added.
 - 8350567: NMT: update VMATree::register_mapping to copy the existing tag of the region

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23771/files
  - new: https://git.openjdk.org/jdk/pull/23771/files/070a91c3..e2250990

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

  Stats: 25005 lines in 776 files changed: 9703 ins; 11967 del; 3335 mod
  Patch: https://git.openjdk.org/jdk/pull/23771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23771/head:pull/23771

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

From azafari at openjdk.org  Mon Mar  3 15:43:26 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 15:43:26 GMT
Subject: RFR: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region [v5]
In-Reply-To: <LHKHCQYIoZLHgMz-eLXvQ8QTvpKezdmwnX3-8NMuN2w=.d0160a46-3336-4d60-a6b4-2050a0b62775@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
 <RzzuH_2vlybLuEBqsFAGoud_XpjYXeehbI35vpizaRA=.4e740cf6-f615-405e-954d-a85316385d45@github.com>
 <LHKHCQYIoZLHgMz-eLXvQ8QTvpKezdmwnX3-8NMuN2w=.d0160a46-3336-4d60-a6b4-2050a0b62775@github.com>
Message-ID: <qCLAuD_cwMDj267H8p1MiSldtZxFgevy1EWb_nOcia4=.6ec7de16-4d88-4e29-91e3-73c58966c406@github.com>

On Mon, 3 Mar 2025 14:28:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari 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 remote-tracking branch 'origin/master' into _8350567_copy_tag_in_place
>>  - out tag of the begin node (stA) is used for accounting.
>>  - new test name, removed unnecessary code
>>  - removed extra whitespace.
>>  - unit test added.
>>  - 8350567: NMT: update VMATree::register_mapping to copy the existing tag of the region
>
> Thanks!
> 
> This LGTM.

Thank you @jdksjolen and @tstuefe for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23771#issuecomment-2694798130

From azafari at openjdk.org  Mon Mar  3 15:43:27 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Mar 2025 15:43:27 GMT
Subject: Integrated: 8350567: NMT: update VMATree::register_mapping to copy the
 existing tag of the region
In-Reply-To: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
References: <HAco45gjQLObxEAeq9vTLhsQaY8e_5Mm6xYQTWIqTOM=.e2c2910c-3e29-4ad5-8f7a-0ccabc64ff27@github.com>
Message-ID: <_wX-KbSbm5T2k_P37K_AlH713dsfhZAXSd8alPyFoN0=.9d28b710-d3f7-4c90-9170-fc39ed14b95d@github.com>

On Tue, 25 Feb 2025 10:01:17 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> When committing a sub-region (SR) in the middle of a reserved region (RR), we need to decide on the MemTag. To find the correct tag, we had to find the RR base and take the tag and use it for SR.
> With this PR, there will be no need to find the RR base and the tag of the previous region of SR can be copied to the SR.
> 
> Tests:
> linux-x64-debug, gtest:NMT*, runtime/NMT

This pull request has now been integrated.

Changeset: 4a51c61b
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a51c61b2cfa396dace2ca21d819b5f363c9b6b5
Stats:     17 lines in 2 files changed: 16 ins; 0 del; 1 mod

8350567: NMT: update VMATree::register_mapping to copy the existing tag of the region

Reviewed-by: jsjolen, stuefe

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

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

From kbarrett at openjdk.org  Mon Mar  3 15:57:07 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 3 Mar 2025 15:57:07 GMT
Subject: RFR: 8350623: Fix -Wzero-as-null-pointer-constant warnings in nsk
 native test utilities
In-Reply-To: <Dkn876_6xdL9-Aui7jpmpS18IxHY1woS27YCrx6vyGA=.ef769e20-1878-4756-aa11-d17f7f0a5056@github.com>
References: <lAPUJ05uTluh8AfK06g3D1MpgMpcbHCAAcLmAaymd_Y=.f483cfa5-332c-4c4b-b5bc-a9f3e21a7af6@github.com>
 <Dkn876_6xdL9-Aui7jpmpS18IxHY1woS27YCrx6vyGA=.ef769e20-1878-4756-aa11-d17f7f0a5056@github.com>
Message-ID: <h-KLtVhCGeOwRJkbtxnJfZtRQsiZMlWKAe69XY5rEOY=.172d8d20-2b13-493c-8d23-394f58336a5d@github.com>

On Mon, 3 Mar 2025 14:58:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this trivial change to remove a use of literal zero as a null
>> pointer constant.
>> 
>> Testing: mach5 tier1
>> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
>> verify the warnings associated with this code were removed.
>
> Looks good plus trivial.

Thanks for reviewing @coleenp

> test/hotspot/jtreg/vmTestbase/nsk/share/native/native_thread.cpp line 101:
> 
>> 99:     thread->status   = thread->procedure(thread->context);
>> 100:     thread->finished = 1;
>> 101: #ifdef windows
> 
> Lower case 'windows' ??  Not an issue for your change, but odd.

Yeah, it's a bit odd.  It's defined up at the top of the file, based on whether `_WIN32` is defined.  I've no
idea why `_WIN32` isn't just used instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/23797#issuecomment-2694835712
PR Review Comment: https://git.openjdk.org/jdk/pull/23797#discussion_r1977758693

From kbarrett at openjdk.org  Mon Mar  3 15:57:09 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 3 Mar 2025 15:57:09 GMT
Subject: Integrated: 8350623: Fix -Wzero-as-null-pointer-constant warnings in
 nsk native test utilities
In-Reply-To: <lAPUJ05uTluh8AfK06g3D1MpgMpcbHCAAcLmAaymd_Y=.f483cfa5-332c-4c4b-b5bc-a9f3e21a7af6@github.com>
References: <lAPUJ05uTluh8AfK06g3D1MpgMpcbHCAAcLmAaymd_Y=.f483cfa5-332c-4c4b-b5bc-a9f3e21a7af6@github.com>
Message-ID: <XrSLPZEuarR6mXcowbGiyjc5c8V16H4Hhv6pA13VdL4=.7c9ed022-22b7-400a-ad31-be7402d35421@github.com>

On Wed, 26 Feb 2025 12:03:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove a use of literal zero as a null
> pointer constant.
> 
> Testing: mach5 tier1
> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
> verify the warnings associated with this code were removed.

This pull request has now been integrated.

Changeset: 67dfdfa6
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67dfdfa6ea829fcd1ecac0df8211b591ad15f859
Stats:     7 lines in 2 files changed: 4 ins; 0 del; 3 mod

8350623: Fix -Wzero-as-null-pointer-constant warnings in nsk native test utilities

Reviewed-by: coleenp

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

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

From kbarrett at openjdk.org  Mon Mar  3 15:58:03 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 3 Mar 2025 15:58:03 GMT
Subject: RFR: 8350767: Fix -Wzero-as-null-pointer-constant warnings in nsk
 jni stress tests
In-Reply-To: <43DKDre4V4daHwqLgAMN-km7CMmUe6vw6GlCWlgo-no=.0b03b9f7-b62f-4c5d-ac8e-776a3a6798da@github.com>
References: <X8KClyxLSfj1FYUgdIClXCC3IloR0K3voayyy586BNg=.f04c7328-dc95-41aa-95e6-f49b0ad9fd03@github.com>
 <43DKDre4V4daHwqLgAMN-km7CMmUe6vw6GlCWlgo-no=.0b03b9f7-b62f-4c5d-ac8e-776a3a6798da@github.com>
Message-ID: <Kj5bpXrR2EhByXYV77KYmW_gU61Pv9xuok8DwMes4q0=.cc01d2fc-d2f1-4654-8ce5-783a47c0a40c@github.com>

On Mon, 3 Mar 2025 15:00:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to remove uses of literal zero as a null pointer
>> constant in nsk jni stress tests.
>> 
>> Testing: mach5 tier1
>> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
>> verify the warnings associated with this code were removed.
>
> Looks good (I don't believe test changes like these require 24 hour review perioid).  Also it's a trivial change.

Thanks for reviewing @coleenp

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

PR Comment: https://git.openjdk.org/jdk/pull/23798#issuecomment-2694839342

From kbarrett at openjdk.org  Mon Mar  3 15:58:04 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 3 Mar 2025 15:58:04 GMT
Subject: Integrated: 8350767: Fix -Wzero-as-null-pointer-constant warnings in
 nsk jni stress tests
In-Reply-To: <X8KClyxLSfj1FYUgdIClXCC3IloR0K3voayyy586BNg=.f04c7328-dc95-41aa-95e6-f49b0ad9fd03@github.com>
References: <X8KClyxLSfj1FYUgdIClXCC3IloR0K3voayyy586BNg=.f04c7328-dc95-41aa-95e6-f49b0ad9fd03@github.com>
Message-ID: <TtvQ3Bhmp7gnxmS-9WlFWyrZFHrHq9U8b9lhoQauSwU=.b1d9627a-1586-4d1c-8179-eda2cf1ac1b4@github.com>

On Wed, 26 Feb 2025 12:10:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove uses of literal zero as a null pointer
> constant in nsk jni stress tests.
> 
> Testing: mach5 tier1
> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
> verify the warnings associated with this code were removed.

This pull request has now been integrated.

Changeset: c988d7d6
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c988d7d6476807bf71a977dc771017915b708ca3
Stats:     20 lines in 5 files changed: 0 ins; 0 del; 20 mod

8350767: Fix -Wzero-as-null-pointer-constant warnings in nsk jni stress tests

Reviewed-by: coleenp

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

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

From coleenp at openjdk.org  Mon Mar  3 16:03:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Mar 2025 16:03:01 GMT
Subject: RFR: 8350955: Fix repetitions of the word "the" in runtime
 component comments
In-Reply-To: <zxlkjqwJPeVuKUop_OnaaRp2mJVPekpGWmvYd2bikW4=.78b00f0b-a14e-421b-a53f-94fc3d29a667@github.com>
References: <zxlkjqwJPeVuKUop_OnaaRp2mJVPekpGWmvYd2bikW4=.78b00f0b-a14e-421b-a53f-94fc3d29a667@github.com>
Message-ID: <SMgEBPKPy7N_ZJqb-bFCT9SztV-vgQdpbjUg6b5-PCs=.c1eea67e-f77d-4c37-a1df-403fb0a1dc01@github.com>

On Mon, 3 Mar 2025 11:07:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial change that fixes "the the" repetitions in the
> runtime related sources.
> 
> If you think it's not worth fixing, I am okay with that and just retract the change.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good plus trivial and I don't think it'll cause a conflict for PR https://github.com/openjdk/jdk/pull/23421

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23857#pullrequestreview-2654563065

From ccheung at openjdk.org  Mon Mar  3 16:38:31 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 3 Mar 2025 16:38:31 GMT
Subject: RFR: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled [v4]
In-Reply-To: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
Message-ID: <Ea727g1oYtLuWaiE_ciLhpjDMyZflZFhZD-OFQAAE7I=.c5c1a3aa-8aaf-4136-b3b9-83f22d3548a2@github.com>

> This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled.
> Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation:
> 
> 
> [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
> [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST
> 
> Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function.
> 
> Passed tiers 1 - 3 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  revert changes in aotArtifactFinder.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23546/files
  - new: https://git.openjdk.org/jdk/pull/23546/files/fdc3836d..f2bdcfab

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

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

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

From ccheung at openjdk.org  Mon Mar  3 16:38:31 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 3 Mar 2025 16:38:31 GMT
Subject: RFR: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled [v4]
In-Reply-To: <4PR8ziZrn7yRPiolUarpUsKKY80v_kdA9Q09mc89NyY=.5084c276-675e-4c60-a1d7-eb2397b122bd@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
 <pFHeLghBAC2j2_TZs6-FnrGQqoyg99qByXIupZvxvqU=.0859f4f4-a38b-4d7f-b6c9-8887e0acf0dc@github.com>
 <kV25ydIvYqE_Q4wwbWgbguFYoAXHNsmLEs6aH-dtsiE=.39f2ee05-308e-4159-8c65-1dd2c368eb17@github.com>
 <LOHsrEp1kTEmRqgtVcwBu7ko3v7owBP35NCHHI-_i3k=.d182ca1f-2c69-4207-a08f-a1023df32beb@github.com>
 <Pbut3uf76u_7MwNZUxanvAj2Jhgb45a6HzFOtpLIhRc=.058c7c7d-0a90-4165-bf58-160a71e51ff7@github.com>
 <4PR8ziZrn7yRPiolUarpUsKKY80v_kdA9Q09mc89NyY=.5084c276-675e-4c60-a1d7-eb2397b122bd@github.com>
Message-ID: <UbMe51P5hMe-s7X3BBbyhYISaoYyNDrgq3su0hNHUiI=.60eb4180-1a1e-4bd4-bf6e-4c53f39cfeb8@github.com>

On Sat, 1 Mar 2025 04:40:46 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I added back the `CDSConfig::is_initing_classes_at_dump_time()` function and reverted most of previous changes.
>
> The three changes in aotArtifactFinder.cpp should also be reverted.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23546#discussion_r1977824902

From shade at openjdk.org  Mon Mar  3 16:45:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 3 Mar 2025 16:45:18 GMT
Subject: RFR: 8348829: Remove ObjectMonitor perf counters [v2]
In-Reply-To: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
References: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
Message-ID: <Wrj8hq74Nb285CwGZYfU4GN4brnUZpBOM40s5nHLaE8=.f9ed8c61-8eac-4a8c-aed2-dfffd24d8467@github.com>

> See bug for more discussion. I believe these counters are useless and come with more trouble than their worth.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8348829-remove-om-counters
 - Counters removal

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

Changes: https://git.openjdk.org/jdk/pull/23326/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23326&range=01
  Stats: 118 lines in 4 files changed: 0 ins; 118 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23326/head:pull/23326

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

From tschatzl at openjdk.org  Mon Mar  3 16:55:05 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 3 Mar 2025 16:55:05 GMT
Subject: RFR: 8350955: Fix repetitions of the word "the" in runtime
 component comments
In-Reply-To: <SMgEBPKPy7N_ZJqb-bFCT9SztV-vgQdpbjUg6b5-PCs=.c1eea67e-f77d-4c37-a1df-403fb0a1dc01@github.com>
References: <zxlkjqwJPeVuKUop_OnaaRp2mJVPekpGWmvYd2bikW4=.78b00f0b-a14e-421b-a53f-94fc3d29a667@github.com>
 <SMgEBPKPy7N_ZJqb-bFCT9SztV-vgQdpbjUg6b5-PCs=.c1eea67e-f77d-4c37-a1df-403fb0a1dc01@github.com>
Message-ID: <zK9oosyLOTTLDsWGu9vuEbwSpngDgsui3KRaZwL12Ms=.a81befea-7be2-4c16-af38-7deda0388a85@github.com>

On Mon, 3 Mar 2025 16:00:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial change that fixes "the the" repetitions in the
>> runtime related sources.
>> 
>> If you think it's not worth fixing, I am okay with that and just retract the change.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Looks good plus trivial and I don't think it'll cause a conflict for PR https://github.com/openjdk/jdk/pull/23421

Does not look to me either a problem for PR https://github.com/openjdk/jdk/pull/23421. Will push. Thanks @coleenp !

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

PR Comment: https://git.openjdk.org/jdk/pull/23857#issuecomment-2694995735

From tschatzl at openjdk.org  Mon Mar  3 16:55:06 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 3 Mar 2025 16:55:06 GMT
Subject: Integrated: 8350955: Fix repetitions of the word "the" in runtime
 component comments
In-Reply-To: <zxlkjqwJPeVuKUop_OnaaRp2mJVPekpGWmvYd2bikW4=.78b00f0b-a14e-421b-a53f-94fc3d29a667@github.com>
References: <zxlkjqwJPeVuKUop_OnaaRp2mJVPekpGWmvYd2bikW4=.78b00f0b-a14e-421b-a53f-94fc3d29a667@github.com>
Message-ID: <j1Gk522BZWBSRl504kWwGXM46Sbx1GTOaOwqonCSwYI=.6e0ea20c-17ed-4b9b-bebd-c38f66fc7cca@github.com>

On Mon, 3 Mar 2025 11:07:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial change that fixes "the the" repetitions in the
> runtime related sources.
> 
> If you think it's not worth fixing, I am okay with that and just retract the change.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 3602c8cf
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3602c8cfd805d2e5ae07685145b91bf2c20e255a
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8350955: Fix repetitions of the word "the" in runtime component comments

Reviewed-by: coleenp

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

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

From coleenp at openjdk.org  Mon Mar  3 18:39:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Mar 2025 18:39:56 GMT
Subject: RFR: 8348829: Remove ObjectMonitor perf counters [v2]
In-Reply-To: <Wrj8hq74Nb285CwGZYfU4GN4brnUZpBOM40s5nHLaE8=.f9ed8c61-8eac-4a8c-aed2-dfffd24d8467@github.com>
References: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
 <Wrj8hq74Nb285CwGZYfU4GN4brnUZpBOM40s5nHLaE8=.f9ed8c61-8eac-4a8c-aed2-dfffd24d8467@github.com>
Message-ID: <_gHfS4Ozd22h-ct29E8UFkeYNsBCq9qPUqkY27iUTFI=.bfb0b7eb-8732-41ab-85d6-c4b400cb052a@github.com>

On Mon, 3 Mar 2025 16:45:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for more discussion. I believe these counters are useless and come with more trouble than their worth.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8348829-remove-om-counters
>  - Counters removal

Looks good.  You might need a remerge after PR https://github.com/openjdk/jdk/pull/23421 once the CSR is approved.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23326#pullrequestreview-2654938353

From ccheung at openjdk.org  Mon Mar  3 18:52:06 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 3 Mar 2025 18:52:06 GMT
Subject: Integrated: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled
In-Reply-To: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
Message-ID: <CzEO1wS0JyLpEDaKXeTuKzKpKmT1mB2-Qw17ioV-aOs=.2ffb3724-64f0-4180-aed9-b0def791d5a4@github.com>

On Tue, 11 Feb 2025 00:25:39 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This changeset fixes a crash during AOT cache creation when `AOTInvokeDynamicLinking` is disabled.
> Changes in `cdsHeapVerifier.cpp` is required to avoid error such as the following during AOT cache creation:
> 
> 
> [4.156s][warning][cds,heap] Archive heap points to a static field that may hold a different value at runtime:
> [4.156s][warning][cds,heap] Field: java/util/Collections::EMPTY_LIST
> 
> Per Ioi's suggestions, added the `CDSConfig::is_dumping_method_handles()` so that most of the calls to `CDSConfig::is_dumping_aot_linked_classes()` and `CDSConfig::is_dumping_invokedynamic()` could be replaced with the new function.
> 
> Passed tiers 1 - 3 testing.

This pull request has now been integrated.

Changeset: c4b516df
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4b516dfe7c5a5fddd4d9c97a21f5f36bf845646
Stats:     58 lines in 17 files changed: 24 ins; 10 del; 24 mod

8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled

Co-authored-by: Ioi Lam <iklam at openjdk.org>
Reviewed-by: iklam, matsaave

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

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

From ccheung at openjdk.org  Mon Mar  3 18:52:05 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 3 Mar 2025 18:52:05 GMT
Subject: RFR: 8348322: AOT cache creation crashes with
 "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking
 is disabled [v4]
In-Reply-To: <aazK34ztQrAMoOYz8pfqLWjLpTMGgLd8JdRISu3dFRA=.f797530a-6e03-4e60-8753-b50e6f4a1b79@github.com>
References: <zu-S8zqGIs8TD8oxZDjj7oUQgU9m_3INziAW7KSk87c=.d2c0dd7a-c92d-4877-b4a0-6e38dbb0c2c4@github.com>
 <Ea727g1oYtLuWaiE_ciLhpjDMyZflZFhZD-OFQAAE7I=.c5c1a3aa-8aaf-4136-b3b9-83f22d3548a2@github.com>
 <aazK34ztQrAMoOYz8pfqLWjLpTMGgLd8JdRISu3dFRA=.f797530a-6e03-4e60-8753-b50e6f4a1b79@github.com>
Message-ID: <JqKT9uWigcFxN2cZBLGegcY--XXc-BEfsPs96F02Xwc=.43f2395b-bf34-4fc2-a40d-60da79990344@github.com>

On Mon, 3 Mar 2025 17:19:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert changes in aotArtifactFinder.cpp
>
> LGTM!

@iklam @matias9927 Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23546#issuecomment-2695265677

From coleenp at openjdk.org  Mon Mar  3 19:39:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Mar 2025 19:39:06 GMT
Subject: RFR: 8350974: The os_cpu VM_STRUCTS, VM_TYPES,
 etc have no declarations and should be removed
In-Reply-To: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
References: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
Message-ID: <xqQjsBhcBUzcxljbG0kuHwrm-j7S_8N4GdJeutjrUlU=.f84bbc62-ad71-4084-bc17-2a828824a038@github.com>

On Mon, 3 Mar 2025 13:18:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove unused SA os_cpu declarations and files.
> Tested with serviceability/sa tests locally.

I didn't see email for this PR (?)

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

PR Comment: https://git.openjdk.org/jdk/pull/23863#issuecomment-2695363460

From gziemski at openjdk.org  Mon Mar  3 20:22:14 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 3 Mar 2025 20:22:14 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
Message-ID: <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>

On Fri, 28 Feb 2025 13:55:30 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style, some cleanup, VMT and regionsTree circular dep resolved

src/hotspot/share/nmt/regionsTree.cpp line 28:

> 26: VMATree::SummaryDiff RegionsTree::commit_region(address addr, size_t size, const NativeCallStack& stack) {
> 27:   return commit_mapping((VMATree::position)addr, size, make_region_data(stack, mtNone), /*use tag inplace*/ true);
> 28: }

`RegionsTree::commit_region` is called by 

 ```
 static inline void record_virtual_memory_reserve_and_commit(void* addr, size_t size,
    const NativeCallStack& stack, MemTag mem_tag = mtNone) {


which has mem_tag, so we could in theory use it and pass it down? Then we could avoid the complicated "use_tag_inplace" parameter handling?

Not sure if this is possible in all cases. Is that why we have the need for "use_tag_inplace"?

src/hotspot/share/nmt/regionsTree.cpp line 32:

> 30: VMATree::SummaryDiff RegionsTree::uncommit_region(address addr, size_t size) {
> 31:   return uncommit_mapping((VMATree::position)addr, size, make_region_data(NativeCallStack::empty_stack(), mtNone));
> 32: }

Would it be helpful here if we were to add a new tag, that would mark this uncommitted region somehow different than mtNone (to mark it that it used to be used, but now it's not, which is different from never used region)?

test/hotspot/gtest/nmt/test_regions_tree.cpp line 72:

> 70:   EXPECT_EQ(rmr.base(), (address)1400);
> 71:   rmr = rt.find_reserved_region((address)1005);
> 72:   EXPECT_EQ(rmr.base(), (address)1000);

When I do:

  rmr = rt.find_reserved_region((address)999);

I get back ReservedMemoryRegion with base == 1, I am not 100% sure what I was expecting - probably 0, but not 1.

test/hotspot/gtest/nmt/test_regions_tree.cpp line 98:

> 96:   rt.reserve_mapping(1400, 50, rd);
> 97: 
> 98:   rt.commit_region((address)1010, 5UL, ncs);

What would, what should happen if we repeat the same reserve_mapping?

rt.commit_region((address)1010, 5UL, ncs);
rt.commit_region((address)1010, 5UL, ncs);

Are/should we be allowed to do this?

test/hotspot/gtest/nmt/test_regions_tree.cpp line 102:

> 100:   rt.commit_region((address)1030, 5UL, ncs);
> 101:   rt.commit_region((address)1040, 5UL, ncs);
> 102:   ReservedMemoryRegion rmr((address)1000, 50);

I would add something like:

  rt.commit_region((address)1500, 5UL, ncs); // should not be counted

that should not be counted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1977880730
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1977894025
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1978113833
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1978138735
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1978124450

From kvn at openjdk.org  Mon Mar  3 20:41:58 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 3 Mar 2025 20:41:58 GMT
Subject: RFR: 8350974: The os_cpu VM_STRUCTS, VM_TYPES,
 etc have no declarations and should be removed
In-Reply-To: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
References: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
Message-ID: <RLv4u0zzgOI48ArXoAXC_FFouyfmhpzDjHh-PxlHzGo=.6470fb06-9eba-44ca-b7c8-a010bb748395@github.com>

On Mon, 3 Mar 2025 13:18:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove unused SA os_cpu declarations and files.
> Tested with serviceability/sa tests locally.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23863#pullrequestreview-2655238174

From kvn at openjdk.org  Mon Mar  3 20:41:59 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 3 Mar 2025 20:41:59 GMT
Subject: RFR: 8350974: The os_cpu VM_STRUCTS, VM_TYPES,
 etc have no declarations and should be removed
In-Reply-To: <xqQjsBhcBUzcxljbG0kuHwrm-j7S_8N4GdJeutjrUlU=.f84bbc62-ad71-4084-bc17-2a828824a038@github.com>
References: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
 <xqQjsBhcBUzcxljbG0kuHwrm-j7S_8N4GdJeutjrUlU=.f84bbc62-ad71-4084-bc17-2a828824a038@github.com>
Message-ID: <21D-6WNhPcIB44aKkRy9FKMtoIcOIz2MF7Wwdz-Vvm8=.1c417e29-5bb4-4dc3-93f6-556888d9dc10@github.com>

On Mon, 3 Mar 2025 19:36:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I didn't see email for this PR (?)

Me too. But your comment generated e-mail.

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

PR Comment: https://git.openjdk.org/jdk/pull/23863#issuecomment-2695483439

From coleenp at openjdk.org  Mon Mar  3 20:56:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Mar 2025 20:56:51 GMT
Subject: RFR: 8350974: The os_cpu VM_STRUCTS, VM_TYPES,
 etc have no declarations and should be removed
In-Reply-To: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
References: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
Message-ID: <4MRmeTGfqm8zu54XnSq_Hp5HcVhp1tMBwaAqI7GEmpc=.2fd96509-a4e2-4d23-b3c0-fe8c342c9a25@github.com>

On Mon, 3 Mar 2025 13:18:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove unused SA os_cpu declarations and files.
> Tested with serviceability/sa tests locally.

Thanks Vladimir.  I guess the email bot for hotspot-runtime was down this morning.

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

PR Comment: https://git.openjdk.org/jdk/pull/23863#issuecomment-2695512618

From iklam at openjdk.org  Mon Mar  3 21:30:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 3 Mar 2025 21:30:31 GMT
Subject: RFR: 8351082: Remove dead code for estimating CDS archive size
Message-ID: <PAoDJaEFrQq4RzNHSvN1t2KCAZ643AYwcjEBMkctO-8=.c9606f76-1727-4978-9117-b24ff5bcd04e@github.com>

Please review this trivial changeset that removes dead code that are no longer called after [JDK-8340416](https://bugs.openjdk.org/browse/JDK-8340416) "Remove ArchiveBuilder::estimate_archive_size()"

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

Commit messages:
 - 8351082: Remove dead code for estimating CDS archive size

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

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

From ccheung at openjdk.org  Mon Mar  3 21:39:56 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 3 Mar 2025 21:39:56 GMT
Subject: RFR: 8351082: Remove dead code for estimating CDS archive size
In-Reply-To: <PAoDJaEFrQq4RzNHSvN1t2KCAZ643AYwcjEBMkctO-8=.c9606f76-1727-4978-9117-b24ff5bcd04e@github.com>
References: <PAoDJaEFrQq4RzNHSvN1t2KCAZ643AYwcjEBMkctO-8=.c9606f76-1727-4978-9117-b24ff5bcd04e@github.com>
Message-ID: <6MYhpj1DB66EW5dLop23HsoaC9NpPryICRxVaxJpD54=.4d4ced4d-0fb5-4add-9f83-5463e30aa7ac@github.com>

On Mon, 3 Mar 2025 21:25:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial changeset that removes dead code that are no longer called after [JDK-8340416](https://bugs.openjdk.org/browse/JDK-8340416) "Remove ArchiveBuilder::estimate_archive_size()"

Looks good and I think this is a trivial fix.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23874#pullrequestreview-2655403597

From iklam at openjdk.org  Mon Mar  3 21:55:35 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 3 Mar 2025 21:55:35 GMT
Subject: RFR: 8351087: Combine scratch object tables in heapShared.cpp
Message-ID: <KAg3bC-8d4wSkg_HBn5nlrzBnrsKrV75fALagp5MCMk=.4dc5933e-525e-4c8d-abc2-ad121e37c30e@github.com>

Please review this trivial change. The two tables `_scratch_java_mirror_table` and `_scratch_references_table` are always disjoint. So we can simply combine them into a single table.

I am running tiers 1-5 for sanity sake.

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

Commit messages:
 - 8351087: Combine scratch object tables in heapShared.cpp

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

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

From ccheung at openjdk.org  Mon Mar  3 22:44:03 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 3 Mar 2025 22:44:03 GMT
Subject: RFR: 8351087: Combine scratch object tables in heapShared.cpp
In-Reply-To: <KAg3bC-8d4wSkg_HBn5nlrzBnrsKrV75fALagp5MCMk=.4dc5933e-525e-4c8d-abc2-ad121e37c30e@github.com>
References: <KAg3bC-8d4wSkg_HBn5nlrzBnrsKrV75fALagp5MCMk=.4dc5933e-525e-4c8d-abc2-ad121e37c30e@github.com>
Message-ID: <7_M_0ofVLp-aKFONGkFoCwQ1AueZYG_739OqI9oBUIw=.8f61aabb-0ff2-4fd5-ac49-9ed2a61a1f4c@github.com>

On Mon, 3 Mar 2025 21:50:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change. The two tables `_scratch_java_mirror_table` and `_scratch_references_table` are always disjoint. So we can simply combine them into a single table.
> 
> I am running tiers 1-5 for sanity sake.

LGTM

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23876#pullrequestreview-2655514511

From pchilanomate at openjdk.org  Tue Mar  4 00:49:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Mar 2025 00:49:53 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v4]
In-Reply-To: <oloAmS2y0tCsZtUv5kkaEGOOJZqw7FYhfqllwpP36Go=.afb5ad6c-49ac-4481-999d-4219a19aebfa@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
 <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com>
 <lKSu4UoGBLaWqEQbM2lJ0ctU5sDPZNkZtFfVNSJdwXs=.5f5a530f-f4f7-4715-a109-c913d38ad373@github.com>
 <x9aEMsQnMrC5ikLH-pbRzGF6EtkkAXppinbZIswVydI=.2d0d18d8-3af2-4f84-928f-95a384f846c7@github.com>
 <FpigHhXOb9nISzF_4EqAR5fzM6pUhVtpTyz7fXqd7_A=.13e96a32-e426-4ee2-8401-7337ca34367c@github.com>
 <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com>
 <iv39Wpp0MFwwesm5NI3ZvZD-xDnFyk4kZMpd19EZ30w=.b0b26989-7499-4b70-97ae-97e19138fe89@github.com>
 <WPY1X633YLLzKWRGX4RJma0CF983CGb1bSMrMs815jM=.084998ec-5bd2-4df5-8948-2161b4c6dd92@github.com>
 <azWxxjE8kLgJpSAiU4SAOk_E4ggzuN_rdoUHxbKHpE4=.275aa5f2-e7e7-4b6e-ad28-a3f34613b1e2@github.com>
 <DTJzFg5YGxLmof32AHTbpGnbIqUO_ygljkHGzhi0pKY=.c68129f6-dbab-4be9-b286-f5d892be60e6@github.com>
 <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x
 YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com>
 <ATSNFuB3otIkeyutW0m0RZHb_OA6BQPxgVanqPUHcAk=.ea8402a7-7058-4edc-aff8-0d6e48a4cedf@github.com>
 <ghaunIfZWap8c9LPz8jpYA_8KFTUhMkDZ1gkwD8kM2E=.cea3a66a-cb87-4464-a3b3-c5a9110fc75b@github.com>
 <tfNnOivL70wmw5IJ0catb58ef4ssrcmeztdgq_H525k=.432a5a11-afd1-4c6f-b24e-297e912ecb4d@github.com>
 <cZf3RuYW5CuMeRXOiJcepc70WK0eY5DITnZh1Elx4mM=.1a7e9d1d-b4a7-4cbb-b6a2-47b21f7aea52@github.com>
 <Bctrj8H3ZpTmh4JxhPpbEkG5m18Qa0roptqVW9czRKQ=.12d8658b-891c-44f9-8717-454dbecd8927@github.com>
 <uUzETr66Gr6wUUB54oHOJJcjemTcKgLFEwB-AdPp1pg=.5209349d-4fe7-48fa-9459-9f3a4555ff16@github.com>
 <RyyM64wPq5iN-sAEvt6SZidNvW51J4HqVzcTG7bNcwY=.56c40bb7-2974-4e00-9b01-3a99041edbff@github.com>
 <x-bxlwRSaJZdwXbU9zsYvgooLlAu3DX5Cj8kao1G6S0=.17f24dfe-94ef-4738-889d-2daa00e5725b@github.com>
 <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
 <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@
 github.com>
 <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com>
 <oloAmS2y0tCsZtUv5kkaEGOOJZqw7FYhfqllwpP36Go=.afb5ad6c-49ac-4481-999d-4219a19aebfa@github.com>
Message-ID: <NMCEunpOL82cZ-X-J6io4GPQmYBYFIUAFpXkFvZ4CnM=.dc1dfd78-6c00-466e-95b9-c7832d1eb077@github.com>

On Mon, 3 Mar 2025 05:10:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sorry that wasn't well thought out - we would need to pass this through all the mutex code to allow it to be specialized.
>> 
>> Do we still have a "suspension disabler" that would prevent the suspend from being processed by the mutex blocking?
>
> For use in ` JvmtiExport::at_single_stepping_point`.

> Do we still have a "suspension disabler" that would prevent the suspend from being processed by the mutex blocking?
>
We have `JavaThread::_is_disable_suspend` for JVMTI, but that only makes the target ignore the `ThreadSelfSuspensionHandshake` (second part of the suspend mechanism), it doesn't prevent the `SuspendThreadHandshake` (first part) from being executed. The suspender considers the target as suspended after the first handshake is done. (Seems this `_is_disable_suspend` should have prevented the first part instead but I'm guessing it wasn't as straightforward without introducing deadlocks). But also note we have the same issue for other events so we need a general solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1978435430

From dholmes at openjdk.org  Tue Mar  4 01:40:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 01:40:52 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v4]
In-Reply-To: <NMCEunpOL82cZ-X-J6io4GPQmYBYFIUAFpXkFvZ4CnM=.dc1dfd78-6c00-466e-95b9-c7832d1eb077@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
 <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com>
 <lKSu4UoGBLaWqEQbM2lJ0ctU5sDPZNkZtFfVNSJdwXs=.5f5a530f-f4f7-4715-a109-c913d38ad373@github.com>
 <x9aEMsQnMrC5ikLH-pbRzGF6EtkkAXppinbZIswVydI=.2d0d18d8-3af2-4f84-928f-95a384f846c7@github.com>
 <FpigHhXOb9nISzF_4EqAR5fzM6pUhVtpTyz7fXqd7_A=.13e96a32-e426-4ee2-8401-7337ca34367c@github.com>
 <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com>
 <iv39Wpp0MFwwesm5NI3ZvZD-xDnFyk4kZMpd19EZ30w=.b0b26989-7499-4b70-97ae-97e19138fe89@github.com>
 <WPY1X633YLLzKWRGX4RJma0CF983CGb1bSMrMs815jM=.084998ec-5bd2-4df5-8948-2161b4c6dd92@github.com>
 <azWxxjE8kLgJpSAiU4SAOk_E4ggzuN_rdoUHxbKHpE4=.275aa5f2-e7e7-4b6e-ad28-a3f34613b1e2@github.com>
 <DTJzFg5YGxLmof32AHTbpGnbIqUO_ygljkHGzhi0pKY=.c68129f6-dbab-4be9-b286-f5d892be60e6@github.com>
 <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x
 YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com>
 <ATSNFuB3otIkeyutW0m0RZHb_OA6BQPxgVanqPUHcAk=.ea8402a7-7058-4edc-aff8-0d6e48a4cedf@github.com>
 <ghaunIfZWap8c9LPz8jpYA_8KFTUhMkDZ1gkwD8kM2E=.cea3a66a-cb87-4464-a3b3-c5a9110fc75b@github.com>
 <tfNnOivL70wmw5IJ0catb58ef4ssrcmeztdgq_H525k=.432a5a11-afd1-4c6f-b24e-297e912ecb4d@github.com>
 <cZf3RuYW5CuMeRXOiJcepc70WK0eY5DITnZh1Elx4mM=.1a7e9d1d-b4a7-4cbb-b6a2-47b21f7aea52@github.com>
 <Bctrj8H3ZpTmh4JxhPpbEkG5m18Qa0roptqVW9czRKQ=.12d8658b-891c-44f9-8717-454dbecd8927@github.com>
 <uUzETr66Gr6wUUB54oHOJJcjemTcKgLFEwB-AdPp1pg=.5209349d-4fe7-48fa-9459-9f3a4555ff16@github.com>
 <RyyM64wPq5iN-sAEvt6SZidNvW51J4HqVzcTG7bNcwY=.56c40bb7-2974-4e00-9b01-3a99041edbff@github.com>
 <x-bxlwRSaJZdwXbU9zsYvgooLlAu3DX5Cj8kao1G6S0=.17f24dfe-94ef-4738-889d-2daa00e5725b@github.com>
 <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
 <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@
 github.com>
 <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com>
 <oloAmS2y0tCsZtUv5kkaEGOOJZqw7FYhfqllwpP36Go=.afb5ad6c-49ac-4481-999d-4219a19aebfa@github.com>
 <NMCEunpOL82cZ-X-J6io4GPQmYBYFIUAFpXkFvZ4CnM=.dc1dfd78-6c00-466e-95b9-c7832d1eb077@github.com>
Message-ID: <quOtN5QjPbF6HTKH8qcsO5McKDxh5meIlmXnPcHhPqc=.f50dd161-025f-44ef-ba30-a7a61d6c312e@github.com>

On Tue, 4 Mar 2025 00:46:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> For use in ` JvmtiExport::at_single_stepping_point`.
>
>> Do we still have a "suspension disabler" that would prevent the suspend from being processed by the mutex blocking?
>>
> We have `JavaThread::_is_disable_suspend` for JVMTI, but that only makes the target ignore the `ThreadSelfSuspensionHandshake` (second part of the suspend mechanism), it doesn't prevent the `SuspendThreadHandshake` (first part) from being executed. The suspender considers the target as suspended after the first handshake is done. (Seems this `_is_disable_suspend` should have prevented the first part instead but I'm guessing it wasn't as straightforward without introducing deadlocks). But also note we have the same issue for other events so we need a general solution.

Let me see if I have the sequence of events correct:
- we have a thread leaving Java to enter the VM, in this case to post a single-step event, which is not suspended
- when trying to acquire the JvmtiThreadState_lock the thread blocks and becomes handshake/safepoint-safe and is then suspended
- the thread acquires the lock and goes to post the event but because it has now been suspended it is an error to do so

So what we need is a way to disable suspension so that the transient/temporary switch to _thread_blocked does not allow a suspend request to be processed. I think that is preferable to trying to find where to add a place to check for suspension and actually suspend it.

But how is any of this new?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1978474572

From jiangli at openjdk.org  Tue Mar  4 01:48:22 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 4 Mar 2025 01:48:22 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
Message-ID: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>

Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 

On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 

On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.

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

Commit messages:
 - Ignore -server and -client options for static JDK.

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

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

From dlong at openjdk.org  Tue Mar  4 04:56:24 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 4 Mar 2025 04:56:24 GMT
Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization
 causes crash [v5]
In-Reply-To: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
Message-ID: <KAHNbVqGChNBrParEfqUiI_PBJlTsXxZjcXD-Sw3f24=.37b18372-86a8-475a-84c8-a444ce7e3135@github.com>

> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received.  In deoptimization, we check for this in several places, but in one place we had outdated code.  See the bug for the gory details.
> 
> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations.  There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports.
> 
> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee.  The asserts I added compute locals both ways and check that they are still within the frame.  I attempted this on all platforms, but am only able to test x64 and aarch64.  I need help testing those asserts for arm32, ppc, riscv, and s390.

Dean Long has updated the pull request incrementally with two additional commits since the last revision:

 - fix typo
 - moved and hopefully improved invokedynamic comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23557/files
  - new: https://git.openjdk.org/jdk/pull/23557/files/375f6cfe..80a3235a

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

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

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

From dlong at openjdk.org  Tue Mar  4 04:56:24 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 4 Mar 2025 04:56:24 GMT
Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization
 causes crash [v4]
In-Reply-To: <TW6xcOuJ2mZv4ranvXMNYeDtQ1JqVSuC7eAa65DY3xk=.e3868b19-b6f1-47a0-90a1-b8b9e44f4639@github.com>
References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
 <Fa9hDpRRHNXS6DyH6G7VJ5YJxa2w7eW5fFMzthVzi64=.2202f767-2ca9-42c2-91ad-5a051b0b2041@github.com>
 <TW6xcOuJ2mZv4ranvXMNYeDtQ1JqVSuC7eAa65DY3xk=.e3868b19-b6f1-47a0-90a1-b8b9e44f4639@github.com>
Message-ID: <XEJWrPtPDhiTbaN-t7vWdIl8kVBUjibiuMu54H_A6io=.8e48ee18-499d-4c69-a666-50aa415f4ef6@github.com>

On Sat, 1 Mar 2025 22:20:23 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use new Bytecode_invoke::has_memeber_arg
>
> src/hotspot/share/runtime/vframeArray.cpp line 616:
> 
>> 614:       // invokedynamic instructions don't have a class but obviously don't have a MemberName appendix.
>> 615:       // NOTE:  Use machinery here that avoids resolving of any kind.
>> 616:       const bool has_member_arg = inv.has_member_arg();
> 
> I reckon the comment about invokedynamic isn't needed anymore. It could be moved to has_member_arg if you want to keep it.

Good idea.  Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23557#discussion_r1978611223

From iklam at openjdk.org  Tue Mar  4 05:26:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Mar 2025 05:26:01 GMT
Subject: RFR: 8351082: Remove dead code for estimating CDS archive size
In-Reply-To: <6MYhpj1DB66EW5dLop23HsoaC9NpPryICRxVaxJpD54=.4d4ced4d-0fb5-4add-9f83-5463e30aa7ac@github.com>
References: <PAoDJaEFrQq4RzNHSvN1t2KCAZ643AYwcjEBMkctO-8=.c9606f76-1727-4978-9117-b24ff5bcd04e@github.com>
 <6MYhpj1DB66EW5dLop23HsoaC9NpPryICRxVaxJpD54=.4d4ced4d-0fb5-4add-9f83-5463e30aa7ac@github.com>
Message-ID: <KVfRdmeHrCJprtaGKqlApyE9PnYBS0evs2g5245v_WQ=.ed835d1a-c214-41a1-bd8c-1964637d97bd@github.com>

On Mon, 3 Mar 2025 21:36:55 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this trivial changeset that removes dead code that are no longer called after [JDK-8340416](https://bugs.openjdk.org/browse/JDK-8340416) "Remove ArchiveBuilder::estimate_archive_size()"
>
> Looks good and I think this is a trivial fix.

Thanks @calvinccheung for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23874#issuecomment-2696243156

From iklam at openjdk.org  Tue Mar  4 05:26:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Mar 2025 05:26:01 GMT
Subject: RFR: 8351087: Combine scratch object tables in heapShared.cpp
In-Reply-To: <7_M_0ofVLp-aKFONGkFoCwQ1AueZYG_739OqI9oBUIw=.8f61aabb-0ff2-4fd5-ac49-9ed2a61a1f4c@github.com>
References: <KAg3bC-8d4wSkg_HBn5nlrzBnrsKrV75fALagp5MCMk=.4dc5933e-525e-4c8d-abc2-ad121e37c30e@github.com>
 <7_M_0ofVLp-aKFONGkFoCwQ1AueZYG_739OqI9oBUIw=.8f61aabb-0ff2-4fd5-ac49-9ed2a61a1f4c@github.com>
Message-ID: <EIDuIUB6TPrMj6Qb-8J5Cd_ASbdH0PwfCjHifT2Bzpc=.1e0be757-6a9d-4912-908b-33f20c591235@github.com>

On Mon, 3 Mar 2025 22:41:22 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this trivial change. The two tables `_scratch_java_mirror_table` and `_scratch_references_table` are always disjoint. So we can simply combine them into a single table.
>> 
>> I am running tiers 1-5 for sanity sake.
>
> LGTM and the fix seems trivial.

Thanks @calvinccheung for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23876#issuecomment-2696242723

From iklam at openjdk.org  Tue Mar  4 05:26:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Mar 2025 05:26:02 GMT
Subject: Integrated: 8351082: Remove dead code for estimating CDS archive size
In-Reply-To: <PAoDJaEFrQq4RzNHSvN1t2KCAZ643AYwcjEBMkctO-8=.c9606f76-1727-4978-9117-b24ff5bcd04e@github.com>
References: <PAoDJaEFrQq4RzNHSvN1t2KCAZ643AYwcjEBMkctO-8=.c9606f76-1727-4978-9117-b24ff5bcd04e@github.com>
Message-ID: <auiSszGVurpxH110aX0udrzeUih6m9BCALHydIrEhjE=.22b0c045-fe0d-4c76-9470-839b13f4646b@github.com>

On Mon, 3 Mar 2025 21:25:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial changeset that removes dead code that are no longer called after [JDK-8340416](https://bugs.openjdk.org/browse/JDK-8340416) "Remove ArchiveBuilder::estimate_archive_size()"

This pull request has now been integrated.

Changeset: 4fc72b8e
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4fc72b8e4b22db2aa3217afb5b8c30d496589eb8
Stats:     65 lines in 7 files changed: 0 ins; 64 del; 1 mod

8351082: Remove dead code for estimating CDS archive size

Reviewed-by: ccheung

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

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

From iklam at openjdk.org  Tue Mar  4 05:26:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Mar 2025 05:26:02 GMT
Subject: Integrated: 8351087: Combine scratch object tables in heapShared.cpp
In-Reply-To: <KAg3bC-8d4wSkg_HBn5nlrzBnrsKrV75fALagp5MCMk=.4dc5933e-525e-4c8d-abc2-ad121e37c30e@github.com>
References: <KAg3bC-8d4wSkg_HBn5nlrzBnrsKrV75fALagp5MCMk=.4dc5933e-525e-4c8d-abc2-ad121e37c30e@github.com>
Message-ID: <7yY-PY5coCB_QOHY_W9O947uAbi9AWC_aKHSNOR0awk=.3b246a89-4f12-4182-b7e4-0838fc87c18a@github.com>

On Mon, 3 Mar 2025 21:50:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change. The two tables `_scratch_java_mirror_table` and `_scratch_references_table` are always disjoint. So we can simply combine them into a single table.
> 
> I am running tiers 1-5 for sanity sake.

This pull request has now been integrated.

Changeset: b6e2d66c
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6e2d66cc4c100d6604ce3edd25e04d459ed1ef1
Stats:     16 lines in 3 files changed: 0 ins; 3 del; 13 mod

8351087: Combine scratch object tables in heapShared.cpp

Reviewed-by: ccheung

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

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

From dholmes at openjdk.org  Tue Mar  4 06:40:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 06:40:00 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging
In-Reply-To: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
Message-ID: <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>

On Fri, 28 Feb 2025 09:16:19 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
> 
> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
> 
> Here is example log output with the change:
> 
> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
> 
> 
> 
> ### Test
> - [x] Tire1
> - [x] Tire2

src/hotspot/share/runtime/safepoint.cpp line 993:

> 991:      "Leaving safepoint: " JLONG_FORMAT " ns, "
> 992:      "Total: " JLONG_FORMAT " ns, "
> 993:      "Threads: " INT32_FORMAT " runnable, " INT32_FORMAT " total",

Why `INT32_FORMAT` when the fields are just `int`???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23838#discussion_r1978711638

From syan at openjdk.org  Tue Mar  4 06:42:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Mar 2025 06:42:38 GMT
Subject: RFR: 8351115: Test AOTClassLinkingVMOptions.java fails after
 JDK-8348322
Message-ID: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>

Hi all,

Test runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java fails "VM option 'AOTInvokeDynamicLinking' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions" after JDK-8348322. This PR add JVM option '-XX:+UnlockDiagnosticVMOptions' to make test run passes.

Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8351115: Test AOTClassLinkingVMOptions.java fails after JDK-8348322

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

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

From dholmes at openjdk.org  Tue Mar  4 06:51:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 06:51:57 GMT
Subject: RFR: 8350974: The os_cpu VM_STRUCTS, VM_TYPES,
 etc have no declarations and should be removed
In-Reply-To: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
References: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
Message-ID: <RBiiBAfbPk16esj3Hzyw1GSbeiEjIFVY0FwSKXo9x7k=.ff7fae94-f8c6-46b9-8b73-81e4ae545301@github.com>

On Mon, 3 Mar 2025 13:18:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove unused SA os_cpu declarations and files.
> Tested with serviceability/sa tests locally.

Looks like a nice cleanup. Just hope we won't need it back sometime.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23863#pullrequestreview-2656158760

From dholmes at openjdk.org  Tue Mar  4 06:58:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 06:58:03 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
Message-ID: <3FGQNZh7screOv_3niJLsCfXnzFzyP-O6A_r2LbxHRM=.b7a185b5-11a0-41a0-894d-e835f1341b9e@github.com>

On Tue, 4 Mar 2025 01:43:29 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
> 
> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
> 
> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.

src/hotspot/share/runtime/arguments.cpp line 2812:

> 2810:       // On regular JDK, '-server|-client' options are processed and removed
> 2811:       // from command-line arguments by CheckJvmType (see
> 2812:       // src/java.base/share/native/libjli/java.c). When running on static JDK,

Why not remove this in the launcher?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1978735436

From dholmes at openjdk.org  Tue Mar  4 07:22:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 07:22:52 GMT
Subject: RFR: 8351115: Test AOTClassLinkingVMOptions.java fails after
 JDK-8348322
In-Reply-To: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>
References: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>
Message-ID: <prrNU8u9pYc9OaBGzz3CnCe2Pl12-vmZ_xIWIeaqH0c=.90e2c76b-c37c-4ada-a458-b40f152796c4@github.com>

On Tue, 4 Mar 2025 06:37:23 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java fails "VM option 'AOTInvokeDynamicLinking' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions" after JDK-8348322. This PR add JVM option '-XX:+UnlockDiagnosticVMOptions' to make test run passes.
> 
> Change has been verified locally, test-fix only, no risk.

Looks good and trivial.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23883#pullrequestreview-2656238962

From mbaesken at openjdk.org  Tue Mar  4 08:15:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Mar 2025 08:15:01 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
Message-ID: <mSCoKo9abZps8mMeZU92lpGwH26lscp_cY-tvB6uVFk=.1c492ffe-4108-42cc-8fe1-d3e9047f6e82@github.com>

On Fri, 28 Feb 2025 20:40:37 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 copyright headers

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2656386374

From rrich at openjdk.org  Tue Mar  4 08:20:57 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 4 Mar 2025 08:20:57 GMT
Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization
 causes crash [v5]
In-Reply-To: <KAHNbVqGChNBrParEfqUiI_PBJlTsXxZjcXD-Sw3f24=.37b18372-86a8-475a-84c8-a444ce7e3135@github.com>
References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
 <KAHNbVqGChNBrParEfqUiI_PBJlTsXxZjcXD-Sw3f24=.37b18372-86a8-475a-84c8-a444ce7e3135@github.com>
Message-ID: <FLTVUD88UchOlaD7Rkl3WwBfZlTWtxFtoJq_uO1TAGk=.eccac4fd-5ed6-42a2-a36e-862bbff620ce@github.com>

On Tue, 4 Mar 2025 04:56:24 GMT, Dean Long <dlong at openjdk.org> wrote:

>> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received.  In deoptimization, we check for this in several places, but in one place we had outdated code.  See the bug for the gory details.
>> 
>> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations.  There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports.
>> 
>> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee.  The asserts I added compute locals both ways and check that they are still within the frame.  I attempted this on all platforms, but am only able to test x64 and aarch64.  I need help testing those asserts for arm32, ppc, riscv, and s390.
>
> Dean Long has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix typo
>  - moved and hopefully improved invokedynamic comment

Marked as reviewed by rrich (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23557#pullrequestreview-2656399880

From xpeng at openjdk.org  Tue Mar  4 08:21:57 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 4 Mar 2025 08:21:57 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging
In-Reply-To: <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>
Message-ID: <9jg9KyaEksmhfxskkThyfZz0c8ZVr9eP_91nMJXz5UI=.e866c6ac-0810-4de4-bf85-93bd90fc270b@github.com>

On Tue, 4 Mar 2025 06:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
>> 
>> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
>> 
>> Here is example log output with the change:
>> 
>> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
>> 
>> 
>> 
>> ### Test
>> - [x] Tire1
>> - [x] Tire2
>
> src/hotspot/share/runtime/safepoint.cpp line 993:
> 
>> 991:      "Leaving safepoint: " JLONG_FORMAT " ns, "
>> 992:      "Total: " JLONG_FORMAT " ns, "
>> 993:      "Threads: " INT32_FORMAT " runnable, " INT32_FORMAT " total",
> 
> Why `INT32_FORMAT` when the fields are just `int`???

Hi David, thanks for the review, I referred to the format used in safepoint [stats log](https://github.com/openjdk/jdk/pull/23838/files#diff-d61020d12394708828d066d097d823180c01b74d35d4c3e369aead062abc11efR913) where format `INT32_FORMAT_W(8)` is used for thread counts, but there is no need print thread count in fixed width with safepoint log, so I removed the fixed width from the format.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23838#discussion_r1978864746

From azafari at openjdk.org  Tue Mar  4 09:28:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 4 Mar 2025 09:28:09 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
 <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
Message-ID: <WUMVzHcgzKFH5463AtWo22dXJHwr1AYhVh-ZD2B4mT4=.37e0c716-7178-4444-bba0-99af7ecf8a1d@github.com>

On Mon, 3 Mar 2025 17:10:40 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style, some cleanup, VMT and regionsTree circular dep resolved
>
> src/hotspot/share/nmt/regionsTree.cpp line 28:
> 
>> 26: VMATree::SummaryDiff RegionsTree::commit_region(address addr, size_t size, const NativeCallStack& stack) {
>> 27:   return commit_mapping((VMATree::position)addr, size, make_region_data(stack, mtNone), /*use tag inplace*/ true);
>> 28: }
> 
> `RegionsTree::commit_region` is called by 
> 
>  ```
>  static inline void record_virtual_memory_reserve_and_commit(void* addr, size_t size,
>     const NativeCallStack& stack, MemTag mem_tag = mtNone) {
> 
> 
> which has mem_tag, so we could in theory use it and pass it down? Then we could avoid the complicated "use_tag_inplace" parameter handling?
> 
> Not sure if this is possible in all cases. Is that why we have the need for "use_tag_inplace"?

I have to separate the concerns as follow:
1. In `record_..._reserve_and_commit` the `mem_tag` is available since it is needed for `reserve`. So, you are right, we can use the tag and pass it down. The change set would be:
 `VMT::Instance::add_committed_region(addr, size, stack, MemTag = mtNone)`
 `VMT::add_committed_region(addr, size, stack, MemTag = mtNone)`
 `RegionsTree::commit_region(addr, size, stack, MemTag = mtNone)`
3. Even if we do so, `use_tag_in_place` is needed in `commit` because the `os::commit_memmory` family do not pass mem_tag down. There is already an abandoned PR which tried to add MemTag param to this family. It was reviewed as not necessary.
4. In addition, the `VMATree::register_mapping` has a mandatory MemTag param (in its MetaData param) which enforces the caller to pass down an specific MemTag. If we don't use `use_tag_inplace`, for every commit of region $[ base, end)$ we have to find the enclosing reserved region $[ A, B)$ where $A \le base < end \le B$ and get its mem_tag and then pass it down to `VMATree::register_mapping`. Finding the enclosing region could be too expensive and is preferred to be avoided. 

I can implement the case 1 above if it is preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1978991855

From jsjolen at openjdk.org  Tue Mar  4 09:28:11 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Mar 2025 09:28:11 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
 <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
Message-ID: <qP8P9uBidA-rpQUbdCMJlRFmfHwFLZHxZtS-JvHXLvU=.557b8c6b-a125-4e73-80a5-fb71a888a293@github.com>

On Mon, 3 Mar 2025 20:17:15 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style, some cleanup, VMT and regionsTree circular dep resolved
>
> test/hotspot/gtest/nmt/test_regions_tree.cpp line 98:
> 
>> 96:   rt.reserve_mapping(1400, 50, rd);
>> 97: 
>> 98:   rt.commit_region((address)1010, 5UL, ncs);
> 
> What would, what should happen if we repeat the same reserve_mapping?
> 
> rt.commit_region((address)1010, 5UL, ncs);
> rt.commit_region((address)1010, 5UL, ncs);
> 
> Are/should we be allowed to do this?

Nothing would happen, the state of the tree would stay the same. We should allow it, at least on product builds! For me, the most important part of this rewrite is getting rid of NMT crashing because it reaches states that it can't do anything with. We can handle more usage patterns, and we try our darnest to not fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1978986884

From azafari at openjdk.org  Tue Mar  4 09:48:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 4 Mar 2025 09:48:09 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
 <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
Message-ID: <QMUMnbIc0-CiKPuT7NIQ0kmBvYxyuMq2tow32pdIZiI=.20a3e3c1-bd6e-4728-8f7d-92cd0653b210@github.com>

On Mon, 3 Mar 2025 17:20:01 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style, some cleanup, VMT and regionsTree circular dep resolved
>
> src/hotspot/share/nmt/regionsTree.cpp line 32:
> 
>> 30: VMATree::SummaryDiff RegionsTree::uncommit_region(address addr, size_t size) {
>> 31:   return uncommit_mapping((VMATree::position)addr, size, make_region_data(NativeCallStack::empty_stack(), mtNone));
>> 32: }
> 
> Would it be helpful here if we were to add a new tag, that would mark this uncommitted region somehow different than mtNone (to mark it that it used to be used, but now it's not, which is different from never used region)?

An uncommitted region has implicitly the same tag as its containing reserved region:

<-------------Reserved Region, mtXXX---------->
<----C1----><..U1...><---C2--><..U2..><---C3-->

C1-C3 are committed regions with tag `mtXXX`
U1 and U2 are uncommitted and enclosed by a `mtXXX` tag region.

Do you have any specific use-case for this?

---
If you were thinking about *release_mapping* instead, then I can say that the released region will be sooner or later reserved by another memtag. For example, an mtStack region is released and immediately reserved by mtGC. In other words, any memtag on a released region would be overwritten by other uses of the same region.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1979035962

From azafari at openjdk.org  Tue Mar  4 10:04:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 4 Mar 2025 10:04:09 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
 <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
Message-ID: <8bygUpwKnmx05leCwTfcQsQkdlYljaDWbpr8lBL7deg=.0a098195-d497-4224-b1d2-1fb3be7071ed@github.com>

On Mon, 3 Mar 2025 19:58:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style, some cleanup, VMT and regionsTree circular dep resolved
>
> test/hotspot/gtest/nmt/test_regions_tree.cpp line 72:
> 
>> 70:   EXPECT_EQ(rmr.base(), (address)1400);
>> 71:   rmr = rt.find_reserved_region((address)1005);
>> 72:   EXPECT_EQ(rmr.base(), (address)1000);
> 
> When I do:
> 
>   rmr = rt.find_reserved_region((address)999);
> 
> I get back ReservedMemoryRegion with base == 1, I am not 100% sure what I was expecting - probably 0, but not 1.

Here, the 999 address is not in any region. 
If no region is found by the `rt.find_reserved_region(addr)`, a region with base==1 and size==1 is returned. base == 0 triggers some assertions since it is a pointer. Because of this, I added the `ReservedMemoryRegion::is_valid()` which checks base and size.


rmr = rt.find_reserved_region(999);
if (!rmr.is_valid()) {
  // your code ....
}

P.S.: The `find_reserved_region` is expensive and hopefully it would be removed in future PRs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1979067689

From azafari at openjdk.org  Tue Mar  4 10:11:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 4 Mar 2025 10:11:09 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
 <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
Message-ID: <MVExe_vwk1vP8x8nXlB9XTIZ6246Iv3fkMqnqg9T0iU=.39977106-e9a7-44ce-adf1-d36961932eb5@github.com>

On Mon, 3 Mar 2025 20:06:20 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style, some cleanup, VMT and regionsTree circular dep resolved
>
> test/hotspot/gtest/nmt/test_regions_tree.cpp line 102:
> 
>> 100:   rt.commit_region((address)1030, 5UL, ncs);
>> 101:   rt.commit_region((address)1040, 5UL, ncs);
>> 102:   ReservedMemoryRegion rmr((address)1000, 50);
> 
> I would add something like:
> 
>   rt.commit_region((address)1500, 5UL, ncs); // should not be counted
> 
> that should not be counted.

adding that line crashes for me as follows:

Internal Error (<local-path>/src/hotspot/share/nmt/vmatree.cpp:77), pid=87926, tid=87926
#  assert(leqA_n->val().out.type() != StateType::Released) failed: Should not use inplace the tag of a released region
#

It means that we cannot commit without reserving first. The region being committed is released but should be reserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1979080504

From azafari at openjdk.org  Tue Mar  4 10:18:12 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 4 Mar 2025 10:18:12 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <qP8P9uBidA-rpQUbdCMJlRFmfHwFLZHxZtS-JvHXLvU=.557b8c6b-a125-4e73-80a5-fb71a888a293@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
 <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
 <qP8P9uBidA-rpQUbdCMJlRFmfHwFLZHxZtS-JvHXLvU=.557b8c6b-a125-4e73-80a5-fb71a888a293@github.com>
Message-ID: <ltbZNslP8G5dKtISRclMF5gjXSTLvm_s3vVZk_XA4Vw=.b5aad723-4116-403b-897c-525acecc0de1@github.com>

On Tue, 4 Mar 2025 09:23:08 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> test/hotspot/gtest/nmt/test_regions_tree.cpp line 98:
>> 
>>> 96:   rt.reserve_mapping(1400, 50, rd);
>>> 97: 
>>> 98:   rt.commit_region((address)1010, 5UL, ncs);
>> 
>> What would, what should happen if we repeat the same reserve_mapping?
>> 
>> rt.commit_region((address)1010, 5UL, ncs);
>> rt.commit_region((address)1010, 5UL, ncs);
>> 
>> Are/should we be allowed to do this?
>
> Nothing would happen, the state of the tree would stay the same. We should allow it, at least on product builds! For me, the most important part of this rewrite is getting rid of NMT crashing because it reaches states that it can't do anything with. We can handle more usage patterns, and we try our darnest to not fail.

The test `TEST_VM_F(NMTRegionsTreeTest, ReserveCommitTwice)` is added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1979094540

From azafari at openjdk.org  Tue Mar  4 11:20:05 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 4 Mar 2025 11:20:05 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v34]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <dbApB_oGdCi_Xl-Un8RmQxtZSEMg2xN55F-vAtXKK9M=.56b42fe1-3494-48d2-9448-a4900d05de15@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  test cases for doing reserve or commit the same region twice.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/70209581..fc106d5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=32-33

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

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

From duke at openjdk.org  Tue Mar  4 11:22:06 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Mar 2025 11:22:06 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
Message-ID: <rzz2hqO1c3VbHiwQRTXimIarvn2at8U5FKg0GTy-qEM=.1b50e461-a84a-436b-ada9-a40e0387e280@github.com>

On Fri, 28 Feb 2025 20:40:37 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 copyright headers

@sercher 
Your change (at version bae78ff7c43e0446ef583db1c43b4a3d6c06ad4f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2697178573

From alanb at openjdk.org  Tue Mar  4 12:13:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Mar 2025 12:13:54 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <3FGQNZh7screOv_3niJLsCfXnzFzyP-O6A_r2LbxHRM=.b7a185b5-11a0-41a0-894d-e835f1341b9e@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <3FGQNZh7screOv_3niJLsCfXnzFzyP-O6A_r2LbxHRM=.b7a185b5-11a0-41a0-894d-e835f1341b9e@github.com>
Message-ID: <FBVDncudYi08PKWdiwtOaXPzB4fpKw3WDGUx4KRd36E=.ed4857e1-bf73-4d20-8234-37746c515af9@github.com>

On Tue, 4 Mar 2025 06:55:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> src/hotspot/share/runtime/arguments.cpp line 2812:
> 
>> 2810:       // On regular JDK, '-server|-client' options are processed and removed
>> 2811:       // from command-line arguments by CheckJvmType (see
>> 2812:       // src/java.base/share/native/libjli/java.c). When running on static JDK,
> 
> Why not remove this in the launcher?

In addition to David's comment, I think we have to wonder why anyone would specify -client or -server when using a statically linked image. There's isn't a choice when using a statically linked image.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1979303185

From coleenp at openjdk.org  Tue Mar  4 12:36:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 12:36:55 GMT
Subject: RFR: 8350974: The os_cpu VM_STRUCTS, VM_TYPES,
 etc have no declarations and should be removed
In-Reply-To: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
References: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
Message-ID: <ntzKCFnzHEpSwiru58q5eO_FozKykMtjnx_2W26nP7M=.b967227b-c046-4352-b411-9038d11c70ec@github.com>

On Mon, 3 Mar 2025 13:18:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove unused SA os_cpu declarations and files.
> Tested with serviceability/sa tests locally.

I hope we don't need it back either.  It seems like that would be a mistake.
Thanks for reviewing Vladimir and David.

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

PR Comment: https://git.openjdk.org/jdk/pull/23863#issuecomment-2697412679

From coleenp at openjdk.org  Tue Mar  4 12:36:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 12:36:56 GMT
Subject: Integrated: 8350974: The os_cpu VM_STRUCTS, VM_TYPES,
 etc have no declarations and should be removed
In-Reply-To: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
References: <5tduy8eWKKgJLZkLBoHjm9nteFZjRjO8anX8RPR30m0=.9642abde-1d70-45f2-8a51-29876df34aef@github.com>
Message-ID: <9dsp8O-y7b48cMExSqdOjq0kmCdCYkF3_6pB6higOgc=.722abce3-869b-4a64-9a54-7cf75c93bdb0@github.com>

On Mon, 3 Mar 2025 13:18:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove unused SA os_cpu declarations and files.
> Tested with serviceability/sa tests locally.

This pull request has now been integrated.

Changeset: 8073914a
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8073914af7d4ddd7bbd93d75104c7637e38a7ad9
Stats:     564 lines in 14 files changed: 0 ins; 564 del; 0 mod

8350974: The os_cpu VM_STRUCTS, VM_TYPES, etc have no declarations and should be removed

Reviewed-by: kvn, dholmes

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

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

From coleenp at openjdk.org  Tue Mar  4 13:02:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 13:02:06 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs
Message-ID: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>

Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
Tested with SA tests locally.

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

Commit messages:
 - 8351165: Remove unused includes from vmStructs

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

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

From coleenp at openjdk.org  Tue Mar  4 13:14:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 13:14:31 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v2]
In-Reply-To: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
Message-ID: <XN5l6cr1U8g6vP2b_lDoFr5X5mZvAchjLcfmG3vM6fo=.3ac36468-07f8-4bcd-9058-9b81db8101a1@github.com>

> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
> Tested with SA tests locally.

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

  One more.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23897/files
  - new: https://git.openjdk.org/jdk/pull/23897/files/c66907b6..e33d5066

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

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

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

From coleenp at openjdk.org  Tue Mar  4 13:22:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 13:22:24 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v3]
In-Reply-To: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
Message-ID: <ACQWDRy0JGkwOnfNEs9eLA47TGmt1nPBqcGfBeNhdjQ=.fcd745a1-9741-4e08-9a3a-bb0e742b2b74@github.com>

> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
> Tested with SA tests locally.

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

  Change the SystemDictionary section header comment too.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23897/files
  - new: https://git.openjdk.org/jdk/pull/23897/files/e33d5066..86443005

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

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

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

From shade at openjdk.org  Tue Mar  4 13:23:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Mar 2025 13:23:54 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging
In-Reply-To: <9jg9KyaEksmhfxskkThyfZz0c8ZVr9eP_91nMJXz5UI=.e866c6ac-0810-4de4-bf85-93bd90fc270b@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>
 <9jg9KyaEksmhfxskkThyfZz0c8ZVr9eP_91nMJXz5UI=.e866c6ac-0810-4de4-bf85-93bd90fc270b@github.com>
Message-ID: <HYGN6RdCJTLnu9xT_8BBmMN1s9X5rIJiGUmUCwc1q7E=.9a726bff-a279-4317-8985-948b2264768d@github.com>

On Tue, 4 Mar 2025 08:19:34 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepoint.cpp line 993:
>> 
>>> 991:      "Leaving safepoint: " JLONG_FORMAT " ns, "
>>> 992:      "Total: " JLONG_FORMAT " ns, "
>>> 993:      "Threads: " INT32_FORMAT " runnable, " INT32_FORMAT " total",
>> 
>> Why `INT32_FORMAT` when the fields are just `int`???
>
> Hi David, thanks for the review, I referred to the format used in safepoint [stats log](https://github.com/openjdk/jdk/pull/23838/files#diff-d61020d12394708828d066d097d823180c01b74d35d4c3e369aead062abc11efR913) where format `INT32_FORMAT_W(8)` is used for thread counts, but there is no need print thread count in fixed width with safepoint log, so I removed the fixed width from the format.

The question now is, why not just `%d` then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23838#discussion_r1979423234

From coleenp at openjdk.org  Tue Mar  4 13:31:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 13:31:03 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging
In-Reply-To: <HYGN6RdCJTLnu9xT_8BBmMN1s9X5rIJiGUmUCwc1q7E=.9a726bff-a279-4317-8985-948b2264768d@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>
 <9jg9KyaEksmhfxskkThyfZz0c8ZVr9eP_91nMJXz5UI=.e866c6ac-0810-4de4-bf85-93bd90fc270b@github.com>
 <HYGN6RdCJTLnu9xT_8BBmMN1s9X5rIJiGUmUCwc1q7E=.9a726bff-a279-4317-8985-948b2264768d@github.com>
Message-ID: <wKY52pbBvSGQxgIF0LkDSff-8ZEBKZVIJFABfwgMQCg=.27ba9aa3-3375-4fac-9838-06062d02b53c@github.com>

On Tue, 4 Mar 2025 13:20:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi David, thanks for the review, I referred to the format used in safepoint [stats log](https://github.com/openjdk/jdk/pull/23838/files#diff-d61020d12394708828d066d097d823180c01b74d35d4c3e369aead062abc11efR913) where format `INT32_FORMAT_W(8)` is used for thread counts, but there is no need print thread count in fixed width with safepoint log, so I removed the fixed width from the format.
>
> The question now is, why not just `%d` then?

Maybe we should get rid of INT32_FORMAT too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23838#discussion_r1979434281

From kbarrett at openjdk.org  Tue Mar  4 14:33:57 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 4 Mar 2025 14:33:57 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v3]
In-Reply-To: <ACQWDRy0JGkwOnfNEs9eLA47TGmt1nPBqcGfBeNhdjQ=.fcd745a1-9741-4e08-9a3a-bb0e742b2b74@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
 <ACQWDRy0JGkwOnfNEs9eLA47TGmt1nPBqcGfBeNhdjQ=.fcd745a1-9741-4e08-9a3a-bb0e742b2b74@github.com>
Message-ID: <y-1m0EtjTMtHJFGjx2lrEBpk-_s6Tk5qV1es8zOWIXw=.88ad6135-36cc-4a06-9c5b-ab2dbf524be4@github.com>

On Tue, 4 Mar 2025 13:22:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
>> Tested with SA tests locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the SystemDictionary section header comment too.

I think that if classes are being removed from here that the friendship with
VMStructs by those classes should also be removed.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23897#pullrequestreview-2657808981

From shade at openjdk.org  Tue Mar  4 15:49:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Mar 2025 15:49:59 GMT
Subject: RFR: 8348829: Remove ObjectMonitor perf counters [v2]
In-Reply-To: <Wrj8hq74Nb285CwGZYfU4GN4brnUZpBOM40s5nHLaE8=.f9ed8c61-8eac-4a8c-aed2-dfffd24d8467@github.com>
References: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
 <Wrj8hq74Nb285CwGZYfU4GN4brnUZpBOM40s5nHLaE8=.f9ed8c61-8eac-4a8c-aed2-dfffd24d8467@github.com>
Message-ID: <G_OMPUjGlXak5Ha8ur68TL5YeGgZoMl3yHsDiKkPgwg=.69d0fcc4-e331-4d3f-b9d3-d221aca3cc77@github.com>

On Mon, 3 Mar 2025 16:45:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for more discussion. I believe these counters are useless and come with more trouble than their worth.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8348829-remove-om-counters
>  - Counters removal

Thanks! I looked deeper what JFR events are available to capture what where these counters help, and I think we want a few new ones (see linked issues). Adding these new JFR events would require code changes in the vicinity of this PR, so I would have to re-merge anyway. Until those events land, this PR is on hold.

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

PR Comment: https://git.openjdk.org/jdk/pull/23326#issuecomment-2698089732

From gziemski at openjdk.org  Tue Mar  4 16:03:09 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 4 Mar 2025 16:03:09 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <WUMVzHcgzKFH5463AtWo22dXJHwr1AYhVh-ZD2B4mT4=.37e0c716-7178-4444-bba0-99af7ecf8a1d@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
 <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
 <WUMVzHcgzKFH5463AtWo22dXJHwr1AYhVh-ZD2B4mT4=.37e0c716-7178-4444-bba0-99af7ecf8a1d@github.com>
Message-ID: <8226VeBvQn8tORIXH1zg_9fJ1A8db9zYEtP6mM8ldOU=.144cb69c-8b75-441f-9ee0-5dc9333b9943@github.com>

On Tue, 4 Mar 2025 09:25:26 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/regionsTree.cpp line 28:
>> 
>>> 26: VMATree::SummaryDiff RegionsTree::commit_region(address addr, size_t size, const NativeCallStack& stack) {
>>> 27:   return commit_mapping((VMATree::position)addr, size, make_region_data(stack, mtNone), /*use tag inplace*/ true);
>>> 28: }
>> 
>> `RegionsTree::commit_region` is called by 
>> 
>>  ```
>>  static inline void record_virtual_memory_reserve_and_commit(void* addr, size_t size,
>>     const NativeCallStack& stack, MemTag mem_tag = mtNone) {
>> 
>> 
>> which has mem_tag, so we could in theory use it and pass it down? Then we could avoid the complicated "use_tag_inplace" parameter handling?
>> 
>> Not sure if this is possible in all cases. Is that why we have the need for "use_tag_inplace"?
>
> I have to separate the concerns as follow:
> 1. In `record_..._reserve_and_commit` the `mem_tag` is available since it is needed for `reserve`. So, you are right, we can use the tag and pass it down. The change set would be:
>  `VMT::Instance::add_committed_region(addr, size, stack, MemTag = mtNone)`
>  `VMT::add_committed_region(addr, size, stack, MemTag = mtNone)`
>  `RegionsTree::commit_region(addr, size, stack, MemTag = mtNone)`
> 3. Even if we do so, `use_tag_in_place` is needed in `commit` because the `os::commit_memmory` family do not pass mem_tag down. There is already an abandoned PR which tried to add MemTag param to this family. It was reviewed as not necessary.
> 4. In addition, the `VMATree::register_mapping` has a mandatory MemTag param (in its MetaData param) which enforces the caller to pass down an specific MemTag. If we don't use `use_tag_inplace`, for every commit of region $[ base, end)$ we have to find the enclosing reserved region $[ A, B)$ where $A \le base < end \le B$ and get its mem_tag and then pass it down to `VMATree::register_mapping`. Finding the enclosing region could be too expensive and is preferred to be avoided. 
> 
> I can implement the case 1 above if it is preferred.

It would help with cleaning mem_tags issue, where we are trying to clean up "mtNone" tags.

>> src/hotspot/share/nmt/regionsTree.cpp line 32:
>> 
>>> 30: VMATree::SummaryDiff RegionsTree::uncommit_region(address addr, size_t size) {
>>> 31:   return uncommit_mapping((VMATree::position)addr, size, make_region_data(NativeCallStack::empty_stack(), mtNone));
>>> 32: }
>> 
>> Would it be helpful here if we were to add a new tag, that would mark this uncommitted region somehow different than mtNone (to mark it that it used to be used, but now it's not, which is different from never used region)?
>
> An uncommitted region has implicitly the same tag as its containing reserved region:
> 
> <-------------Reserved Region, mtXXX---------->
> <----C1----><..U1...><---C2--><..U2..><---C3-->
> 
> C1-C3 are committed regions with tag `mtXXX`
> U1 and U2 are uncommitted and enclosed by a `mtXXX` tag region.
> 
> Do you have any specific use-case for this?
> 
> ---
> If you were thinking about *release_mapping* instead, then I can say that the released region will be sooner or later reserved by another memtag. For example, an mtStack region is released and immediately reserved by mtGC. In other words, any memtag on a released region would be overwritten by other uses of the same region.

I was thinking in terms of cleaning up all the mtNone tags. Here we could set it to something more meaningful than mtNone?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1979749939
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1979752152

From iklam at openjdk.org  Tue Mar  4 16:35:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Mar 2025 16:35:53 GMT
Subject: RFR: 8351115: Test AOTClassLinkingVMOptions.java fails after
 JDK-8348322
In-Reply-To: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>
References: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>
Message-ID: <-84RuR54j3dqWvglVZtk8Vw66bOItkXWO8rVl_bMTd0=.6345bb28-8c8c-4111-846d-492d9516cd60@github.com>

On Tue, 4 Mar 2025 06:37:23 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java fails "VM option 'AOTInvokeDynamicLinking' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions" after JDK-8348322. This PR add JVM option '-XX:+UnlockDiagnosticVMOptions' to make test run passes.
> 
> Change has been verified locally, test-fix only, no risk.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23883#pullrequestreview-2658248643

From coleenp at openjdk.org  Tue Mar  4 16:40:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 16:40:13 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v4]
In-Reply-To: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
Message-ID: <Xgu8UIwABLb2fgRaWTmwNIK-2SkENTjFIwbYjcOp0uY=.ec2d752c-464f-4d48-8be7-8d0c50e97ba7@github.com>

> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
> Tested with SA tests locally.

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

  Remove some friends.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23897/files
  - new: https://git.openjdk.org/jdk/pull/23897/files/86443005..f2bb9364

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

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

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

From coleenp at openjdk.org  Tue Mar  4 16:44:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 16:44:52 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v3]
In-Reply-To: <y-1m0EtjTMtHJFGjx2lrEBpk-_s6Tk5qV1es8zOWIXw=.88ad6135-36cc-4a06-9c5b-ab2dbf524be4@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
 <ACQWDRy0JGkwOnfNEs9eLA47TGmt1nPBqcGfBeNhdjQ=.fcd745a1-9741-4e08-9a3a-bb0e742b2b74@github.com>
 <y-1m0EtjTMtHJFGjx2lrEBpk-_s6Tk5qV1es8zOWIXw=.88ad6135-36cc-4a06-9c5b-ab2dbf524be4@github.com>
Message-ID: <SDTfCo4DMRTHCqHbW_9_D9Jyx_LTs21Y9RMBCuP90Q8=.e1550a6e-3444-4d0f-ae0e-1c62a28da0e8@github.com>

On Tue, 4 Mar 2025 14:30:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I think that if classes are being removed from here that the friendship with
VMStructs by those classes should also be removed.

Good point.  Thanks for remembering these.

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

PR Comment: https://git.openjdk.org/jdk/pull/23897#issuecomment-2698293824

From xpeng at openjdk.org  Tue Mar  4 17:39:02 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 4 Mar 2025 17:39:02 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging
In-Reply-To: <wKY52pbBvSGQxgIF0LkDSff-8ZEBKZVIJFABfwgMQCg=.27ba9aa3-3375-4fac-9838-06062d02b53c@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>
 <9jg9KyaEksmhfxskkThyfZz0c8ZVr9eP_91nMJXz5UI=.e866c6ac-0810-4de4-bf85-93bd90fc270b@github.com>
 <HYGN6RdCJTLnu9xT_8BBmMN1s9X5rIJiGUmUCwc1q7E=.9a726bff-a279-4317-8985-948b2264768d@github.com>
 <wKY52pbBvSGQxgIF0LkDSff-8ZEBKZVIJFABfwgMQCg=.27ba9aa3-3375-4fac-9838-06062d02b53c@github.com>
Message-ID: <FoRbb5N-pygbUOqr0lYMezY5MrnAQHLNVWn4bEbmycc=.639db57a-9557-40ec-ad00-3479645c5216@github.com>

On Tue, 4 Mar 2025 13:28:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The question now is, why not just `%d` then?
>
> Maybe we should get rid of INT32_FORMAT too?

I think INT32_FORMAT makes the code style more consistent within the context, but I am ok with using `%d` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23838#discussion_r1979921091

From jiangli at openjdk.org  Tue Mar  4 17:53:07 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 4 Mar 2025 17:53:07 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <3FGQNZh7screOv_3niJLsCfXnzFzyP-O6A_r2LbxHRM=.b7a185b5-11a0-41a0-894d-e835f1341b9e@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <3FGQNZh7screOv_3niJLsCfXnzFzyP-O6A_r2LbxHRM=.b7a185b5-11a0-41a0-894d-e835f1341b9e@github.com>
Message-ID: <BqiXdJlwiOJXDMmRP9F-4uUKoYZr1CkYfjKlE5HO8Y8=.54ba80f9-eefc-4bfe-85bf-f19de5c702d7@github.com>

On Tue, 4 Mar 2025 06:55:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> src/hotspot/share/runtime/arguments.cpp line 2812:
> 
>> 2810:       // On regular JDK, '-server|-client' options are processed and removed
>> 2811:       // from command-line arguments by CheckJvmType (see
>> 2812:       // src/java.base/share/native/libjli/java.c). When running on static JDK,
> 
> Why not remove this in the launcher?

@dholmes-ora @AlanBateman Thanks for taking a looking.

> Why not remove this in the launcher?

I made the change in `Arguments::parse_each_vm_init_arg` mainly because the error led me there. Taking another look at the related launcher code now, I think removing the options in launcher is also doable. On regular JDK, ?`CheckJvmType` happens before `ParseArguments`. If we change `ParseArguments` to remove the options, we don't need to do an extra check to see if we are running on static or regular JDK.

> I think we have to wonder why anyone would specify -client or -server when using a statically linked image. There's isn't a choice when using a statically linked image.

I had given some thoughts on it back when making the related change. For users running a hermetic Java image, they would not be using any pre-existing scripts without modification. So `-client|-server` would not be a concern in that sense. 

Ignoring the options without failing on static JDK provides the same behavior as on regular JDK and avoids changing the tests to remove `-client|-server`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1979940279

From pchilanomate at openjdk.org  Tue Mar  4 18:26:10 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Mar 2025 18:26:10 GMT
Subject: RFR: 8336042: Caller/callee param size mismatch in deoptimization
 causes crash [v5]
In-Reply-To: <KAHNbVqGChNBrParEfqUiI_PBJlTsXxZjcXD-Sw3f24=.37b18372-86a8-475a-84c8-a444ce7e3135@github.com>
References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
 <KAHNbVqGChNBrParEfqUiI_PBJlTsXxZjcXD-Sw3f24=.37b18372-86a8-475a-84c8-a444ce7e3135@github.com>
Message-ID: <nOMGqNW6oz2o4B-9JVBRPuJuWcWxc5liDu7UNs8SvMw=.07d08f63-b8df-4b76-8214-77bfe5c2fd11@github.com>

On Tue, 4 Mar 2025 04:56:24 GMT, Dean Long <dlong at openjdk.org> wrote:

>> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received.  In deoptimization, we check for this in several places, but in one place we had outdated code.  See the bug for the gory details.
>> 
>> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations.  There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports.
>> 
>> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee.  The asserts I added compute locals both ways and check that they are still within the frame.  I attempted this on all platforms, but am only able to test x64 and aarch64.  I need help testing those asserts for arm32, ppc, riscv, and s390.
>
> Dean Long has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix typo
>  - moved and hopefully improved invokedynamic comment

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23557#pullrequestreview-2658565622

From alanb at openjdk.org  Tue Mar  4 18:50:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Mar 2025 18:50:57 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
Message-ID: <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>

On Tue, 4 Mar 2025 01:43:29 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
> 
> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
> 
> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.

Jiangli and I chatted about this today. We don't think there will be developers looking to specify -server or -client to a static image, instead this is more about the tests. So we think the best think is to look at the tests that still specify -server and see if it can be dropped. Some of the tests (say for C2) might be better off using `@requires vm.compiler2.enabled` or `@requires vm.flavor == "server"`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2698584730

From szaldana at openjdk.org  Tue Mar  4 19:04:01 2025
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 4 Mar 2025 19:04:01 GMT
Subject: Withdrawn: 8325068: runtime/os/TestTracePageSizes.java: incorrect page
 size comparison for kernels < 5.0 with THP 'always' mode
In-Reply-To: <Cq0BDLo_6FNvipMyWBuR3FRCEW0T7H-SYo3soBGsNas=.eb20d730-19ab-4571-a75e-fd21d7e9c3dc@github.com>
References: <Cq0BDLo_6FNvipMyWBuR3FRCEW0T7H-SYo3soBGsNas=.eb20d730-19ab-4571-a75e-fd21d7e9c3dc@github.com>
Message-ID: <SwrVsXIpqGOiZrxXHixJ6UXvbjXOTd0Oh4rFwZbrrRY=.c383450f-c550-43e6-8a66-02b1b4441cce@github.com>

On Fri, 24 Jan 2025 18:01:23 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8325068](https://bugs.openjdk.org/browse/JDK-8325068) by disabling the test if running a kernel version < 5.0 with THP 'always' mode enabled. 
> 
> On older kernels, when THP mode is "always," the test fails because it doesn?t find the `THPeligible` field to identify that a mapping uses THP. As a result, it incorrectly compares the logged page size to the smaller page size reported in `/proc/self/smaps`.
> 
> Thanks, 
> Sonia

This pull request has been closed without being integrated.

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

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

From jiangli at openjdk.org  Tue Mar  4 19:18:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 4 Mar 2025 19:18:57 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
Message-ID: <X6mu264HF5dQl7nDp_xDA5mcvBrXK0Tk_Hv2cvZUW-I=.5ead7b88-a62d-4076-9bdb-158923b4fd98@github.com>

On Tue, 4 Mar 2025 18:48:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Jiangli and I chatted about this today. We don't think there will be developers looking to specify -server or -client to a static image, instead this is more about the tests. So we think the best think is to look at the tests that still specify -server and see if it can be dropped. Some of the tests (say for C2) might be better off using `@requires vm.compiler2.enabled` or `@requires vm.flavor == "server"`.

Thanks for the notes, @AlanBateman. Yeah, updating the tests sounds the right thing to do, for cleanups. I'm going to withdraw this PR and create a new PR for the test updates. @dholmes-ora Please let me know if this sounds good to you. Alan and I also discussed (briefly) the part on the static JDK behavior, which can be described in any of the related JEP(s).

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2698669700

From xpeng at openjdk.org  Tue Mar  4 19:45:33 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 4 Mar 2025 19:45:33 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging [v2]
In-Reply-To: <FoRbb5N-pygbUOqr0lYMezY5MrnAQHLNVWn4bEbmycc=.639db57a-9557-40ec-ad00-3479645c5216@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>
 <9jg9KyaEksmhfxskkThyfZz0c8ZVr9eP_91nMJXz5UI=.e866c6ac-0810-4de4-bf85-93bd90fc270b@github.com>
 <HYGN6RdCJTLnu9xT_8BBmMN1s9X5rIJiGUmUCwc1q7E=.9a726bff-a279-4317-8985-948b2264768d@github.com>
 <wKY52pbBvSGQxgIF0LkDSff-8ZEBKZVIJFABfwgMQCg=.27ba9aa3-3375-4fac-9838-06062d02b53c@github.com>
 <FoRbb5N-pygbUOqr0lYMezY5MrnAQHLNVWn4bEbmycc=.639db57a-9557-40ec-ad00-3479645c5216@github.com>
Message-ID: <OKcTiJE9Y64_FdLqeNO2YhEFpktyMzBR6XmGOA36Lyw=.78793734-8e18-41bc-9ffa-5aa3330e22a4@github.com>

On Tue, 4 Mar 2025 17:36:13 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Maybe we should get rid of INT32_FORMAT too?
>
> I think INT32_FORMAT makes the code style more consistent within the context, but I am ok with using `%d` here.

I have updated the PR to use `%d `.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23838#discussion_r1980122166

From xpeng at openjdk.org  Tue Mar  4 19:45:33 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 4 Mar 2025 19:45:33 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging [v2]
In-Reply-To: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
Message-ID: <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>

> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
> 
> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
> 
> Here is example log output with the change:
> 
> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
> 
> 
> 
> ### Test
> - [x] Tire1
> - [x] Tire2

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Use format %d instead of INT32_FORMAT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23838/files
  - new: https://git.openjdk.org/jdk/pull/23838/files/10707b16..874791f4

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

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

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

From xpeng at openjdk.org  Tue Mar  4 19:45:33 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 4 Mar 2025 19:45:33 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging [v2]
In-Reply-To: <OKcTiJE9Y64_FdLqeNO2YhEFpktyMzBR6XmGOA36Lyw=.78793734-8e18-41bc-9ffa-5aa3330e22a4@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>
 <9jg9KyaEksmhfxskkThyfZz0c8ZVr9eP_91nMJXz5UI=.e866c6ac-0810-4de4-bf85-93bd90fc270b@github.com>
 <HYGN6RdCJTLnu9xT_8BBmMN1s9X5rIJiGUmUCwc1q7E=.9a726bff-a279-4317-8985-948b2264768d@github.com>
 <wKY52pbBvSGQxgIF0LkDSff-8ZEBKZVIJFABfwgMQCg=.27ba9aa3-3375-4fac-9838-06062d02b53c@github.com>
 <FoRbb5N-pygbUOqr0lYMezY5MrnAQHLNVWn4bEbmycc=.639db57a-9557-40ec-ad00-3479645c5216@github.com>
 <OKcTiJE9Y64_FdLqeNO2YhEFpktyMzBR6XmGOA36Lyw=.78793734-8e18-41bc-9ffa-5aa3330e22a4@github.com>
Message-ID: <4160dyZzw-tg_bD0l0rtEVRahzzcwtD335DOhuno7jA=.2b08d927-b78b-4c2e-b5f5-0da12ce0101a@github.com>

On Tue, 4 Mar 2025 19:39:49 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> I think INT32_FORMAT makes the code style more consistent within the context, but I am ok with using `%d` here.
>
> I have updated the PR to use `%d `.

> Maybe we should get rid of INT32_FORMAT too?

Thanks Coleen, do you mean in the entire repo? I'll follow up on it with another PR if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23838#discussion_r1980125247

From gziemski at openjdk.org  Tue Mar  4 19:48:16 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 4 Mar 2025 19:48:16 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v34]
In-Reply-To: <dbApB_oGdCi_Xl-Un8RmQxtZSEMg2xN55F-vAtXKK9M=.56b42fe1-3494-48d2-9448-a4900d05de15@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <dbApB_oGdCi_Xl-Un8RmQxtZSEMg2xN55F-vAtXKK9M=.56b42fe1-3494-48d2-9448-a4900d05de15@github.com>
Message-ID: <oJyLxtaU5gdQO0Pw-QCIoJim1RJFrhwjd9zfsWfbiyI=.fd66550d-5d3b-47ef-b38c-c6a83a174a1d@github.com>

On Tue, 4 Mar 2025 11:20:05 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cases for doing reserve or commit the same region twice.

LGTM, thanks!

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

Marked as reviewed by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2658817432

From gziemski at openjdk.org  Tue Mar  4 19:48:17 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 4 Mar 2025 19:48:17 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v33]
In-Reply-To: <MVExe_vwk1vP8x8nXlB9XTIZ6246Iv3fkMqnqg9T0iU=.39977106-e9a7-44ce-adf1-d36961932eb5@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <hT2CMvzDht9GU8IEBrHCPpZVfaBeyxoaE1j3DlXOFFc=.8cb1d3f5-d40e-426b-8acc-fe088294a05e@github.com>
 <6HZ_GjpHmTXV-HiRJQ1GucpUNC9YifDkXIpUnAupjJ4=.a94bb403-b0d6-4d65-97c7-4644245aae55@github.com>
 <MVExe_vwk1vP8x8nXlB9XTIZ6246Iv3fkMqnqg9T0iU=.39977106-e9a7-44ce-adf1-d36961932eb5@github.com>
Message-ID: <o526NDv8v32se5k8jE7Hv_LMtCM0kFBM7mOy1st52EI=.a89752d8-3154-42e6-a62f-0a51f5d913cf@github.com>

On Tue, 4 Mar 2025 10:08:18 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> test/hotspot/gtest/nmt/test_regions_tree.cpp line 102:
>> 
>>> 100:   rt.commit_region((address)1030, 5UL, ncs);
>>> 101:   rt.commit_region((address)1040, 5UL, ncs);
>>> 102:   ReservedMemoryRegion rmr((address)1000, 50);
>> 
>> I would add something like:
>> 
>>   rt.commit_region((address)1500, 5UL, ncs); // should not be counted
>> 
>> that should not be counted.
>
> adding that line crashes for me as follows:
> 
> Internal Error (<local-path>/src/hotspot/share/nmt/vmatree.cpp:77), pid=87926, tid=87926
> #  assert(leqA_n->val().out.type() != StateType::Released) failed: Should not use inplace the tag of a released region
> #
> 
> It means that we cannot commit without reserving first. The region being committed is released but should be reserved.

I was running it without asserts and didn't see it, but it's good that assert catches it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1980126456

From pchilanomate at openjdk.org  Tue Mar  4 20:56:57 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Mar 2025 20:56:57 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v4]
In-Reply-To: <quOtN5QjPbF6HTKH8qcsO5McKDxh5meIlmXnPcHhPqc=.f50dd161-025f-44ef-ba30-a7a61d6c312e@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
 <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com>
 <lKSu4UoGBLaWqEQbM2lJ0ctU5sDPZNkZtFfVNSJdwXs=.5f5a530f-f4f7-4715-a109-c913d38ad373@github.com>
 <x9aEMsQnMrC5ikLH-pbRzGF6EtkkAXppinbZIswVydI=.2d0d18d8-3af2-4f84-928f-95a384f846c7@github.com>
 <FpigHhXOb9nISzF_4EqAR5fzM6pUhVtpTyz7fXqd7_A=.13e96a32-e426-4ee2-8401-7337ca34367c@github.com>
 <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com>
 <iv39Wpp0MFwwesm5NI3ZvZD-xDnFyk4kZMpd19EZ30w=.b0b26989-7499-4b70-97ae-97e19138fe89@github.com>
 <WPY1X633YLLzKWRGX4RJma0CF983CGb1bSMrMs815jM=.084998ec-5bd2-4df5-8948-2161b4c6dd92@github.com>
 <azWxxjE8kLgJpSAiU4SAOk_E4ggzuN_rdoUHxbKHpE4=.275aa5f2-e7e7-4b6e-ad28-a3f34613b1e2@github.com>
 <DTJzFg5YGxLmof32AHTbpGnbIqUO_ygljkHGzhi0pKY=.c68129f6-dbab-4be9-b286-f5d892be60e6@github.com>
 <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x
 YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com>
 <ATSNFuB3otIkeyutW0m0RZHb_OA6BQPxgVanqPUHcAk=.ea8402a7-7058-4edc-aff8-0d6e48a4cedf@github.com>
 <ghaunIfZWap8c9LPz8jpYA_8KFTUhMkDZ1gkwD8kM2E=.cea3a66a-cb87-4464-a3b3-c5a9110fc75b@github.com>
 <tfNnOivL70wmw5IJ0catb58ef4ssrcmeztdgq_H525k=.432a5a11-afd1-4c6f-b24e-297e912ecb4d@github.com>
 <cZf3RuYW5CuMeRXOiJcepc70WK0eY5DITnZh1Elx4mM=.1a7e9d1d-b4a7-4cbb-b6a2-47b21f7aea52@github.com>
 <Bctrj8H3ZpTmh4JxhPpbEkG5m18Qa0roptqVW9czRKQ=.12d8658b-891c-44f9-8717-454dbecd8927@github.com>
 <uUzETr66Gr6wUUB54oHOJJcjemTcKgLFEwB-AdPp1pg=.5209349d-4fe7-48fa-9459-9f3a4555ff16@github.com>
 <RyyM64wPq5iN-sAEvt6SZidNvW51J4HqVzcTG7bNcwY=.56c40bb7-2974-4e00-9b01-3a99041edbff@github.com>
 <x-bxlwRSaJZdwXbU9zsYvgooLlAu3DX5Cj8kao1G6S0=.17f24dfe-94ef-4738-889d-2daa00e5725b@github.com>
 <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
 <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@
 github.com>
 <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com>
 <oloAmS2y0tCsZtUv5kkaEGOOJZqw7FYhfqllwpP36Go=.afb5ad6c-49ac-4481-999d-4219a19aebfa@github.com>
 <NMCEunpOL82cZ-X-J6io4GPQmYBYFIUAFpXkFvZ4CnM=.dc1dfd78-6c00-466e-95b9-c7832d1eb077@github.com>
 <quOtN5QjPbF6HTKH8qcsO5McKDxh5meIlmXnPcHhPqc=.f50dd161-025f-44ef-ba30-a7a61d6c312e@github.com>
Message-ID: <bNtk6oBDqzFvLtRAvNeDa0aPX4apWMM46tiiDFoZA8o=.9478ae99-d827-4da6-a128-caa40248ca2b@github.com>

On Tue, 4 Mar 2025 01:37:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Do we still have a "suspension disabler" that would prevent the suspend from being processed by the mutex blocking?
>>>
>> We have `JavaThread::_is_disable_suspend` for JVMTI, but that only makes the target ignore the `ThreadSelfSuspensionHandshake` (second part of the suspend mechanism), it doesn't prevent the `SuspendThreadHandshake` (first part) from being executed. The suspender considers the target as suspended after the first handshake is done. (Seems this `_is_disable_suspend` should have prevented the first part instead but I'm guessing it wasn't as straightforward without introducing deadlocks). But also note we have the same issue for other events so we need a general solution.
>
> Let me see if I have the sequence of events correct:
> - we have a thread leaving Java to enter the VM, in this case to post a single-step event, which is not suspended
> - when trying to acquire the JvmtiThreadState_lock the thread blocks and becomes handshake/safepoint-safe and is then suspended
> - the thread acquires the lock and goes to post the event but because it has now been suspended it is an error to do so
> 
> So what we need is a way to disable suspension so that the transient/temporary switch to _thread_blocked does not allow a suspend request to be processed. I think that is preferable to trying to find where to add a place to check for suspension and actually suspend it.
> 
> But how is any of this new?

Yes, that's exactly what's happening. I think the issue with blocking suspend requests while being _thread_blocked is that we might create deadlocks.

> But how is any of this new?
>
We probably never checked for this scenario until this test was added in JDK-8284161. Since that moment we started checking the single step case. Looking at the code history, method `JvmtiExport::get_jvmti_thread_state()` (that leads to the blocked state) was only added later in JDK-8312174, on September 11, 2023. The first reported failure was September 17, 2023.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1980213926

From ccheung at openjdk.org  Tue Mar  4 23:03:39 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 4 Mar 2025 23:03:39 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log
Message-ID: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>

Always include the ArchiveRelocationMode in the CDS info log. Before this fix, ArchiveRelocationMode is not in the log if it is set to 0.
The ArchiveRelocationMode default value was set to 1 about 2 years ago. Some tests need to be updated accordingly.

Testing:

- ran the modified tests manually on linux-x64
- tier1

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

Commit messages:
 - minor changes to test cases
 - 8325132: CDS: Make sure the ArchiveRelocationMode is always printed in the log

Changes: https://git.openjdk.org/jdk/pull/23878/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23878&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325132
  Stats: 18 lines in 4 files changed: 10 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23878/head:pull/23878

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

From dlong at openjdk.org  Tue Mar  4 23:14:20 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 4 Mar 2025 23:14:20 GMT
Subject: Integrated: 8336042: Caller/callee param size mismatch in
 deoptimization causes crash
In-Reply-To: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
References: <4MjR9hdInhuJduDqpTqpGiyo_M_JQ6pM2g5_TgzcSTg=.16037e60-de66-4d0b-861b-19be80ff2751@github.com>
Message-ID: <-DOch4HtWdaPuapC0aBkemPls96miNahQpfaqEwSyog=.4e7dddaf-6517-4b84-88f2-5833fb19054c@github.com>

On Tue, 11 Feb 2025 07:59:01 GMT, Dean Long <dlong at openjdk.org> wrote:

> When calling a MethodHandle linker, such as linkToStatic, we drop the last argument, which causes a mismatch between what the caller pushed and what the callee received.  In deoptimization, we check for this in several places, but in one place we had outdated code.  See the bug for the gory details.
> 
> In this PR I add asserts and a test to reproduce the problem, plus the necessary fixes in deoptimizations.  There are other inefficiencies in deoptimization that I didn't address, hoping to simplify the fix for backports.
> 
> Some platforms align locals according to the caller during deoptimization, while some align locals according to the callee.  The asserts I added compute locals both ways and check that they are still within the frame.  I attempted this on all platforms, but am only able to test x64 and aarch64.  I need help testing those asserts for arm32, ppc, riscv, and s390.

This pull request has now been integrated.

Changeset: 20ea218c
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20ea218ce52f79704445acfe2d4a3dc9d04e86d2
Stats:     161 lines in 11 files changed: 147 ins; 3 del; 11 mod

8336042: Caller/callee param size mismatch in deoptimization causes crash

Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Reviewed-by: pchilanomate, rrich, vlivanov, never

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

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

From dholmes at openjdk.org  Wed Mar  5 02:27:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Mar 2025 02:27:52 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v4]
In-Reply-To: <bNtk6oBDqzFvLtRAvNeDa0aPX4apWMM46tiiDFoZA8o=.9478ae99-d827-4da6-a128-caa40248ca2b@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
 <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com>
 <lKSu4UoGBLaWqEQbM2lJ0ctU5sDPZNkZtFfVNSJdwXs=.5f5a530f-f4f7-4715-a109-c913d38ad373@github.com>
 <x9aEMsQnMrC5ikLH-pbRzGF6EtkkAXppinbZIswVydI=.2d0d18d8-3af2-4f84-928f-95a384f846c7@github.com>
 <FpigHhXOb9nISzF_4EqAR5fzM6pUhVtpTyz7fXqd7_A=.13e96a32-e426-4ee2-8401-7337ca34367c@github.com>
 <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com>
 <iv39Wpp0MFwwesm5NI3ZvZD-xDnFyk4kZMpd19EZ30w=.b0b26989-7499-4b70-97ae-97e19138fe89@github.com>
 <WPY1X633YLLzKWRGX4RJma0CF983CGb1bSMrMs815jM=.084998ec-5bd2-4df5-8948-2161b4c6dd92@github.com>
 <azWxxjE8kLgJpSAiU4SAOk_E4ggzuN_rdoUHxbKHpE4=.275aa5f2-e7e7-4b6e-ad28-a3f34613b1e2@github.com>
 <DTJzFg5YGxLmof32AHTbpGnbIqUO_ygljkHGzhi0pKY=.c68129f6-dbab-4be9-b286-f5d892be60e6@github.com>
 <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x
 YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com>
 <ATSNFuB3otIkeyutW0m0RZHb_OA6BQPxgVanqPUHcAk=.ea8402a7-7058-4edc-aff8-0d6e48a4cedf@github.com>
 <ghaunIfZWap8c9LPz8jpYA_8KFTUhMkDZ1gkwD8kM2E=.cea3a66a-cb87-4464-a3b3-c5a9110fc75b@github.com>
 <tfNnOivL70wmw5IJ0catb58ef4ssrcmeztdgq_H525k=.432a5a11-afd1-4c6f-b24e-297e912ecb4d@github.com>
 <cZf3RuYW5CuMeRXOiJcepc70WK0eY5DITnZh1Elx4mM=.1a7e9d1d-b4a7-4cbb-b6a2-47b21f7aea52@github.com>
 <Bctrj8H3ZpTmh4JxhPpbEkG5m18Qa0roptqVW9czRKQ=.12d8658b-891c-44f9-8717-454dbecd8927@github.com>
 <uUzETr66Gr6wUUB54oHOJJcjemTcKgLFEwB-AdPp1pg=.5209349d-4fe7-48fa-9459-9f3a4555ff16@github.com>
 <RyyM64wPq5iN-sAEvt6SZidNvW51J4HqVzcTG7bNcwY=.56c40bb7-2974-4e00-9b01-3a99041edbff@github.com>
 <x-bxlwRSaJZdwXbU9zsYvgooLlAu3DX5Cj8kao1G6S0=.17f24dfe-94ef-4738-889d-2daa00e5725b@github.com>
 <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
 <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@
 github.com>
 <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com>
 <oloAmS2y0tCsZtUv5kkaEGOOJZqw7FYhfqllwpP36Go=.afb5ad6c-49ac-4481-999d-4219a19aebfa@github.com>
 <NMCEunpOL82cZ-X-J6io4GPQmYBYFIUAFpXkFvZ4CnM=.dc1dfd78-6c00-466e-95b9-c7832d1eb077@github.com>
 <quOtN5QjPbF6HTKH8qcsO5McKDxh5meIlmXnPcHhPqc=.f50dd161-025f-44ef-ba30-a7a61d6c312e@github.com>
 <bNtk6oBDqzFvLtRAvNeDa0aPX4apWMM46tiiDFoZA8o=.9478ae99-d827-4da6-a128-caa40248ca2b@github.com>
Message-ID: <jLBfpzedrVSy-iGkO5nM005gczCXcmhSTbRPjClweWQ=.fb65f8a4-b1dd-418e-a8a4-31e802552477@github.com>

On Tue, 4 Mar 2025 20:54:13 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Let me see if I have the sequence of events correct:
>> - we have a thread leaving Java to enter the VM, in this case to post a single-step event, which is not suspended
>> - when trying to acquire the JvmtiThreadState_lock the thread blocks and becomes handshake/safepoint-safe and is then suspended
>> - the thread acquires the lock and goes to post the event but because it has now been suspended it is an error to do so
>> 
>> So what we need is a way to disable suspension so that the transient/temporary switch to _thread_blocked does not allow a suspend request to be processed. I think that is preferable to trying to find where to add a place to check for suspension and actually suspend it.
>> 
>> But how is any of this new?
>
> Yes, that's exactly what's happening. I think the issue with blocking suspend requests while being _thread_blocked is that we might create deadlocks.
> 
>> But how is any of this new?
>>
> We probably never checked for this scenario until this test was added in JDK-8284161. Since that moment we started checking the single step case. Looking at the code history, method `JvmtiExport::get_jvmti_thread_state()` (that leads to the blocked state) was only added later in JDK-8312174, on September 11, 2023. The first reported failure was September 17, 2023.

I don't think we should block suspend requests in all cases of being `_thread_blocked`, but `get_jvmti_thread_state` is a special case. We either need to have a general suspension suppression mechanism (which I thought already existed - but may it was in old code), or we need to special-case the acquisition of the `Thread_State_lock`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1980577092

From dholmes at openjdk.org  Wed Mar  5 05:36:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Mar 2025 05:36:02 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging [v2]
In-Reply-To: <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>
Message-ID: <BCG_xXT9qXp_KiyCnYeUKr0PB27oTgYPAL7Q3NQN4lI=.ee7a8a9b-432f-4dd0-9ddb-018bde29729f@github.com>

On Tue, 4 Mar 2025 19:45:33 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
>> 
>> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
>> 
>> Here is example log output with the change:
>> 
>> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
>> 
>> 
>> 
>> ### Test
>> - [x] Tire1
>> - [x] Tire2
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use format %d instead of INT32_FORMAT

LGTM. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23838#pullrequestreview-2659973145

From dholmes at openjdk.org  Wed Mar  5 05:36:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Mar 2025 05:36:02 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging [v2]
In-Reply-To: <4160dyZzw-tg_bD0l0rtEVRahzzcwtD335DOhuno7jA=.2b08d927-b78b-4c2e-b5f5-0da12ce0101a@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <DTIjyA5H6GyDEYiVeZhEllnBdfQ5iK8IlDpYidToRsE=.695d7e11-d12e-4b98-a0ac-d67c73796617@github.com>
 <9jg9KyaEksmhfxskkThyfZz0c8ZVr9eP_91nMJXz5UI=.e866c6ac-0810-4de4-bf85-93bd90fc270b@github.com>
 <HYGN6RdCJTLnu9xT_8BBmMN1s9X5rIJiGUmUCwc1q7E=.9a726bff-a279-4317-8985-948b2264768d@github.com>
 <wKY52pbBvSGQxgIF0LkDSff-8ZEBKZVIJFABfwgMQCg=.27ba9aa3-3375-4fac-9838-06062d02b53c@github.com>
 <FoRbb5N-pygbUOqr0lYMezY5MrnAQHLNVWn4bEbmycc=.639db57a-9557-40ec-ad00-3479645c5216@github.com>
 <OKcTiJE9Y64_FdLqeNO2YhEFpktyMzBR6XmGOA36Lyw=.78793734-8e18-41bc-9ffa-5aa3330e22a4@github.com>
 <4160dyZzw-tg_bD0l0rtEVRahzzcwtD335DOhuno7jA=.2b08d927-b78b-4c2e-b5f5-0da12ce0101a@github.com>
Message-ID: <T4c5J3IdlevgaCugANnvsnDq18zr8qxrGA4ywyc01RA=.8f2006cc-5552-46b0-8a88-97820071ca84@github.com>

On Tue, 4 Mar 2025 19:42:17 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> I have updated the PR to use `%d `.
>
>> Maybe we should get rid of INT32_FORMAT too?
> 
> Thanks Coleen, do you mean in the entire repo? I'll follow up on it with another PR if needed.

INT32_FORMAT should be used for int32_t. The question then is whether we ever really need int32_t given we have no supported platforms that don't use 32-bit int.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23838#discussion_r1980724479

From dholmes at openjdk.org  Wed Mar  5 05:59:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 5 Mar 2025 05:59:56 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
Message-ID: <fWGXKCfs8zO1UXQfq4085-LcAahtOqmCuLFrtvfngV4=.c395a3dc-f1e2-4541-8da0-5001f196621c@github.com>

On Tue, 4 Mar 2025 01:43:29 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
> 
> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
> 
> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.

I'm okay with updating the tests. I don't think any tests specifically targeting C2 should simply be using -server. Or -client for that matter.

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2699947384

From shade at openjdk.org  Wed Mar  5 08:46:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 5 Mar 2025 08:46:53 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging [v2]
In-Reply-To: <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>
Message-ID: <vaqrKXNu3SC3Kb1JGrV3aBfY7NdXhnGDG7gZ0YtCL3g=.a70dc35c-b674-4332-a531-848814f617c8@github.com>

On Tue, 4 Mar 2025 19:45:33 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
>> 
>> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
>> 
>> Here is example log output with the change:
>> 
>> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
>> 
>> 
>> 
>> ### Test
>> - [x] Tire1
>> - [x] Tire2
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use format %d instead of INT32_FORMAT

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23838#pullrequestreview-2660359415

From schernyshev at openjdk.org  Wed Mar  5 10:35:14 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 5 Mar 2025 10:35:14 GMT
Subject: Integrated: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <ZQH-mksU79ohGcjBhaTu5GclLtV1cftF-wAiWQazxco=.90f7e782-010c-4da6-bfeb-4e8d53c4d0f1@github.com>

On Thu, 31 Oct 2024 15:00:25 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 to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

This pull request has now been integrated.

Changeset: de29ef3b
Author:    Sergey Chernyshev <schernyshev at openjdk.org>
Committer: Dmitry Chuyko <dchuyko at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de29ef3bf3a029f99f340de9f093cd20544217fd
Stats:     491 lines in 9 files changed: 449 ins; 3 del; 39 mod

8343191: Cgroup v1 subsystem fails to set subsystem path

Co-authored-by: Severin Gehwolf <sgehwolf at openjdk.org>
Reviewed-by: sgehwolf, mbaesken

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

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

From syan at openjdk.org  Wed Mar  5 12:58:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Mar 2025 12:58:01 GMT
Subject: RFR: 8351115: Test AOTClassLinkingVMOptions.java fails after
 JDK-8348322
In-Reply-To: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>
References: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>
Message-ID: <3MEs41KEzImgP_H28-Kas3oFi_fzJJOC2iRTMgw6vys=.194ca3eb-848a-4b98-b5bf-df26961e4656@github.com>

On Tue, 4 Mar 2025 06:37:23 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java fails "VM option 'AOTInvokeDynamicLinking' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions" after JDK-8348322. This PR add JVM option '-XX:+UnlockDiagnosticVMOptions' to make test run passes.
> 
> Change has been verified locally, test-fix only, no risk.

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23883#issuecomment-2700852730

From syan at openjdk.org  Wed Mar  5 12:58:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 5 Mar 2025 12:58:02 GMT
Subject: Integrated: 8351115: Test AOTClassLinkingVMOptions.java fails after
 JDK-8348322
In-Reply-To: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>
References: <H-ciZPy17yss-zlvs_1GEhDDBwkOtnnX5yz2OqXwqTA=.456ec780-53c6-4fa7-bdb0-1f3f973d0c8c@github.com>
Message-ID: <TTa5Q-FSZlWAf9kWlsznw-yg8X2xXFvwfcF_TGRapTc=.b15f03b1-8b38-4217-a4e5-f15a130e83bd@github.com>

On Tue, 4 Mar 2025 06:37:23 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java fails "VM option 'AOTInvokeDynamicLinking' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions" after JDK-8348322. This PR add JVM option '-XX:+UnlockDiagnosticVMOptions' to make test run passes.
> 
> Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: 062b7c73
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/062b7c7348453e6a96c311082b112291913dc1d9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8351115: Test AOTClassLinkingVMOptions.java fails after JDK-8348322

Reviewed-by: dholmes, iklam

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

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

From jsjolen at openjdk.org  Wed Mar  5 15:27:14 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Mar 2025 15:27:14 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v3]
In-Reply-To: <4Bmzepx0oatn_NqbrzEdCMEQCBBpPwV1VW7KymjdrUQ=.09ea6870-2d00-4059-acb5-df53b72a25ef@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4Bmzepx0oatn_NqbrzEdCMEQCBBpPwV1VW7KymjdrUQ=.09ea6870-2d00-4059-acb5-df53b72a25ef@github.com>
Message-ID: <O9u-iH-dJXPzONXQCpaCnyNwgJlg1Lq8yBNJbueVzuU=.2461f8fd-d17b-4a1d-95bc-1ea79ecd91ca@github.com>

On Thu, 6 Feb 2025 20:23:32 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

Hi,

Thanks for waiting.

I understand, I think, more or less what this does on the VM side now. I think that we can simplify the code for the cases when we set an error and don't write any error message.

src/hotspot/os/posix/attachListener_posix.cpp line 150:

> 148:   }
> 149: 
> 150:   void complete(jint res, bufferedStream* st) override;

Style: Put brackets together `{}`

src/hotspot/os/posix/attachListener_posix.cpp line 152:

> 150:   void complete(jint res, bufferedStream* st) override;
> 151: 
> 152:   virtual ReplyWriter* get_reply_writer() override {

Style: No need for both `virtual` and `override`.

src/hotspot/os/windows/attachListener_windows.cpp line 128:

> 126:     if (!fSuccess) {
> 127:       log_error(attach)("pipe write error (%d)", GetLastError());
> 128:       return -1;

Style wish: Could you rename `fSuccess` to something like  `write_success`?

src/hotspot/os/windows/attachListener_windows.cpp line 159:

> 157:   void complete(jint result, bufferedStream* result_stream) override;
> 158: 
> 159:   virtual ReplyWriter* get_reply_writer() override {

Style: virtual && override unnecessary

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

> 61: class attachStream : public bufferedStream {
> 62:   AttachOperation::ReplyWriter* _reply_writer;
> 63:   bool _allow_streaming;

Is this `const`?

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

> 64:   jint _result;
> 65:   bool _result_set;
> 66:   bool _result_written;

It seems like `_result_written` implies `_result_set`? You can do this:

```c++
enum class ResultState { Unset; Set; Written; };
ResultState _result_state;
jint _result;


And then have the `ResultState` transition from `Unset` to `Set` to `Written`.

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

> 135:       if (!_error) {
> 136:         _error = !_reply_writer->write_fully(str, (int)len);
> 137:       }

What happens if we're in  `is_streaming()` but the result isn't written? That breaks the protocol. At least add an assert that `_result_written` is set to true.

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

> 211: }
> 212: 
> 213: static void get_properties(AttachOperation* op, attachStream* out, Symbol* serializePropertiesMethod) {

In this function you have to remember to set the result, otherwise you'll accidentally drop the result. If you return `jint`, you're forced to remember to write a  `return`.

I'd say that you should revert the changes for this function, and instead have the callers of this method set the result code.

In fact, revert this kind of change for all functions in `AttachOperationFunctionInfo funcs[]` and have all send the return code. That simplifies the pattern significantly, as you only need to set the result early if you want to be streaming your output. That also minimizes the changeset, win-win.

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

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2660667054
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981124805
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981125292
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981131134
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981131731
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981377287
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981373628
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981629725
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981584499

From gziemski at openjdk.org  Wed Mar  5 15:32:03 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 5 Mar 2025 15:32:03 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag
In-Reply-To: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
Message-ID: <K8BYn1xaxRw9qtZfubPZH9co9AlwnV8LTgHBYwttmYg=.85c4eaf5-3502-420c-a415-97f962b427e4@github.com>

On Tue, 25 Feb 2025 09:49:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
> Tests:
> linux-x64-debug, gtest:NMT* and runtime/NMT*

Changes requested by gziemski (Reviewer).

Changes requested by gziemski (Reviewer).

src/hotspot/share/cds/metaspaceShared.cpp line 1475:

> 1473:              (address)archive_space_rs.base() == base_address, "Sanity");
> 1474:       // Register archive space with NMT.
> 1475:       MemTracker::record_virtual_memory_tag(archive_space_rs.base(), archive_space_rs.size(), mtClassShared);

The pattern here is:

`something.base(), something.base.size()`

instead of doing this over and over again, why can't we just pass `something` to MemTracker::record_virtual_memory_tag() and let it figure out `base` and `size` itself?

src/hotspot/share/cds/metaspaceShared.cpp line 1548:

> 1546:       return nullptr;
> 1547:     }
> 1548:     // NMT: fix up the space tags

What exactly needs to be fixed here?

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

PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2661498707
PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2661515550
PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1981647511
PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1981635746

From gziemski at openjdk.org  Wed Mar  5 15:35:52 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 5 Mar 2025 15:35:52 GMT
Subject: RFR: 8350565: NMT: remaining memory flag/type to be replaced with
 memory tag
In-Reply-To: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
References: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
Message-ID: <UZ3V3RBS87pnDh7A7ZnFmBSUdKhPvaPx6QVsvXiBsy4=.79d0aed3-59ae-4206-b9a1-1a53c16894ca@github.com>

On Tue, 25 Feb 2025 09:38:22 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> There were some remaining flag or type for Memory Tag contexts.
> 
> Tests:
> gtest:NMT* and runtime/NMT sets of tasks all passed.

Thank you very much for cleaning up this technical debt stuff. I really appreciate this work!

LGTM

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

Marked as reviewed by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23769#pullrequestreview-2661536284

From jsjolen at openjdk.org  Wed Mar  5 16:26:17 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Mar 2025 16:26:17 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v34]
In-Reply-To: <dbApB_oGdCi_Xl-Un8RmQxtZSEMg2xN55F-vAtXKK9M=.56b42fe1-3494-48d2-9448-a4900d05de15@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <dbApB_oGdCi_Xl-Un8RmQxtZSEMg2xN55F-vAtXKK9M=.56b42fe1-3494-48d2-9448-a4900d05de15@github.com>
Message-ID: <V4UhKGn9pVMeKubGH7QLW4aaSl9Ku4R4gyb7YZhYx58=.f45ae760-8191-4f74-9365-aef4ddebb4b2@github.com>

On Tue, 4 Mar 2025 11:20:05 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cases for doing reserve or commit the same region twice.

Still working through the files, a few more comments.

src/hotspot/share/nmt/memReporter.cpp line 451:

> 449:     });
> 450: 
> 451:     if (reserved_and_committed)

Missing braces

src/hotspot/share/nmt/regionsTree.hpp line 37:

> 35: // for processing the tree nodes in a shorter and more meaningful way.
> 36: class RegionsTree : public VMATree {
> 37:  private:

Remote private, not needed.

src/hotspot/share/nmt/regionsTree.hpp line 56:

> 54:       NodeHelper() : _node(nullptr) { }
> 55:       NodeHelper(Node* node) : _node(node) { }
> 56:       inline bool is_valid() { return _node != nullptr; }

Missing `const`

src/hotspot/share/nmt/regionsTree.inline.hpp line 33:

> 31: void RegionsTree::visit_committed_regions(const ReservedMemoryRegion& rgn, F func) {
> 32:   position start = (position)rgn.base();
> 33:   size_t end = (size_t)rgn.end() + 1;

Can we `static_cast<size_t>(rgn.end())` instead?

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 60:

> 58:     if (tracker == nullptr) return false;
> 59:     _tracker = new (tracker) VirtualMemoryTracker(level == NMT_detail);
> 60:     return _tracker->tree() != nullptr;

@afshin-zafari , `_tracker->tree()` can never be null anymore. In the future we should do a PR where we change it to return a reference.

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

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2661644343
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1981728394
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1981743711
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1981745212
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1981747136
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1981755525

From xpeng at openjdk.org  Wed Mar  5 16:35:59 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 5 Mar 2025 16:35:59 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging [v2]
In-Reply-To: <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>
Message-ID: <8zJy37LATK37nipDhOI9m236hgBQTqtJ0514pKmn2vs=.1c712d11-3bb8-4d3f-abfa-51110fd62eea@github.com>

On Tue, 4 Mar 2025 19:45:33 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
>> 
>> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
>> 
>> Here is example log output with the change:
>> 
>> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
>> 
>> 
>> 
>> ### Test
>> - [x] Tire1
>> - [x] Tire2
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use format %d instead of INT32_FORMAT

Thank you all for the discussions and approvals!

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

PR Comment: https://git.openjdk.org/jdk/pull/23838#issuecomment-2701467680

From duke at openjdk.org  Wed Mar  5 16:36:00 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Mar 2025 16:36:00 GMT
Subject: RFR: 8350854: Include thread counts in safepoint logging [v2]
In-Reply-To: <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
 <dTJ7rKDgRV35ItqS8jTXPTP6qX6qZHYfEEbd-uRZRGY=.00ec1357-c04c-417b-82a8-eebd548c8686@github.com>
Message-ID: <fatzOJILZ4MBeTx61VR5NZrOuewFrGO0BB3IcKyHx24=.b613ab1b-2390-4500-bf7d-bee35caeb7a5@github.com>

On Tue, 4 Mar 2025 19:45:33 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
>> 
>> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
>> 
>> Here is example log output with the change:
>> 
>> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
>> 
>> 
>> 
>> ### Test
>> - [x] Tire1
>> - [x] Tire2
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use format %d instead of INT32_FORMAT

@pengxiaolong 
Your change (at version 874791f409bf4cf89cb944ed9bd1a93fc271b88a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23838#issuecomment-2701469052

From xpeng at openjdk.org  Wed Mar  5 16:39:00 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 5 Mar 2025 16:39:00 GMT
Subject: Integrated: 8350854: Include thread counts in safepoint logging
In-Reply-To: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
References: <HVzjKPXbqWDowE55XdeC1vAjOcqZaAwFXamRZ0qzdLU=.ce316c04-8cb2-4d03-90a2-c674c5d23f6b@github.com>
Message-ID: <canFQgMN-mFfLvaz1MoB9wLIylsI_z-Q2f-K9FCr3Ws=.bb9c71bb-c54c-406a-8d0b-054f5134f89f@github.com>

On Fri, 28 Feb 2025 09:16:19 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> The PR is to add thread counts in safepoint logging. In recent work, we notice the number of Java thread may affects time to reach/leave safepoint hardly in some cases, but safepoint logging doesn't have thread counts, thread counts are printed only with 'safepoint+stats' log. 
> 
> Given in many cases, we only have `safepoint` log enabled, not `safepoint+stats`, it make sense to add thread count to 'safepoint' logging. 
> 
> Here is example log output with the change:
> 
> [15.240s][info][safepoint      ] Safepoint "ShenandoahFinalMarkStartEvac", Time since last: 3527459 ns, Reaching safepoint: 78666 ns, At safepoint: 821625 ns, Leaving safepoint: 1472167 ns, Total: 2372458 ns, Threads: 3 runnable, 1038 total
> 
> 
> 
> ### Test
> - [x] Tire1
> - [x] Tire2

This pull request has now been integrated.

Changeset: 61d9ab97
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61d9ab9717783e5bb0faa555f794499d0e5b3fdb
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8350854: Include thread counts in safepoint logging

Reviewed-by: shade, dholmes

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

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

From kbarrett at openjdk.org  Wed Mar  5 19:06:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 5 Mar 2025 19:06:53 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v5]
In-Reply-To: <8j8Q9lFaUqpJ-00YvaTbQpsR_mP3r6hukpeWiqss1yk=.0995063a-99d9-4b86-ab99-1b38f387a8a8@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
 <8j8Q9lFaUqpJ-00YvaTbQpsR_mP3r6hukpeWiqss1yk=.0995063a-99d9-4b86-ab99-1b38f387a8a8@github.com>
Message-ID: <d6ZtXHTWxJPfr12XYfeRgovnLEeyzaz-v3GEpXEOQ3M=.0a5b2abc-a5b6-4b7d-8819-9be34fde3cfe@github.com>

On Tue, 4 Mar 2025 23:00:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
>> Tested with SA tests locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove more friends.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23897#pullrequestreview-2662217792

From coleenp at openjdk.org  Wed Mar  5 19:31:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Mar 2025 19:31:57 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v5]
In-Reply-To: <8j8Q9lFaUqpJ-00YvaTbQpsR_mP3r6hukpeWiqss1yk=.0995063a-99d9-4b86-ab99-1b38f387a8a8@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
 <8j8Q9lFaUqpJ-00YvaTbQpsR_mP3r6hukpeWiqss1yk=.0995063a-99d9-4b86-ab99-1b38f387a8a8@github.com>
Message-ID: <5H2L7HiXE3L6CDr_OQl5nG6axx6KD2F36rwTzLBwNoM=.273f0844-98de-423c-a298-aa3f65adc44f@github.com>

On Tue, 4 Mar 2025 23:00:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
>> Tested with SA tests locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove more friends.

Thanks Kim.  I'm going to continue to claim this is trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/23897#issuecomment-2701871901

From coleenp at openjdk.org  Wed Mar  5 19:31:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Mar 2025 19:31:58 GMT
Subject: Integrated: 8351165: Remove unused includes from vmStructs
In-Reply-To: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
Message-ID: <8cF_zUKZyH6XE8iGcDsw2x0hUfSy3ZiAAOsgzXXb7dE=.b436e37d-8a2b-4fce-90df-40ec3691a5a4@github.com>

On Tue, 4 Mar 2025 12:56:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
> Tested with SA tests locally.

This pull request has now been integrated.

Changeset: 11a37c82
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11a37c829c12d064874416a7b242596cf23972e5
Stats:     39 lines in 9 files changed: 0 ins; 32 del; 7 mod

8351165: Remove unused includes from vmStructs

Reviewed-by: kbarrett

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

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

From iveresov at openjdk.org  Wed Mar  5 22:38:03 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 5 Mar 2025 22:38:03 GMT
Subject: RFR: 8350148: Native stack overflow when writing Java heap objects
 into AOT cache
In-Reply-To: <ecYJOXcu9aVwAzcPfOi7b5Jajth4JXcGsiHigLs_Q9c=.4de0ac02-e5d0-4f16-8e03-cdfdc5a51848@github.com>
References: <ecYJOXcu9aVwAzcPfOi7b5Jajth4JXcGsiHigLs_Q9c=.4de0ac02-e5d0-4f16-8e03-cdfdc5a51848@github.com>
Message-ID: <DSZF9FrQvxSwaPw4zDpjdE-2K5GH9N7FwJYe9hLKsiE=.34cbc757-96ca-4829-8011-7a1496ccf2a0@github.com>

On Sun, 16 Feb 2025 05:16:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this patch that fixes a problem that was found in the Leyden repo: when finding all cacheable heap objects with recursive calls to `HeapShared::archive_reachable_objects_from()`, very deep reference chains could cause overflow on the native stack. 
> 
> The fix is to do the recursion using a side table, without making any recursive calls.
> 
> Note: the kind of deep reference chains do not seem to happen with the mainline. It happened in the Leyden repo only after we enabled the caching of `WeakReference` objects, which are not cacheable in the mainline.

Looks good

src/hotspot/share/cds/heapShared.cpp line 1351:

> 1349: 
> 1350: // Push all oops that are referenced by _referencing_obj onto the _stack.
> 1351: class HeapShared::ReferentPusher: public BasicOopIterateClosure {

Suggestion:

class HeapShared::ReferentPusher : public BasicOopIterateClosure {

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

Marked as reviewed by iveresov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23654#pullrequestreview-2662640308
PR Review Comment: https://git.openjdk.org/jdk/pull/23654#discussion_r1982273300

From sspitsyn at openjdk.org  Thu Mar  6 00:43:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 6 Mar 2025 00:43:04 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v4]
In-Reply-To: <jLBfpzedrVSy-iGkO5nM005gczCXcmhSTbRPjClweWQ=.fb65f8a4-b1dd-418e-a8a4-31e802552477@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
 <8-HgO8SF2c-Tquo2GXvc-dx-k8QTssjLALyC4f3biFU=.19c21169-3d8b-4fbb-baf7-4384c6f9613c@github.com>
 <lKSu4UoGBLaWqEQbM2lJ0ctU5sDPZNkZtFfVNSJdwXs=.5f5a530f-f4f7-4715-a109-c913d38ad373@github.com>
 <x9aEMsQnMrC5ikLH-pbRzGF6EtkkAXppinbZIswVydI=.2d0d18d8-3af2-4f84-928f-95a384f846c7@github.com>
 <FpigHhXOb9nISzF_4EqAR5fzM6pUhVtpTyz7fXqd7_A=.13e96a32-e426-4ee2-8401-7337ca34367c@github.com>
 <5_7J0S8xulRTzs5KrgjWQ6xpX0JSfDL6EDKyA1ubOVE=.943722af-59a2-4cce-a8fb-0c9153185d5f@github.com>
 <iv39Wpp0MFwwesm5NI3ZvZD-xDnFyk4kZMpd19EZ30w=.b0b26989-7499-4b70-97ae-97e19138fe89@github.com>
 <WPY1X633YLLzKWRGX4RJma0CF983CGb1bSMrMs815jM=.084998ec-5bd2-4df5-8948-2161b4c6dd92@github.com>
 <azWxxjE8kLgJpSAiU4SAOk_E4ggzuN_rdoUHxbKHpE4=.275aa5f2-e7e7-4b6e-ad28-a3f34613b1e2@github.com>
 <DTJzFg5YGxLmof32AHTbpGnbIqUO_ygljkHGzhi0pKY=.c68129f6-dbab-4be9-b286-f5d892be60e6@github.com>
 <7bpGTmRhvqsaoOonaC2Dp-CIxZArYH1YN2x
 YQ_rM9eo=.3760f743-e7fe-4857-b08c-b3555b66f3b6@github.com>
 <ATSNFuB3otIkeyutW0m0RZHb_OA6BQPxgVanqPUHcAk=.ea8402a7-7058-4edc-aff8-0d6e48a4cedf@github.com>
 <ghaunIfZWap8c9LPz8jpYA_8KFTUhMkDZ1gkwD8kM2E=.cea3a66a-cb87-4464-a3b3-c5a9110fc75b@github.com>
 <tfNnOivL70wmw5IJ0catb58ef4ssrcmeztdgq_H525k=.432a5a11-afd1-4c6f-b24e-297e912ecb4d@github.com>
 <cZf3RuYW5CuMeRXOiJcepc70WK0eY5DITnZh1Elx4mM=.1a7e9d1d-b4a7-4cbb-b6a2-47b21f7aea52@github.com>
 <Bctrj8H3ZpTmh4JxhPpbEkG5m18Qa0roptqVW9czRKQ=.12d8658b-891c-44f9-8717-454dbecd8927@github.com>
 <uUzETr66Gr6wUUB54oHOJJcjemTcKgLFEwB-AdPp1pg=.5209349d-4fe7-48fa-9459-9f3a4555ff16@github.com>
 <RyyM64wPq5iN-sAEvt6SZidNvW51J4HqVzcTG7bNcwY=.56c40bb7-2974-4e00-9b01-3a99041edbff@github.com>
 <x-bxlwRSaJZdwXbU9zsYvgooLlAu3DX5Cj8kao1G6S0=.17f24dfe-94ef-4738-889d-2daa00e5725b@github.com>
 <J6GfQL558QyaSeBd-WEHyahjkbB0qcucanJfz6AXEo4=.99bc11ae-c6db-4ee6-89c2-14379a762ac2@github.com>
 <BJO32meMNC2ZffZ_SqfO7Pj-vR6p0mt_RVVkhJNWAiU=.19fee650-1182-4c59-ab10-eb71c9e93e2d@
 github.com>
 <3wKYG3noSuPp2U24LLfDFyiWcTe-QHBlHvbb_wnhjEU=.c6b40bed-0e67-4d0e-a9d5-6a5d0645c547@github.com>
 <oloAmS2y0tCsZtUv5kkaEGOOJZqw7FYhfqllwpP36Go=.afb5ad6c-49ac-4481-999d-4219a19aebfa@github.com>
 <NMCEunpOL82cZ-X-J6io4GPQmYBYFIUAFpXkFvZ4CnM=.dc1dfd78-6c00-466e-95b9-c7832d1eb077@github.com>
 <quOtN5QjPbF6HTKH8qcsO5McKDxh5meIlmXnPcHhPqc=.f50dd161-025f-44ef-ba30-a7a61d6c312e@github.com>
 <bNtk6oBDqzFvLtRAvNeDa0aPX4apWMM46tiiDFoZA8o=.9478ae99-d827-4da6-a128-caa40248ca2b@github.com>
 <jLBfpzedrVSy-iGkO5nM005gczCXcmhSTbRPjClweWQ=.fb65f8a4-b1dd-418e-a8a4-31e802552477@github.com>
Message-ID: <NyT3BRfa9Kw9RSujicFzRw9_HQWf8x1CRwNFSLQgE2E=.d78ca8a5-d7fc-413a-bafd-427478e380d2@github.com>

On Wed, 5 Mar 2025 02:24:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes, that's exactly what's happening. I think the issue with blocking suspend requests while being _thread_blocked is that we might create deadlocks.
>> 
>>> But how is any of this new?
>>>
>> We probably never checked for this scenario until this test was added in JDK-8284161. Since that moment we started checking the single step case. Looking at the code history, method `JvmtiExport::get_jvmti_thread_state()` (that leads to the blocked state) was only added later in JDK-8312174, on September 11, 2023. The first reported failure was September 17, 2023.
>
> I don't think we should block suspend requests in all cases of being `_thread_blocked`, but `get_jvmti_thread_state` is a special case. We either need to have a general suspension suppression mechanism (which I thought already existed - but may it was in old code), or we need to special-case the acquisition of the `Thread_State_lock`.

> Let me see if I have the sequence of events correct:
>  - we have a thread leaving Java to enter the VM, in this case to post a single-step event, which is not suspended
>   - when trying to acquire the JvmtiThreadState_lock the thread blocks and becomes handshake/safepoint-safe and is then suspended
>   - the thread acquires the lock and goes to post the event but because it has now been suspended it is an error to do so

This is almost right but let me add a couple of details.
A suspend request was processed/registered/accepted at the handshake/safepoint-safe point but physical suspension in the `ThreadSelfSuspensionHandshake` has not happened yet which created a problem. Also, the problem is not that the thread goes to post the event. Suspension and event posting are racy by design. The problem is that the `SingleStep` events for this thread are also enabled at the handshake/safepoint-safe point after the suspend request was processed/registered/accepted.

> So what we need is a way to disable suspension so that the transient/temporary switch to _thread_blocked does not allow a suspend request to be processed. I think that is preferable to trying to find where to add a place to check for suspension and actually suspend it.

I'm also thinking toward this direction. The best way to fix this would be to disallow processing/accepting new suspend requests in `MutexLocker mu(JvmtiThreadState_lock)` which is executed in context of `get_jvmti_thread_state()` call:

inline JvmtiThreadState* JvmtiThreadState::state_for(JavaThread *thread, Handle thread_handle) {
  // In a case of unmounted virtual thread the thread can be null.
  JvmtiThreadState* state = thread_handle == nullptr ? thread->jvmti_thread_state() :
                                                java_lang_Thread::jvmti_thread_state(thread_handle());
  if (state == nullptr) {
    MutexLocker mu(JvmtiThreadState_lock);
  . . .

Unfortunately, it looks like it is tricky to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23490#discussion_r1982384039

From amenkov at openjdk.org  Thu Mar  6 02:18:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Mar 2025 02:18:35 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v4]
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: <2VrvagcQ_c6vqMMaINqJ-DNTnXB_c8eAW4qo_yvtcvE=.ac41a25f-7e74-4bfd-9a85-bd7bd5ef7083@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/d074f2f7..5c87f9e4

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

  Stats: 105 lines in 3 files changed: 18 ins; 23 del; 64 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 amenkov at openjdk.org  Thu Mar  6 02:18:36 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Mar 2025 02:18:36 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v3]
In-Reply-To: <O9u-iH-dJXPzONXQCpaCnyNwgJlg1Lq8yBNJbueVzuU=.2461f8fd-d17b-4a1d-95bc-1ea79ecd91ca@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4Bmzepx0oatn_NqbrzEdCMEQCBBpPwV1VW7KymjdrUQ=.09ea6870-2d00-4059-acb5-df53b72a25ef@github.com>
 <O9u-iH-dJXPzONXQCpaCnyNwgJlg1Lq8yBNJbueVzuU=.2461f8fd-d17b-4a1d-95bc-1ea79ecd91ca@github.com>
Message-ID: <ZB4efJoqZqUUoPwiW2jFcQshzdntFNUAkfHETmTGJbA=.eec9ac57-4041-4978-85f8-834e1f50029a@github.com>

On Wed, 5 Mar 2025 10:29:21 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/os/posix/attachListener_posix.cpp line 150:
> 
>> 148:   }
>> 149: 
>> 150:   void complete(jint res, bufferedStream* st) override;
> 
> Style: Put brackets together `{}`

Fixed

> src/hotspot/os/posix/attachListener_posix.cpp line 152:
> 
>> 150:   void complete(jint res, bufferedStream* st) override;
>> 151: 
>> 152:   virtual ReplyWriter* get_reply_writer() override {
> 
> Style: No need for both `virtual` and `override`.

Fixed.

> src/hotspot/os/windows/attachListener_windows.cpp line 128:
> 
>> 126:     if (!fSuccess) {
>> 127:       log_error(attach)("pipe write error (%d)", GetLastError());
>> 128:       return -1;
> 
> Style wish: Could you rename `fSuccess` to something like  `write_success`?

This is general style in the file (I believe it came from MSDN examples), so I prefer to leave it as is for now

> src/hotspot/os/windows/attachListener_windows.cpp line 159:
> 
>> 157:   void complete(jint result, bufferedStream* result_stream) override;
>> 158: 
>> 159:   virtual ReplyWriter* get_reply_writer() override {
> 
> Style: virtual && override unnecessary

Fixed.

> src/hotspot/share/services/attachListener.cpp line 63:
> 
>> 61: class attachStream : public bufferedStream {
>> 62:   AttachOperation::ReplyWriter* _reply_writer;
>> 63:   bool _allow_streaming;
> 
> Is this `const`?

Right. Fixed.

> src/hotspot/share/services/attachListener.cpp line 66:
> 
>> 64:   jint _result;
>> 65:   bool _result_set;
>> 66:   bool _result_written;
> 
> It seems like `_result_written` implies `_result_set`? You can do this:
> 
> ```c++
> enum class ResultState { Unset; Set; Written; };
> ResultState _result_state;
> jint _result;
> 
> 
> And then have the `ResultState` transition from `Unset` to `Set` to `Written`.

Updated

> src/hotspot/share/services/attachListener.cpp line 213:
> 
>> 211: }
>> 212: 
>> 213: static void get_properties(AttachOperation* op, attachStream* out, Symbol* serializePropertiesMethod) {
> 
> In this function you have to remember to set the result, otherwise you'll accidentally drop the result. If you return `jint`, you're forced to remember to write a  `return`.
> 
> I'd say that you should revert the changes for this function, and instead have the callers of this method set the result code.
> 
> In fact, revert this kind of change for all functions in `AttachOperationFunctionInfo funcs[]` and have all send the return code. That simplifies the pattern significantly, as you only need to set the result early if you want to be streaming your output. That also minimizes the changeset, win-win.

Updated as suggested. But github considers diff for the file as "large" :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982500667
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982501693
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982528121
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982502593
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982504691
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982517135
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982514245

From jiangli at openjdk.org  Thu Mar  6 02:18:43 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 02:18:43 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
Message-ID: <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>

> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
> 
> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
> 
> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.

Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:

 - Remove '-server' from all following tests.
   
   Add?@requires vm.flavor == "server" & !vm.emulatedClient since these tests run on c2:
   - compiler/c2/TestReduceAllocationAndHeapDump.java
   - compiler/inlining/InlineBimorphicVirtualCallAfterMorphismChanged.java
   
   These tests already have @requires?vm.compiler2.enabled:
   - compiler/c2/TestReduceAllocationAndLoadKlass.java
   - compiler/c2/TestReduceAllocationAndNonExactAllocate.java
   - compiler/c2/TestReduceAllocationAndNullableLoads.java
   - compiler/c2/TestReduceAllocationAndPointerComparisons.java
   - compiler/escapeAnalysis/TestIterativeEA.java
   
   Can run on c1/c2:
   - compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java
   
   Already have @requires vm.flavor == "server":
   - compiler/intrinsics/math/TestMinMaxIntrinsics.java
   - compiler/profiling/TestTypeProfiling.java
   - gc/stress/gcbasher/TestGCBasherWithG1.java
   - gc/stress/gcbasher/TestGCBasherWithParallel.java
   - gc/stress/gcbasher/TestGCBasherWithSerial.java
   
   Not compiler specific:
   - runtime/CDSCompressedKPtrs/XShareAuto.java
 - Revert src/hotspot/share/runtime/arguments.cpp.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23881/files
  - new: https://git.openjdk.org/jdk/pull/23881/files/fc285013..3189513d

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

  Stats: 25 lines in 15 files changed: 2 ins; 12 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23881/head:pull/23881

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

From jiangli at openjdk.org  Thu Mar  6 02:51:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 02:51:52 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
Message-ID: <9BfykHOVx3gX7DZXEcNgH7eVs1uPCLwNFDA4i-q9vmY=.cb5ed4ed-639f-4c98-82b1-10ef4edb5920@github.com>

On Thu, 6 Mar 2025 02:18:43 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove '-server' from all following tests.
>    
>    Add?@requires vm.flavor == "server" & !vm.emulatedClient since these tests run on c2:
>    - compiler/c2/TestReduceAllocationAndHeapDump.java
>    - compiler/inlining/InlineBimorphicVirtualCallAfterMorphismChanged.java
>    
>    These tests already have @requires?vm.compiler2.enabled:
>    - compiler/c2/TestReduceAllocationAndLoadKlass.java
>    - compiler/c2/TestReduceAllocationAndNonExactAllocate.java
>    - compiler/c2/TestReduceAllocationAndNullableLoads.java
>    - compiler/c2/TestReduceAllocationAndPointerComparisons.java
>    - compiler/escapeAnalysis/TestIterativeEA.java
>    
>    Can run on c1/c2:
>    - compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java
>    
>    Already have @requires vm.flavor == "server":
>    - compiler/intrinsics/math/TestMinMaxIntrinsics.java
>    - compiler/profiling/TestTypeProfiling.java
>    - gc/stress/gcbasher/TestGCBasherWithG1.java
>    - gc/stress/gcbasher/TestGCBasherWithParallel.java
>    - gc/stress/gcbasher/TestGCBasherWithSerial.java
>    
>    Not compiler specific:
>    - runtime/CDSCompressedKPtrs/XShareAuto.java
>  - Revert src/hotspot/share/runtime/arguments.cpp.

Thanks.

I decided to just revert arguments.cpp without withdrawing the PR. Updated affect hotspot tier1 tests. Please see details in my commit message for each test update: https://github.com/openjdk/jdk/pull/23881/commits/3189513db2a579427d55e062a137eea31b5e1a5e.

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2702649941

From dholmes at openjdk.org  Thu Mar  6 05:56:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 05:56:54 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
Message-ID: <1dx6hZk1YbPUl9q1rtXftVMUT1yHd4wwa2_aEqBMhTY=.ba3feb43-bd68-4803-8484-403c6b906861@github.com>

On Thu, 6 Mar 2025 02:18:43 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove '-server' from all following tests.
>    
>    Add?@requires vm.flavor == "server" & !vm.emulatedClient since these tests run on c2:
>    - compiler/c2/TestReduceAllocationAndHeapDump.java
>    - compiler/inlining/InlineBimorphicVirtualCallAfterMorphismChanged.java
>    
>    These tests already have @requires?vm.compiler2.enabled:
>    - compiler/c2/TestReduceAllocationAndLoadKlass.java
>    - compiler/c2/TestReduceAllocationAndNonExactAllocate.java
>    - compiler/c2/TestReduceAllocationAndNullableLoads.java
>    - compiler/c2/TestReduceAllocationAndPointerComparisons.java
>    - compiler/escapeAnalysis/TestIterativeEA.java
>    
>    Can run on c1/c2:
>    - compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java
>    
>    Already have @requires vm.flavor == "server":
>    - compiler/intrinsics/math/TestMinMaxIntrinsics.java
>    - compiler/profiling/TestTypeProfiling.java
>    - gc/stress/gcbasher/TestGCBasherWithG1.java
>    - gc/stress/gcbasher/TestGCBasherWithParallel.java
>    - gc/stress/gcbasher/TestGCBasherWithSerial.java
>    
>    Not compiler specific:
>    - runtime/CDSCompressedKPtrs/XShareAuto.java
>  - Revert src/hotspot/share/runtime/arguments.cpp.

@jianglizhou  this seems to now be a compiler team issue to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2702883441

From dholmes at openjdk.org  Thu Mar  6 06:14:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 06:14:52 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
Message-ID: <_mnGdermmAHz7Uc0ImXgngswbkF1RgXjycQKTQAiz9I=.da23ce88-3967-4891-9bd7-b2b0a04e76ab@github.com>

On Thu, 6 Mar 2025 02:18:43 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove '-server' from all following tests.
>    
>    Add?@requires vm.flavor == "server" & !vm.emulatedClient since these tests run on c2:
>    - compiler/c2/TestReduceAllocationAndHeapDump.java
>    - compiler/inlining/InlineBimorphicVirtualCallAfterMorphismChanged.java
>    
>    These tests already have @requires?vm.compiler2.enabled:
>    - compiler/c2/TestReduceAllocationAndLoadKlass.java
>    - compiler/c2/TestReduceAllocationAndNonExactAllocate.java
>    - compiler/c2/TestReduceAllocationAndNullableLoads.java
>    - compiler/c2/TestReduceAllocationAndPointerComparisons.java
>    - compiler/escapeAnalysis/TestIterativeEA.java
>    
>    Can run on c1/c2:
>    - compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java
>    
>    Already have @requires vm.flavor == "server":
>    - compiler/intrinsics/math/TestMinMaxIntrinsics.java
>    - compiler/profiling/TestTypeProfiling.java
>    - gc/stress/gcbasher/TestGCBasherWithG1.java
>    - gc/stress/gcbasher/TestGCBasherWithParallel.java
>    - gc/stress/gcbasher/TestGCBasherWithSerial.java
>    
>    Not compiler specific:
>    - runtime/CDSCompressedKPtrs/XShareAuto.java
>  - Revert src/hotspot/share/runtime/arguments.cpp.

test/hotspot/jtreg/runtime/CDSCompressedKPtrs/XShareAuto.java line 43:

> 41:     public static void main(String[] args) throws Exception {
> 42:         ProcessBuilder pb = ProcessTools.createLimitedTestJavaProcessBuilder(
> 43:             "-XX:+UnlockDiagnosticVMOptions",

This test was created specifically as a regression test because `-server` didn't work. I'm not sure it serves any purpose now. @iklam?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1982743025

From iklam at openjdk.org  Thu Mar  6 07:06:03 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Mar 2025 07:06:03 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <_mnGdermmAHz7Uc0ImXgngswbkF1RgXjycQKTQAiz9I=.da23ce88-3967-4891-9bd7-b2b0a04e76ab@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
 <_mnGdermmAHz7Uc0ImXgngswbkF1RgXjycQKTQAiz9I=.da23ce88-3967-4891-9bd7-b2b0a04e76ab@github.com>
Message-ID: <ngePVW3MKh3sWYEw6sM1qUWJvuiFzI3ynU5-4c5p5MQ=.88add105-e474-4d1f-9b48-9af62b1c208e@github.com>

On Thu, 6 Mar 2025 06:04:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove '-server' from all following tests.
>>    
>>    Add?@requires vm.flavor == "server" & !vm.emulatedClient since these tests run on c2:
>>    - compiler/c2/TestReduceAllocationAndHeapDump.java
>>    - compiler/inlining/InlineBimorphicVirtualCallAfterMorphismChanged.java
>>    
>>    These tests already have @requires?vm.compiler2.enabled:
>>    - compiler/c2/TestReduceAllocationAndLoadKlass.java
>>    - compiler/c2/TestReduceAllocationAndNonExactAllocate.java
>>    - compiler/c2/TestReduceAllocationAndNullableLoads.java
>>    - compiler/c2/TestReduceAllocationAndPointerComparisons.java
>>    - compiler/escapeAnalysis/TestIterativeEA.java
>>    
>>    Can run on c1/c2:
>>    - compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java
>>    
>>    Already have @requires vm.flavor == "server":
>>    - compiler/intrinsics/math/TestMinMaxIntrinsics.java
>>    - compiler/profiling/TestTypeProfiling.java
>>    - gc/stress/gcbasher/TestGCBasherWithG1.java
>>    - gc/stress/gcbasher/TestGCBasherWithParallel.java
>>    - gc/stress/gcbasher/TestGCBasherWithSerial.java
>>    
>>    Not compiler specific:
>>    - runtime/CDSCompressedKPtrs/XShareAuto.java
>>  - Revert src/hotspot/share/runtime/arguments.cpp.
>
> test/hotspot/jtreg/runtime/CDSCompressedKPtrs/XShareAuto.java line 43:
> 
>> 41:     public static void main(String[] args) throws Exception {
>> 42:         ProcessBuilder pb = ProcessTools.createLimitedTestJavaProcessBuilder(
>> 43:             "-XX:+UnlockDiagnosticVMOptions",
> 
> This test was created specifically as a regression test because `-server` didn't work. I'm not sure it serves any purpose now. @iklam?

I think the test still serves as a functional test: if an archive is specified, then -Xshare:auto is used by default.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1982800754

From alanb at openjdk.org  Thu Mar  6 07:46:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Mar 2025 07:46:56 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <ngePVW3MKh3sWYEw6sM1qUWJvuiFzI3ynU5-4c5p5MQ=.88add105-e474-4d1f-9b48-9af62b1c208e@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
 <_mnGdermmAHz7Uc0ImXgngswbkF1RgXjycQKTQAiz9I=.da23ce88-3967-4891-9bd7-b2b0a04e76ab@github.com>
 <ngePVW3MKh3sWYEw6sM1qUWJvuiFzI3ynU5-4c5p5MQ=.88add105-e474-4d1f-9b48-9af62b1c208e@github.com>
Message-ID: <EmRgWZ5hhmUV8U0DXx3UlpqoxST7MW38kAhn2SRksXg=.483b07e4-6247-4e0a-844f-899c12ce9c54@github.com>

On Thu, 6 Mar 2025 07:03:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/CDSCompressedKPtrs/XShareAuto.java line 43:
>> 
>>> 41:     public static void main(String[] args) throws Exception {
>>> 42:         ProcessBuilder pb = ProcessTools.createLimitedTestJavaProcessBuilder(
>>> 43:             "-XX:+UnlockDiagnosticVMOptions",
>> 
>> This test was created specifically as a regression test because `-server` didn't work. I'm not sure it serves any purpose now. @iklam?
>
> I think the test still serves as a functional test: if an archive is specified, then -Xshare:auto is used by default.

Would it be better to use @requires !jdk.static for now so this test isn't selected when testing static builds? There is work further down the line to figure out a story for static builds + AOT as the ultimate goal is to run jlink and produce a single executable so there wouldn't be a separate AOT cache/archive on the file system. It's much further down the road, not clear that it's worth trying to test intermediate tests with -Xshare:auto at this time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1982845616

From ktakakuri at openjdk.org  Thu Mar  6 08:53:57 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Thu, 6 Mar 2025 08:53:57 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v2]
In-Reply-To: <dQlSzANca3fgrran6u4v4NJL4wmUjzo7SppQLzDLFX4=.2b541d09-96e2-49eb-a97b-0f4b33752e46@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <VY8wZOwMgOaNgfKYlYWeb9b2XupI_8oZ8_hmy4i2syY=.86058d22-2c1f-4758-94e3-0a8fb938ced9@github.com>
 <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com>
 <zRILbqqqfapzSSqehYXi0aByi7vKRgSmmdZna5jx7Vg=.0bf97ac0-1406-4379-afa8-03b22115fe20@github.com>
 <dQlSzANca3fgrran6u4v4NJL4wmUjzo7SppQLzDLFX4=.2b541d09-96e2-49eb-a97b-0f4b33752e46@github.com>
Message-ID: <bXiWo1gfSuKU7FpQZyfIi9f4HHIoMvTdur3Lh3-mA7g=.3301a575-da75-448c-8b27-e938fcd37f4c@github.com>

On Fri, 28 Feb 2025 10:05:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As well as tools/jpackage/windows/Win8301247Test.java, the tools tests is not included in jdk/tier1, so it will not run in GHA?
>
> Sorry I'm not sure what you are asking.

I think tools/jpackage/helpers/jdk/jpackage/test/Executor.java is not run in GHA.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1982942311

From jsjolen at openjdk.org  Thu Mar  6 10:27:06 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 6 Mar 2025 10:27:06 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag
In-Reply-To: <K8BYn1xaxRw9qtZfubPZH9co9AlwnV8LTgHBYwttmYg=.85c4eaf5-3502-420c-a415-97f962b427e4@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
 <K8BYn1xaxRw9qtZfubPZH9co9AlwnV8LTgHBYwttmYg=.85c4eaf5-3502-420c-a415-97f962b427e4@github.com>
Message-ID: <0CDxD_JcYtu4Ax1xB8TDyWqLkxNub6OfJRtSmCFONgU=.bd3edae0-3eaf-4ba3-ac9e-2582d1baf151@github.com>

On Wed, 5 Mar 2025 15:28:59 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
>> Tests:
>> linux-x64-debug, gtest:NMT* and runtime/NMT*
>
> src/hotspot/share/cds/metaspaceShared.cpp line 1475:
> 
>> 1473:              (address)archive_space_rs.base() == base_address, "Sanity");
>> 1474:       // Register archive space with NMT.
>> 1475:       MemTracker::record_virtual_memory_tag(archive_space_rs.base(), archive_space_rs.size(), mtClassShared);
> 
> The pattern here is:
> 
> `something.base(), something.base.size()`
> 
> instead of doing this over and over again, why can't we just pass `something` to MemTracker::record_virtual_memory_tag() and let it figure out `base` and `size` itself?

We could have an overload for `ReservedSpace`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1983093725

From azafari at openjdk.org  Thu Mar  6 14:22:38 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Mar 2025 14:22:38 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v2]
In-Reply-To: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
Message-ID: <pqI8-BOVie8_NtpoT70Bh8Qxy65D5ANTWAQeIV1IK_A=.a12a3e68-c867-4083-91e4-346f1a088dfa@github.com>

> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
> Tests:
> linux-x64-debug, gtest:NMT* and runtime/NMT*

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  ReservedSpace is accepted as param.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23770/files
  - new: https://git.openjdk.org/jdk/pull/23770/files/0a1495bc..1e7853e6

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

  Stats: 21 lines in 12 files changed: 4 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/23770.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23770/head:pull/23770

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

From azafari at openjdk.org  Thu Mar  6 14:22:39 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Mar 2025 14:22:39 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v2]
In-Reply-To: <K8BYn1xaxRw9qtZfubPZH9co9AlwnV8LTgHBYwttmYg=.85c4eaf5-3502-420c-a415-97f962b427e4@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
 <K8BYn1xaxRw9qtZfubPZH9co9AlwnV8LTgHBYwttmYg=.85c4eaf5-3502-420c-a415-97f962b427e4@github.com>
Message-ID: <ucycAOBUxhCJ2TsoSRyPqkGM598Wd6vM14t1-zs-EFM=.ee25b563-4088-41c9-9415-fb1acc7e6ed6@github.com>

On Wed, 5 Mar 2025 15:25:29 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ReservedSpace is accepted as param.
>
> src/hotspot/share/cds/metaspaceShared.cpp line 1548:
> 
>> 1546:       return nullptr;
>> 1547:     }
>> 1548:     // NMT: fix up the space tags
> 
> What exactly needs to be fixed here?

Removed. Obsolete comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1983442554

From azafari at openjdk.org  Thu Mar  6 14:22:39 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Mar 2025 14:22:39 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v2]
In-Reply-To: <0CDxD_JcYtu4Ax1xB8TDyWqLkxNub6OfJRtSmCFONgU=.bd3edae0-3eaf-4ba3-ac9e-2582d1baf151@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
 <K8BYn1xaxRw9qtZfubPZH9co9AlwnV8LTgHBYwttmYg=.85c4eaf5-3502-420c-a415-97f962b427e4@github.com>
 <0CDxD_JcYtu4Ax1xB8TDyWqLkxNub6OfJRtSmCFONgU=.bd3edae0-3eaf-4ba3-ac9e-2582d1baf151@github.com>
Message-ID: <Nz1BRXqh7CEc022G9ZkiZyWR2SqONC5HGfMKDrb7Vaw=.bd9c8d4c-cacd-4e2f-a1cc-4e2f1a5ac4cb@github.com>

On Thu, 6 Mar 2025 10:23:54 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/cds/metaspaceShared.cpp line 1475:
>> 
>>> 1473:              (address)archive_space_rs.base() == base_address, "Sanity");
>>> 1474:       // Register archive space with NMT.
>>> 1475:       MemTracker::record_virtual_memory_tag(archive_space_rs.base(), archive_space_rs.size(), mtClassShared);
>> 
>> The pattern here is:
>> 
>> `something.base(), something.base.size()`
>> 
>> instead of doing this over and over again, why can't we just pass `something` to MemTracker::record_virtual_memory_tag() and let it figure out `base` and `size` itself?
>
> We could have an overload for `ReservedSpace`.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23770#discussion_r1983441505

From azafari at openjdk.org  Thu Mar  6 14:26:56 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Mar 2025 14:26:56 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v35]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <trnLKG1BO0lB-ipqibW-MaDT-Rj2jVChdzidegfencE=.a8ba936d-076b-4bf4-9214-7d37fc1cf106@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  review comments applied

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/fc106d5f..f2f1a800

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=33-34

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

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

From azafari at openjdk.org  Thu Mar  6 14:26:59 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Mar 2025 14:26:59 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v34]
In-Reply-To: <V4UhKGn9pVMeKubGH7QLW4aaSl9Ku4R4gyb7YZhYx58=.f45ae760-8191-4f74-9365-aef4ddebb4b2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <dbApB_oGdCi_Xl-Un8RmQxtZSEMg2xN55F-vAtXKK9M=.56b42fe1-3494-48d2-9448-a4900d05de15@github.com>
 <V4UhKGn9pVMeKubGH7QLW4aaSl9Ku4R4gyb7YZhYx58=.f45ae760-8191-4f74-9365-aef4ddebb4b2@github.com>
Message-ID: <sswZSLg9uSEeCeIbRIc22sBYoJopT_DKuB09I-qfGIU=.1298495a-d3c0-4502-b8ff-5cf316e5a086@github.com>

On Wed, 5 Mar 2025 16:06:55 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test cases for doing reserve or commit the same region twice.
>
> src/hotspot/share/nmt/memReporter.cpp line 451:
> 
>> 449:     });
>> 450: 
>> 451:     if (reserved_and_committed)
> 
> Missing braces

Done.

> src/hotspot/share/nmt/regionsTree.hpp line 37:
> 
>> 35: // for processing the tree nodes in a shorter and more meaningful way.
>> 36: class RegionsTree : public VMATree {
>> 37:  private:
> 
> Remote private, not needed.

Done.

> src/hotspot/share/nmt/regionsTree.hpp line 56:
> 
>> 54:       NodeHelper() : _node(nullptr) { }
>> 55:       NodeHelper(Node* node) : _node(node) { }
>> 56:       inline bool is_valid() { return _node != nullptr; }
> 
> Missing `const`

Done.

> src/hotspot/share/nmt/regionsTree.inline.hpp line 33:
> 
>> 31: void RegionsTree::visit_committed_regions(const ReservedMemoryRegion& rgn, F func) {
>> 32:   position start = (position)rgn.base();
>> 33:   size_t end = (size_t)rgn.end() + 1;
> 
> Can we `static_cast<size_t>(rgn.end())` instead?

Should be `reinterpret_cast<>` instead.
Done.

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 60:
> 
>> 58:     if (tracker == nullptr) return false;
>> 59:     _tracker = new (tracker) VirtualMemoryTracker(level == NMT_detail);
>> 60:     return _tracker->tree() != nullptr;
> 
> @afshin-zafari , `_tracker->tree()` can never be null anymore. In the future we should do a PR where we change it to return a reference.

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983447519
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983447822
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983448306
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983449521
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983450068

From gziemski at openjdk.org  Thu Mar  6 15:27:04 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 6 Mar 2025 15:27:04 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v2]
In-Reply-To: <pqI8-BOVie8_NtpoT70Bh8Qxy65D5ANTWAQeIV1IK_A=.a12a3e68-c867-4083-91e4-346f1a088dfa@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
 <pqI8-BOVie8_NtpoT70Bh8Qxy65D5ANTWAQeIV1IK_A=.a12a3e68-c867-4083-91e4-346f1a088dfa@github.com>
Message-ID: <Hm7tH0GQ_0k6bDmsDWqxkHwbG585FPDSIU7YSaQMZt0=.ae75e2c3-a592-454c-b8b0-e68fd09f08d1@github.com>

On Thu, 6 Mar 2025 14:22:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
>> Tests:
>> linux-x64-debug, gtest:NMT* and runtime/NMT*
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ReservedSpace is accepted as param.

LGTM, thank you for fixing this.

Need to fix the build errors:

/home/runner/work/jdk/jdk/src/hotspot/share/nmt/memTracker.hpp:224:31: error: invalid use of incomplete type ?const class ReservedSpace?
  224 |     record_virtual_memory_tag(rs.base(), rs.size(), mem_tag);
      |                               ^~
In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:28:
/home/runner/work/jdk/jdk/src/hotspot/share/memory/metaspace.hpp:38:7: note: forward declaration of ?class ReservedSpace?
   38 | class ReservedSpace;
      |       ^~~~~~~~~~~~~
In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:30:
/home/runner/work/jdk/jdk/src/hotspot/share/nmt/memTracker.hpp:224:42: error: invalid use of incomplete type ?const class ReservedSpace?
  224 |     record_virtual_memory_tag(rs.base(), rs.size(), mem_tag);
      |                                          ^~
In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:28:
/home/runner/work/jdk/jdk/src/hotspot/share/memory/metaspace.hpp:38:7: note: forward declaration of ?class ReservedSpace?
   ... (rest of output omitted)

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

Marked as reviewed by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2664792545
PR Comment: https://git.openjdk.org/jdk/pull/23770#issuecomment-2704168962

From jsjolen at openjdk.org  Thu Mar  6 17:54:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 6 Mar 2025 17:54:56 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v4]
In-Reply-To: <2VrvagcQ_c6vqMMaINqJ-DNTnXB_c8eAW4qo_yvtcvE=.ac41a25f-7e74-4bfd-9a85-bd7bd5ef7083@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <2VrvagcQ_c6vqMMaINqJ-DNTnXB_c8eAW4qo_yvtcvE=.ac41a25f-7e74-4bfd-9a85-bd7bd5ef7083@github.com>
Message-ID: <lqI3Vuwxw6yF7lgDBMsqfTSTfHIO-rzJcciPfcrG-nQ=.88e73f09-797e-4187-bfd5-bf01b97cf70e@github.com>

On Thu, 6 Mar 2025 02:18:35 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

Hi Alex,

I'm generally happy with this code. I've got a few more comments, but nothing major.

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

> 314: 
> 315: static jint data_dump(AttachOperation* op, attachStream* out) {
> 316:   out->set_result(JNI_OK); // allow streaming output

I'm wondering, do you think it's useful to add a helper `start_streaming_if_available` (or whatever) that just calls `set_result(JNI_OK)`? That helper could have a small snippet of documentation to explain what's going on. That would probably be neater than a comment.

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

> 371:   // The commands report error if the agent failed to load, so we need to disable streaming output.
> 372:   const char jmx_prefix[] = "ManagementAgent.";
> 373:   if (strncmp(op->arg(0), jmx_prefix, strlen(jmx_prefix)) == 0) {

`const char* jmx_prefix = "ManagementAgent.", not array.

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

> 394:   if (HAS_PENDING_EXCEPTION) {
> 395:     // We can get an exception during command execution.
> 396:     // In the case _attach_stream->set_result() is already called and operation result code is send

"is senT to the client"

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 379:

> 377: 
> 378:             // Reply is "<ver> option1,option2...".
> 379:             int delimPos = message.indexOf(' ');

We can do this in an early-break sort of way. That'd reduce the indentation and let's us not to have to check `delimPos` again.


int delimPos = message.indexOf(' ');
int supportedVersion = Integer.parseUnsignedInt(delimPos < 0 ? message : message.substring(0, delimPos));
if (delimPos < 0 || supportedVersion != VERSION_2) {
    return; // No options to parse, or doesn't support options anyway
}
/* Insert the parsing stuff here */

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

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2665162130
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1983778660
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1983782768
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1983783438
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1983812437

From jiangli at openjdk.org  Thu Mar  6 17:57:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 17:57:57 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <EmRgWZ5hhmUV8U0DXx3UlpqoxST7MW38kAhn2SRksXg=.483b07e4-6247-4e0a-844f-899c12ce9c54@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
 <_mnGdermmAHz7Uc0ImXgngswbkF1RgXjycQKTQAiz9I=.da23ce88-3967-4891-9bd7-b2b0a04e76ab@github.com>
 <ngePVW3MKh3sWYEw6sM1qUWJvuiFzI3ynU5-4c5p5MQ=.88add105-e474-4d1f-9b48-9af62b1c208e@github.com>
 <EmRgWZ5hhmUV8U0DXx3UlpqoxST7MW38kAhn2SRksXg=.483b07e4-6247-4e0a-844f-899c12ce9c54@github.com>
Message-ID: <DUxfxd50cDQgKjaNT29oAeTYb1HKzW9ccXeebo_Ygso=.db23e332-76c1-4232-9dde-d8e8601dc3ee@github.com>

On Thu, 6 Mar 2025 07:44:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think the test still serves as a functional test: if an archive is specified, then -Xshare:auto is used by default.
>
> Would it be better to use @requires !jdk.static for now so this test isn't selected when testing static builds? There is work further down the line to figure out a story for static builds + AOT as the ultimate goal is to run jlink and produce a single executable so there wouldn't be a separate AOT cache/archive on the file system. It's much further down the road, not clear that it's worth trying to test intermediate tests with -Xshare:auto at this time.

Looking back at the history, the `-Xshare:auto` & `-server` issue (https://bugs.openjdk.org/browse/JDK-8005933) was related to this code in JDK 8:

https://github.com/openjdk/jdk8u-dev/commit/a1f3a95880318c32169ff89dc8784a0dfc629eec

In JDK 8, on c2 sharedSpaces is disabled if the following condition is true.


!DumpSharedSpaces && !RequireSharedSpaces &&
      (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)


That code no longer exists in mainline. The `-server` option has become a no-op. The launcher code, `CheckJvmType` removes `-server` from the command line arguments passed to the VM side. As a result of those, `-server` is no real impact on CDS now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1983820332

From jsjolen at openjdk.org  Thu Mar  6 18:28:55 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 6 Mar 2025 18:28:55 GMT
Subject: RFR: 8350565: NMT: remaining memory flag/type to be replaced with
 memory tag
In-Reply-To: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
References: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
Message-ID: <urcRZ0_2WkWYimBAf03HBxx0N3j85STbLnNy7cuZ3G4=.61a45b53-c01c-4397-8801-bfa489e39679@github.com>

On Tue, 25 Feb 2025 09:38:22 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> There were some remaining flag or type for Memory Tag contexts.
> 
> Tests:
> gtest:NMT* and runtime/NMT sets of tasks all passed.

LGTM, cheers

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23769#pullrequestreview-2665300801

From jsjolen at openjdk.org  Thu Mar  6 18:49:30 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 6 Mar 2025 18:49:30 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v35]
In-Reply-To: <trnLKG1BO0lB-ipqibW-MaDT-Rj2jVChdzidegfencE=.a8ba936d-076b-4bf4-9214-7d37fc1cf106@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <trnLKG1BO0lB-ipqibW-MaDT-Rj2jVChdzidegfencE=.a8ba936d-076b-4bf4-9214-7d37fc1cf106@github.com>
Message-ID: <PcmQziLol7DrMExjxFhMFl058r41awonG_aQbnNpY98=.c3428d21-8d13-4d3c-9b30-c58e65f0be74@github.com>

On Thu, 6 Mar 2025 14:26:56 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied

A few more :-).

Btw, you probably do not want to integrate any of your other NMT PRs (unless they are necessary). Integrating them might cause merge conflicts.

I think we're almost done!!! Great job on this :D

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 107:

> 105:     //                str, NMTUtil::tag_to_name(tag), (long)reserve_delta, (long)commit_delta, reserved, committed);
> 106:   };
> 107: 

8350567 is merged now! I think that that PR should be merged in.

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 195:

> 193: bool VirtualMemoryTracker::print_containing_region(const void* p, outputStream* st) {
> 194:   ReservedMemoryRegion rmr = tree()->find_reserved_region((address)p);
> 195:   log_debug(nmt)("containing rgn: base=" INTPTR_FORMAT, p2i(rmr.base()));

Is this important?

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 216:

> 214:   MemTracker::NmtVirtualMemoryLocker nvml;
> 215:   tree()->visit_reserved_regions([&](ReservedMemoryRegion& rgn) {
> 216:     log_info(nmt)("region in walker vmem, base: " INTPTR_FORMAT " size: %zu , %s, committed: %zu",

This should be `debug` level, or maybe even removed.

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 35:

> 33: #include "utilities/ostream.hpp"
> 34: 
> 35: // VirtualMemoryTracker (VMT) is the internal class of NMT that only the MemTracker class uses it for performing the NMT operations.

`... uses it for ...`, delete "it" (grammar issue).

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 41:

> 39: // state (reserved/released/committed) and MemTag of the regions before and after it.
> 40: //
> 41: // The memory operations of Reserve/Commit/Uncommit/Release (RCUR) are tracked by updating/inserting/deleting the nodes in the tree. When an operation

`(RCUR)` can be removed, it's never mentioned again.

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 49:

> 47: //   - uncommitted size of a MemTag should be <= of its committed size
> 48: //   - released size of a MemTag should be <= of its reserved size
> 49: 

I don't believe that these are checked, right? So this can be deleted.

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 132:

> 130:     }
> 131:   }
> 132: 

Dead code?

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

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2665310971
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983875040
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983878610
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983879989
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983870666
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983869375
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983868809
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1983866253

From iklam at openjdk.org  Thu Mar  6 20:37:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Mar 2025 20:37:55 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <DUxfxd50cDQgKjaNT29oAeTYb1HKzW9ccXeebo_Ygso=.db23e332-76c1-4232-9dde-d8e8601dc3ee@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
 <_mnGdermmAHz7Uc0ImXgngswbkF1RgXjycQKTQAiz9I=.da23ce88-3967-4891-9bd7-b2b0a04e76ab@github.com>
 <ngePVW3MKh3sWYEw6sM1qUWJvuiFzI3ynU5-4c5p5MQ=.88add105-e474-4d1f-9b48-9af62b1c208e@github.com>
 <EmRgWZ5hhmUV8U0DXx3UlpqoxST7MW38kAhn2SRksXg=.483b07e4-6247-4e0a-844f-899c12ce9c54@github.com>
 <DUxfxd50cDQgKjaNT29oAeTYb1HKzW9ccXeebo_Ygso=.db23e332-76c1-4232-9dde-d8e8601dc3ee@github.com>
Message-ID: <F7_f_TdaRBhI35zmncwPdrXerOkoL6ndzJZFfJem8Bo=.f892db5e-a401-4899-a5df-8654dbcb7296@github.com>

On Thu, 6 Mar 2025 17:55:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Would it be better to use @requires !jdk.static for now so this test isn't selected when testing static builds? There is work further down the line to figure out a story for static builds + AOT as the ultimate goal is to run jlink and produce a single executable so there wouldn't be a separate AOT cache/archive on the file system. It's much further down the road, not clear that it's worth trying to test intermediate tests with -Xshare:auto at this time.
>
> Looking back at the history, the `-Xshare:auto` & `-server` issue (https://bugs.openjdk.org/browse/JDK-8005933) was related to this code in JDK 8:
> 
> https://github.com/openjdk/jdk8u-dev/commit/a1f3a95880318c32169ff89dc8784a0dfc629eec
> 
> In JDK 8, on c2 sharedSpaces is disabled if the following condition is true.
> 
> 
> !DumpSharedSpaces && !RequireSharedSpaces &&
>       (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)
> 
> 
> That code no longer exists in mainline. The `-server` option has become a no-op. The launcher code, `CheckJvmType` removes `-server` from the command line arguments passed to the VM side. As a result of those, `-server` is no real impact on CDS now.

For this particular test, I think it's OK to remove `-server` (so it won't fail with static JDK) and ` * @bug 8005933`  (as the condition related to that particular bug no longer exists). But we should keep the test for the purpose "-Xshare:auto is the default when -Xshare is not specified"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1984015402

From jiangli at openjdk.org  Thu Mar  6 23:32:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 6 Mar 2025 23:32:55 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <EmRgWZ5hhmUV8U0DXx3UlpqoxST7MW38kAhn2SRksXg=.483b07e4-6247-4e0a-844f-899c12ce9c54@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
 <_mnGdermmAHz7Uc0ImXgngswbkF1RgXjycQKTQAiz9I=.da23ce88-3967-4891-9bd7-b2b0a04e76ab@github.com>
 <ngePVW3MKh3sWYEw6sM1qUWJvuiFzI3ynU5-4c5p5MQ=.88add105-e474-4d1f-9b48-9af62b1c208e@github.com>
 <EmRgWZ5hhmUV8U0DXx3UlpqoxST7MW38kAhn2SRksXg=.483b07e4-6247-4e0a-844f-899c12ce9c54@github.com>
Message-ID: <h7Ueqq6SJpL5crdoHVs-kMH4Lxiuf_5QS-RoPRsPyiQ=.c82eb2c4-d725-4d61-9988-9aa0d63fb48d@github.com>

On Thu, 6 Mar 2025 07:44:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think the test still serves as a functional test: if an archive is specified, then -Xshare:auto is used by default.
>
> Would it be better to use @requires !jdk.static for now so this test isn't selected when testing static builds? There is work further down the line to figure out a story for static builds + AOT as the ultimate goal is to run jlink and produce a single executable so there wouldn't be a separate AOT cache/archive on the file system. It's much further down the road, not clear that it's worth trying to test intermediate tests with -Xshare:auto at this time.

Thanks. I agree with keeping the test. That's also related to @AlanBateman comments on if the test needs to be skipped for static JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23881#discussion_r1984185761

From amenkov at openjdk.org  Fri Mar  7 01:46:37 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Mar 2025 01:46:37 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v5]
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: <oJjAjXaPQgDh7AYdSDzC3vPbxA669H68ZlbjfyLeDUo=.06dd0b2d-6428-4da4-aa8c-7c0c14d26c9d@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/5c87f9e4..2a3d4346

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

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 amenkov at openjdk.org  Fri Mar  7 02:15:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Mar 2025 02:15:56 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v4]
In-Reply-To: <lqI3Vuwxw6yF7lgDBMsqfTSTfHIO-rzJcciPfcrG-nQ=.88e73f09-797e-4187-bfd5-bf01b97cf70e@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <2VrvagcQ_c6vqMMaINqJ-DNTnXB_c8eAW4qo_yvtcvE=.ac41a25f-7e74-4bfd-9a85-bd7bd5ef7083@github.com>
 <lqI3Vuwxw6yF7lgDBMsqfTSTfHIO-rzJcciPfcrG-nQ=.88e73f09-797e-4187-bfd5-bf01b97cf70e@github.com>
Message-ID: <fme883PAlbdETWn2f4DCVn5CEu1W30vMIrNoH9RKPhU=.c5491fe7-61da-467f-91d9-c096e82ce499@github.com>

On Thu, 6 Mar 2025 17:27:56 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
>
> src/hotspot/share/services/attachListener.cpp line 316:
> 
>> 314: 
>> 315: static jint data_dump(AttachOperation* op, attachStream* out) {
>> 316:   out->set_result(JNI_OK); // allow streaming output
> 
> I'm wondering, do you think it's useful to add a helper `start_streaming_if_available` (or whatever) that just calls `set_result(JNI_OK)`? That helper could have a small snippet of documentation to explain what's going on. That would probably be neater than a comment.

I don't think helper method is needed (and those comments too :)
I think the better approach would be "operation handler should call set_result as soon as it knows the result code"

> src/hotspot/share/services/attachListener.cpp line 373:
> 
>> 371:   // The commands report error if the agent failed to load, so we need to disable streaming output.
>> 372:   const char jmx_prefix[] = "ManagementAgent.";
>> 373:   if (strncmp(op->arg(0), jmx_prefix, strlen(jmx_prefix)) == 0) {
> 
> `const char* jmx_prefix = "ManagementAgent.", not array.

Fixed.

> src/hotspot/share/services/attachListener.cpp line 396:
> 
>> 394:   if (HAS_PENDING_EXCEPTION) {
>> 395:     // We can get an exception during command execution.
>> 396:     // In the case _attach_stream->set_result() is already called and operation result code is send
> 
> "is senT to the client"

Fixed

> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 379:
> 
>> 377: 
>> 378:             // Reply is "<ver> option1,option2...".
>> 379:             int delimPos = message.indexOf(' ');
> 
> We can do this in an early-break sort of way. That'd reduce the indentation and let's us not to have to check `delimPos` again.
> 
> 
> int delimPos = message.indexOf(' ');
> int supportedVersion = Integer.parseUnsignedInt(delimPos < 0 ? message : message.substring(0, delimPos));
> if (delimPos < 0 || supportedVersion != VERSION_2) {
>     return; // No options to parse, or doesn't support options anyway
> }
> /* Insert the parsing stuff here */

To me current implementation looks clearer. And I think it will be simpler to extend the logic (if we ever need to extend v2 or introduce v3)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1984330438
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1984331040
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1984332637
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1984343797

From dholmes at openjdk.org  Fri Mar  7 04:37:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 04:37:09 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
 <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
 <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
Message-ID: <YB0BPE3YrgPXxXVz-kiybyCy115iGXumKpyaw1-AcEs=.d0ec39ec-b697-4ada-b19e-bad218c0d4d2@github.com>

On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
>
>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
> 
> Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.

@sercher  your new test is failing in our CI:

[STDOUT]
mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory

I will file a new bug

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2705506729

From syan at openjdk.org  Fri Mar  7 07:27:52 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Mar 2025 07:27:52 GMT
Subject: RFR: 8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm
 fails
In-Reply-To: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
References: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
Message-ID: <q8eRxaQqp57wiR5hhFDbD6ZOfmVAWg3-Nv8604rnehs=.a7690fe8-28cc-426b-a131-1ddc64c5f2d7@github.com>

On Fri, 7 Feb 2025 07:01:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The glibc function `mallinfo()` do do not work with -fsanitize=adddress, maybe it's [limitation or bug](https://github.com/google/sanitizers/issues/1845) of address sanitizer . Should we disable the gtest 'os_linux.glibc_mallinfo_wrapper_vm' when configure and build with address sanitizer. The macro `ADDRESS_SANITIZER` will always pass to gcc/clang/microsoft compiler when enable address sanitizer. So this PR check the macro `ADDRESS_SANITIZER` to enable the test or not.
> 
> On the other hand, this test get malloc usage information by call `os::Linux::get_mallinfo` and check "total allocation values" greater than `2K` before allocate the memort by `malloc(2K)`. Call `os::Linux::get_mallinfo` should after `malloc(2K)`.
> 
> Below code snippet can demonstrate the glibc function `mallinfo()` do do not work with -fsanitize=adddress.
> 
> 
> #include <stdio.h>
> #include <malloc.h>
> 
> int main() {
>     struct mallinfo info;
>     info = mallinfo();
> 
>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
> 
>     char* ptr = malloc(0x10000);
>     info = mallinfo();
> 
>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
> 
>     free(ptr);
>     return 0;
> }
> 
> 
> - Without -fsanitize=address, mallinfo() works normally.
> 
> 
> gcc mallinfo.c && ./a.out
> 0, 1, 0, 0, 0, 0, 0, 0, 0, 0
> 135168, 1, 0, 0, 0, 0, 0, 67248, 67920, 67920
> 
> 
> - With -fsanitize=address, mallinfo() works abnormally.
> 
> 
> gcc -fsanitize=address mallinfo.c && ./a.out
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

keep it open.

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

PR Comment: https://git.openjdk.org/jdk/pull/23510#issuecomment-2705720762

From syan at openjdk.org  Fri Mar  7 07:31:52 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Mar 2025 07:31:52 GMT
Subject: RFR: 8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm
 fails
In-Reply-To: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
References: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
Message-ID: <7ZgJEJexcsRg3AFWychcq2aCnSAAP5eo0ve0iP78FLw=.6e689114-898e-4235-aba9-efc2f400422c@github.com>

On Fri, 7 Feb 2025 07:01:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The glibc function `mallinfo()` do do not work with -fsanitize=adddress, maybe it's [limitation or bug](https://github.com/google/sanitizers/issues/1845) of address sanitizer . Should we disable the gtest 'os_linux.glibc_mallinfo_wrapper_vm' when configure and build with address sanitizer. The macro `ADDRESS_SANITIZER` will always pass to gcc/clang/microsoft compiler when enable address sanitizer. So this PR check the macro `ADDRESS_SANITIZER` to enable the test or not.
> 
> On the other hand, this test get malloc usage information by call `os::Linux::get_mallinfo` and check "total allocation values" greater than `2K` before allocate the memort by `malloc(2K)`. Call `os::Linux::get_mallinfo` should after `malloc(2K)`.
> 
> Below code snippet can demonstrate the glibc function `mallinfo()` do do not work with -fsanitize=adddress.
> 
> 
> #include <stdio.h>
> #include <malloc.h>
> 
> int main() {
>     struct mallinfo info;
>     info = mallinfo();
> 
>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
> 
>     char* ptr = malloc(0x10000);
>     info = mallinfo();
> 
>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
> 
>     free(ptr);
>     return 0;
> }
> 
> 
> - Without -fsanitize=address, mallinfo() works normally.
> 
> 
> gcc mallinfo.c && ./a.out
> 0, 1, 0, 0, 0, 0, 0, 0, 0, 0
> 135168, 1, 0, 0, 0, 0, 0, 67248, 67920, 67920
> 
> 
> - With -fsanitize=address, mallinfo() works abnormally.
> 
> 
> gcc -fsanitize=address mallinfo.c && ./a.out
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

@tstuefe Hi, could you take look this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23510#issuecomment-2705727721

From azafari at openjdk.org  Fri Mar  7 08:05:29 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 08:05:29 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v36]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <xV1LWb4rnMJKuq7LBHixZhT2lVcEZGvth-QEYiPOAf8=.05a1bca4-9ec2-44e9-8d42-d08f053a1cff@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  more reviews.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/f2f1a800..cfab60fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=34-35

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

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

From azafari at openjdk.org  Fri Mar  7 08:40:26 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 08:40:26 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v37]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <qrK8FL2bPi9DHl8KbANJQJu7lU3h2iZBfhpwYFpmMSM=.80aa7b39-9d73-4221-95c3-81ba53e2e884@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits:

 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - more reviews.
 - review comments applied
 - test cases for doing reserve or commit the same region twice.
 - style, some cleanup, VMT and regionsTree circular dep resolved
 - removed UseFlagInPlace test.
 - reviews applied.
 - test file got back, fixed coding style
 - once more.
 - removed remaining of the unrelated changes.
 - ... and 72 more: https://git.openjdk.org/jdk/compare/7314efc9...5177cc11

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

Changes: https://git.openjdk.org/jdk/pull/20425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=36
  Stats: 1450 lines in 26 files changed: 582 ins; 544 del; 324 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

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

From azafari at openjdk.org  Fri Mar  7 08:40:26 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 08:40:26 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v35]
In-Reply-To: <PcmQziLol7DrMExjxFhMFl058r41awonG_aQbnNpY98=.c3428d21-8d13-4d3c-9b30-c58e65f0be74@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <trnLKG1BO0lB-ipqibW-MaDT-Rj2jVChdzidegfencE=.a8ba936d-076b-4bf4-9214-7d37fc1cf106@github.com>
 <PcmQziLol7DrMExjxFhMFl058r41awonG_aQbnNpY98=.c3428d21-8d13-4d3c-9b30-c58e65f0be74@github.com>
Message-ID: <tanEOxNtClPPrczx-j_s-MnKWxAu5kDTWJshdSWERWQ=.d63aaf75-7f3a-43f1-bd8b-c517b06234f9@github.com>

On Thu, 6 Mar 2025 18:38:20 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments applied
>
> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 107:
> 
>> 105:     //                str, NMTUtil::tag_to_name(tag), (long)reserve_delta, (long)commit_delta, reserved, committed);
>> 106:   };
>> 107: 
> 
> 8350567 is merged now! I think that that PR should be merged in.

Under test.

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 195:
> 
>> 193: bool VirtualMemoryTracker::print_containing_region(const void* p, outputStream* st) {
>> 194:   ReservedMemoryRegion rmr = tree()->find_reserved_region((address)p);
>> 195:   log_debug(nmt)("containing rgn: base=" INTPTR_FORMAT, p2i(rmr.base()));
> 
> Is this important?

Removed.

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 216:
> 
>> 214:   MemTracker::NmtVirtualMemoryLocker nvml;
>> 215:   tree()->visit_reserved_regions([&](ReservedMemoryRegion& rgn) {
>> 216:     log_info(nmt)("region in walker vmem, base: " INTPTR_FORMAT " size: %zu , %s, committed: %zu",
> 
> This should be `debug` level, or maybe even removed.

Removed.

> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 35:
> 
>> 33: #include "utilities/ostream.hpp"
>> 34: 
>> 35: // VirtualMemoryTracker (VMT) is the internal class of NMT that only the MemTracker class uses it for performing the NMT operations.
> 
> `... uses it for ...`, delete "it" (grammar issue).

Removed.

> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 41:
> 
>> 39: // state (reserved/released/committed) and MemTag of the regions before and after it.
>> 40: //
>> 41: // The memory operations of Reserve/Commit/Uncommit/Release (RCUR) are tracked by updating/inserting/deleting the nodes in the tree. When an operation
> 
> `(RCUR)` can be removed, it's never mentioned again.

Removed.

> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 49:
> 
>> 47: //   - uncommitted size of a MemTag should be <= of its committed size
>> 48: //   - released size of a MemTag should be <= of its reserved size
>> 49: 
> 
> I don't believe that these are checked, right? So this can be deleted.

As said at the end of line, when they are applied to the VirtualMemorySummary they will be checked.
Is it OK if I limit/wrap the comments to 80-columns text?

> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 132:
> 
>> 130:     }
>> 131:   }
>> 132: 
> 
> Dead code?

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1984660439
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1984660659
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1984660818
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1984660197
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1984659994
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1984659801
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1984657977

From stuefe at openjdk.org  Fri Mar  7 09:02:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Mar 2025 09:02:53 GMT
Subject: RFR: 8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm
 fails
In-Reply-To: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
References: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
Message-ID: <bX1m9ou_xaYFOpICT4ugSdliKoF2BhI4h02GhIZ2q-A=.216acf1f-35cf-424f-8f31-cd3342806b72@github.com>

On Fri, 7 Feb 2025 07:01:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The glibc function `mallinfo()` do do not work with -fsanitize=adddress, maybe it's [limitation or bug](https://github.com/google/sanitizers/issues/1845) of address sanitizer . Should we disable the gtest 'os_linux.glibc_mallinfo_wrapper_vm' when configure and build with address sanitizer. The macro `ADDRESS_SANITIZER` will always pass to gcc/clang/microsoft compiler when enable address sanitizer. So this PR check the macro `ADDRESS_SANITIZER` to enable the test or not.
> 
> On the other hand, this test get malloc usage information by call `os::Linux::get_mallinfo` and check "total allocation values" greater than `2K` before allocate the memort by `malloc(2K)`. Call `os::Linux::get_mallinfo` should after `malloc(2K)`.
> 
> Below code snippet can demonstrate the glibc function `mallinfo()` do do not work with -fsanitize=adddress.
> 
> 
> #include <stdio.h>
> #include <malloc.h>
> 
> int main() {
>     struct mallinfo info;
>     info = mallinfo();
> 
>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
> 
>     char* ptr = malloc(0x10000);
>     info = mallinfo();
> 
>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
> 
>     free(ptr);
>     return 0;
> }
> 
> 
> - Without -fsanitize=address, mallinfo() works normally.
> 
> 
> gcc mallinfo.c && ./a.out
> 0, 1, 0, 0, 0, 0, 0, 0, 0, 0
> 135168, 1, 0, 0, 0, 0, 0, 67248, 67920, 67920
> 
> 
> - With -fsanitize=address, mallinfo() works abnormally.
> 
> 
> gcc -fsanitize=address mallinfo.c && ./a.out
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

Good

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23510#pullrequestreview-2666642434

From azafari at openjdk.org  Fri Mar  7 09:09:57 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 09:09:57 GMT
Subject: RFR: 8350565: NMT: remaining memory flag/type to be replaced with
 memory tag
In-Reply-To: <UZ3V3RBS87pnDh7A7ZnFmBSUdKhPvaPx6QVsvXiBsy4=.79d0aed3-59ae-4206-b9a1-1a53c16894ca@github.com>
References: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
 <UZ3V3RBS87pnDh7A7ZnFmBSUdKhPvaPx6QVsvXiBsy4=.79d0aed3-59ae-4206-b9a1-1a53c16894ca@github.com>
Message-ID: <-mFlqvSoEduo15znaAMhkZQVwy88aII7-CptbYHPMkA=.ce89e088-c5ee-448c-9f9b-980e22c7db12@github.com>

On Wed, 5 Mar 2025 15:33:12 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> There were some remaining flag or type for Memory Tag contexts.
>> 
>> Tests:
>> gtest:NMT* and runtime/NMT sets of tasks all passed.
>
> Thank you very much for cleaning up this technical debt stuff. I really appreciate this work!
> 
> LGTM

Thank you @gerard-ziemski and @jdksjolen for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23769#issuecomment-2705907075

From azafari at openjdk.org  Fri Mar  7 09:09:58 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 09:09:58 GMT
Subject: Integrated: 8350565: NMT: remaining memory flag/type to be replaced
 with memory tag
In-Reply-To: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
References: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
Message-ID: <hDPjMHLwuKbNONiRa1jk9eJxIJI-gKLZcpg_AaaGXqQ=.1830d35f-34d0-41be-b467-6ea3b247fc6f@github.com>

On Tue, 25 Feb 2025 09:38:22 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> There were some remaining flag or type for Memory Tag contexts.
> 
> Tests:
> gtest:NMT* and runtime/NMT sets of tasks all passed.

This pull request has now been integrated.

Changeset: 4066f33a
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4066f33a0b9a080d87acd60056b3dbfc9348ab5e
Stats:     77 lines in 17 files changed: 0 ins; 0 del; 77 mod

8350565: NMT: remaining memory flag/type to be replaced with memory tag

Reviewed-by: gziemski, jsjolen

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

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

From syan at openjdk.org  Fri Mar  7 09:18:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Mar 2025 09:18:01 GMT
Subject: RFR: 8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm
 fails
In-Reply-To: <bX1m9ou_xaYFOpICT4ugSdliKoF2BhI4h02GhIZ2q-A=.216acf1f-35cf-424f-8f31-cd3342806b72@github.com>
References: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
 <bX1m9ou_xaYFOpICT4ugSdliKoF2BhI4h02GhIZ2q-A=.216acf1f-35cf-424f-8f31-cd3342806b72@github.com>
Message-ID: <FPGLO5ZxOgd09AyocVSoTHAsYQhVwY6pQqlbd3LAQbU=.959fe565-6ec8-409f-a318-77760f6775a7@github.com>

On Fri, 7 Mar 2025 09:00:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi all,
>> 
>> The glibc function `mallinfo()` do do not work with -fsanitize=adddress, maybe it's [limitation or bug](https://github.com/google/sanitizers/issues/1845) of address sanitizer . Should we disable the gtest 'os_linux.glibc_mallinfo_wrapper_vm' when configure and build with address sanitizer. The macro `ADDRESS_SANITIZER` will always pass to gcc/clang/microsoft compiler when enable address sanitizer. So this PR check the macro `ADDRESS_SANITIZER` to enable the test or not.
>> 
>> On the other hand, this test get malloc usage information by call `os::Linux::get_mallinfo` and check "total allocation values" greater than `2K` before allocate the memort by `malloc(2K)`. Call `os::Linux::get_mallinfo` should after `malloc(2K)`.
>> 
>> Below code snippet can demonstrate the glibc function `mallinfo()` do do not work with -fsanitize=adddress.
>> 
>> 
>> #include <stdio.h>
>> #include <malloc.h>
>> 
>> int main() {
>>     struct mallinfo info;
>>     info = mallinfo();
>> 
>>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
>> 
>>     char* ptr = malloc(0x10000);
>>     info = mallinfo();
>> 
>>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
>> 
>>     free(ptr);
>>     return 0;
>> }
>> 
>> 
>> - Without -fsanitize=address, mallinfo() works normally.
>> 
>> 
>> gcc mallinfo.c && ./a.out
>> 0, 1, 0, 0, 0, 0, 0, 0, 0, 0
>> 135168, 1, 0, 0, 0, 0, 0, 67248, 67920, 67920
>> 
>> 
>> - With -fsanitize=address, mallinfo() works abnormally.
>> 
>> 
>> gcc -fsanitize=address mallinfo.c && ./a.out
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
>
> Good

Thanks @tstuefe

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

PR Comment: https://git.openjdk.org/jdk/pull/23510#issuecomment-2705921065

From syan at openjdk.org  Fri Mar  7 09:18:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 7 Mar 2025 09:18:02 GMT
Subject: Integrated: 8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm
 fails
In-Reply-To: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
References: <FZM8Jveg-RsIDyt0dh6Rak14w0U3gGT_kecqM3p3S-Q=.32044c3c-eecf-480f-9cdb-0a1c9d8c5ef0@github.com>
Message-ID: <qJTZcw89csGEmEcV2GZjeqpfGkvrdTpp6zrEg-ygyNQ=.6e807cd9-ab8e-44d6-8282-197054a08497@github.com>

On Fri, 7 Feb 2025 07:01:18 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The glibc function `mallinfo()` do do not work with -fsanitize=adddress, maybe it's [limitation or bug](https://github.com/google/sanitizers/issues/1845) of address sanitizer . Should we disable the gtest 'os_linux.glibc_mallinfo_wrapper_vm' when configure and build with address sanitizer. The macro `ADDRESS_SANITIZER` will always pass to gcc/clang/microsoft compiler when enable address sanitizer. So this PR check the macro `ADDRESS_SANITIZER` to enable the test or not.
> 
> On the other hand, this test get malloc usage information by call `os::Linux::get_mallinfo` and check "total allocation values" greater than `2K` before allocate the memort by `malloc(2K)`. Call `os::Linux::get_mallinfo` should after `malloc(2K)`.
> 
> Below code snippet can demonstrate the glibc function `mallinfo()` do do not work with -fsanitize=adddress.
> 
> 
> #include <stdio.h>
> #include <malloc.h>
> 
> int main() {
>     struct mallinfo info;
>     info = mallinfo();
> 
>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
> 
>     char* ptr = malloc(0x10000);
>     info = mallinfo();
> 
>     printf("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d\n", info.arena, info.ordblks, info.smblks, info.hblks, info.hblkhd, info.usmblks, info.fsmblks, info.uordblks, info.fordblks, info.keepcost);
> 
>     free(ptr);
>     return 0;
> }
> 
> 
> - Without -fsanitize=address, mallinfo() works normally.
> 
> 
> gcc mallinfo.c && ./a.out
> 0, 1, 0, 0, 0, 0, 0, 0, 0, 0
> 135168, 1, 0, 0, 0, 0, 0, 67248, 67920, 67920
> 
> 
> - With -fsanitize=address, mallinfo() works abnormally.
> 
> 
> gcc -fsanitize=address mallinfo.c && ./a.out
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

This pull request has now been integrated.

Changeset: 155697fc
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/155697fc0ed69f1b4f871b00fe67685177bad59a
Stats:     7 lines in 1 file changed: 4 ins; 2 del; 1 mod

8349623: [ASAN] Gtest os_linux.glibc_mallinfo_wrapper_vm fails

Reviewed-by: stuefe

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

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

From stuefe at openjdk.org  Fri Mar  7 09:21:56 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 7 Mar 2025 09:21:56 GMT
Subject: RFR: 8350565: NMT: remaining memory flag/type to be replaced with
 memory tag
In-Reply-To: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
References: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
Message-ID: <kAv5mFUmg0cMb1Dw1j-JxiGU2z7U8zKe2txdicQnqOs=.66e8c459-a4ff-4506-92b7-02c8aca9b807@github.com>

On Tue, 25 Feb 2025 09:38:22 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> There were some remaining flag or type for Memory Tag contexts.
> 
> Tests:
> gtest:NMT* and runtime/NMT sets of tasks all passed.

+1

In older code I used to use the term "category" for a while, you can see this e.g. in the memlimit handling. Maybe you want to change that too? No strong feelings from me, if you want to leave it that is fine too. I'll approve the PR as it is now.

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

PR Review: https://git.openjdk.org/jdk/pull/23769#pullrequestreview-2666685230
PR Comment: https://git.openjdk.org/jdk/pull/23769#issuecomment-2705935052

From azafari at openjdk.org  Fri Mar  7 09:29:58 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 09:29:58 GMT
Subject: RFR: 8350565: NMT: remaining memory flag/type to be replaced with
 memory tag
In-Reply-To: <kAv5mFUmg0cMb1Dw1j-JxiGU2z7U8zKe2txdicQnqOs=.66e8c459-a4ff-4506-92b7-02c8aca9b807@github.com>
References: <3Vi1Qvv_B4FcMbQQeOoYj6xNWzuNHt-_5aArpg6MpeI=.6de0bc8b-f1cc-4898-b297-dfb968d1b27c@github.com>
 <kAv5mFUmg0cMb1Dw1j-JxiGU2z7U8zKe2txdicQnqOs=.66e8c459-a4ff-4506-92b7-02c8aca9b807@github.com>
Message-ID: <KTzM6MNPj_eOW6JxS2S7f7jnszAcQJmqy6qzx9JK1Wc=.3448f5b8-d29f-43e0-bab5-1ede0ca21d00@github.com>

On Fri, 7 Mar 2025 09:18:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> There were some remaining flag or type for Memory Tag contexts.
>> 
>> Tests:
>> gtest:NMT* and runtime/NMT sets of tasks all passed.
>
> In older code I used to use the term "category" for a while, you can see this e.g. in the memlimit handling. Maybe you want to change that too? No strong feelings from me, if you want to leave it that is fine too. I'll approve the PR as it is now.

Thank you @tstuefe for your valuable info. Unfortunately, I have already integrated the PR.
I will do the change in a future PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23769#issuecomment-2705953006

From azafari at openjdk.org  Fri Mar  7 09:36:42 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 09:36:42 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v3]
In-Reply-To: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
Message-ID: <tOnsoss1gwVzhZfXLemxosetZrJBvvek38Euhb8wqHo=.e3e3809b-4ad9-4e7a-9bf5-4335375c905e@github.com>

> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
> Tests:
> linux-x64-debug, gtest:NMT* and runtime/NMT*

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  fixed build problem.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23770/files
  - new: https://git.openjdk.org/jdk/pull/23770/files/1e7853e6..87f22f46

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

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

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

From jsjolen at openjdk.org  Fri Mar  7 10:14:12 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 7 Mar 2025 10:14:12 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v35]
In-Reply-To: <tanEOxNtClPPrczx-j_s-MnKWxAu5kDTWJshdSWERWQ=.d63aaf75-7f3a-43f1-bd8b-c517b06234f9@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <trnLKG1BO0lB-ipqibW-MaDT-Rj2jVChdzidegfencE=.a8ba936d-076b-4bf4-9214-7d37fc1cf106@github.com>
 <PcmQziLol7DrMExjxFhMFl058r41awonG_aQbnNpY98=.c3428d21-8d13-4d3c-9b30-c58e65f0be74@github.com>
 <tanEOxNtClPPrczx-j_s-MnKWxAu5kDTWJshdSWERWQ=.d63aaf75-7f3a-43f1-bd8b-c517b06234f9@github.com>
Message-ID: <RXftOVDfbPUyQ2nqGGdQUn4VW6l2GGkTgn0x_7loqZ4=.479e9b10-059a-4eaf-999a-283e3ad9cce5@github.com>

On Fri, 7 Mar 2025 08:36:14 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 49:
>> 
>>> 47: //   - uncommitted size of a MemTag should be <= of its committed size
>>> 48: //   - released size of a MemTag should be <= of its reserved size
>>> 49: 
>> 
>> I don't believe that these are checked, right? So this can be deleted.
>
> As said at the end of line, when they are applied to the VirtualMemorySummary they will be checked.
> Is it OK if I limit/wrap the comments to 80-columns text?

Aha, that's when they're checked. Feel free to do so if you want, but I don't see any problem with going above 80 columns.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1984798716

From azafari at openjdk.org  Fri Mar  7 10:26:17 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 10:26:17 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v4]
In-Reply-To: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
Message-ID: <mnZwHRyy1-5_M_I8b9TsrMpfXJY8n3bNk3N6sT965fE=.09f4b142-4589-42d1-b3cd-f6b344fc22ef@github.com>

> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
> Tests:
> linux-x64-debug, gtest:NMT* and runtime/NMT*

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  new fix.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23770/files
  - new: https://git.openjdk.org/jdk/pull/23770/files/87f22f46..3850708c

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

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

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

From azafari at openjdk.org  Fri Mar  7 16:06:32 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 16:06:32 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v5]
In-Reply-To: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
Message-ID: <0SlK7ixxGv5N7-LQnC7SwgpcK4Oz_9_H24qnrGPrTpc=.9bfd6434-6a48-4563-9dd6-66cff70dafe7@github.com>

> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
> Tests:
> linux-x64-debug, gtest:NMT* and runtime/NMT*

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge remote-tracking branch 'origin/master' into _8350566_size_par_set_tag
 - new fix.
 - fixed build problem.
 - ReservedSpace is accepted as param.
 - applied also to VMT.
 - 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag

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

Changes: https://git.openjdk.org/jdk/pull/23770/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23770&range=04
  Stats: 27 lines in 14 files changed: 6 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/23770.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23770/head:pull/23770

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

From matsaave at openjdk.org  Fri Mar  7 18:03:53 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 7 Mar 2025 18:03:53 GMT
Subject: RFR: 8350148: Native stack overflow when writing Java heap objects
 into AOT cache
In-Reply-To: <ecYJOXcu9aVwAzcPfOi7b5Jajth4JXcGsiHigLs_Q9c=.4de0ac02-e5d0-4f16-8e03-cdfdc5a51848@github.com>
References: <ecYJOXcu9aVwAzcPfOi7b5Jajth4JXcGsiHigLs_Q9c=.4de0ac02-e5d0-4f16-8e03-cdfdc5a51848@github.com>
Message-ID: <7dbz01SF6wh2Iih-rJLu8t03hDdDRW9Z5ADv09JaOfw=.fbb6f65d-21a2-454a-b108-0877889578c9@github.com>

On Sun, 16 Feb 2025 05:16:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this patch that fixes a problem that was found in the Leyden repo: when finding all cacheable heap objects with recursive calls to `HeapShared::archive_reachable_objects_from()`, very deep reference chains could cause overflow on the native stack. 
> 
> The fix is to do the recursion using a side table, without making any recursive calls.
> 
> Note: the kind of deep reference chains do not seem to happen with the mainline. It happened in the Leyden repo only after we enabled the caching of `WeakReference` objects, which are not cacheable in the mainline.

LGTM!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23654#pullrequestreview-2667965974

From azafari at openjdk.org  Fri Mar  7 18:43:54 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 18:43:54 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v2]
In-Reply-To: <Hm7tH0GQ_0k6bDmsDWqxkHwbG585FPDSIU7YSaQMZt0=.ae75e2c3-a592-454c-b8b0-e68fd09f08d1@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
 <pqI8-BOVie8_NtpoT70Bh8Qxy65D5ANTWAQeIV1IK_A=.a12a3e68-c867-4083-91e4-346f1a088dfa@github.com>
 <Hm7tH0GQ_0k6bDmsDWqxkHwbG585FPDSIU7YSaQMZt0=.ae75e2c3-a592-454c-b8b0-e68fd09f08d1@github.com>
Message-ID: <6-tmSINEwkIMphxPbnP92QmD_-i3Ui7pU9aLpeQ_PmY=.1760c755-2e70-4152-a273-1ad036c46e2e@github.com>

On Thu, 6 Mar 2025 15:24:49 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ReservedSpace is accepted as param.
>
> Need to fix the build errors:
> 
> /home/runner/work/jdk/jdk/src/hotspot/share/nmt/memTracker.hpp:224:31: error: invalid use of incomplete type ?const class ReservedSpace?
>   224 |     record_virtual_memory_tag(rs.base(), rs.size(), mem_tag);
>       |                               ^~
> In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:28:
> /home/runner/work/jdk/jdk/src/hotspot/share/memory/metaspace.hpp:38:7: note: forward declaration of ?class ReservedSpace?
>    38 | class ReservedSpace;
>       |       ^~~~~~~~~~~~~
> In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:30:
> /home/runner/work/jdk/jdk/src/hotspot/share/nmt/memTracker.hpp:224:42: error: invalid use of incomplete type ?const class ReservedSpace?
>   224 |     record_virtual_memory_tag(rs.base(), rs.size(), mem_tag);
>       |                                          ^~
> In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:28:
> /home/runner/work/jdk/jdk/src/hotspot/share/memory/metaspace.hpp:38:7: note: forward declaration of ?class ReservedSpace?
>    ... (rest of output omitted)

Thank you @gerard-ziemski and @jdksjolen for your reviews.
Build failure and merge problems fixed.
GHA tests failures are due timeout.

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

PR Comment: https://git.openjdk.org/jdk/pull/23770#issuecomment-2707162561

From coleenp at openjdk.org  Fri Mar  7 18:44:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Mar 2025 18:44:26 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions
Message-ID: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>

This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
Ran tier1 on Oracle standard platforms.

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

Commit messages:
 - 8351046: Rename ObjectMonitor functions

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

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

From coleenp at openjdk.org  Fri Mar  7 18:44:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Mar 2025 18:44:26 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions
In-Reply-To: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
Message-ID: <TYAz-AYL0qAHKxzC4mKwdizhWupmjThhveGKpJHvQF8=.15e8bfdb-1c5d-4cf9-b52c-679ac606b3f1@github.com>

On Tue, 4 Feb 2025 22:05:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
> Ran tier1 on Oracle standard platforms.

#!/bin/csh -f
cd runtime
foreach f (objectMonitor.hpp objectMonitor.inline.hpp objectMonitor.cpp)
  sed -e "s/AddWaiter/add_waiter/g" \
      -e "s/INotify/notify_internal/g" \
      -e "s/DequeueWaiter/dequeue_waiter/g" \
      -e "s/DequeueSpecificWaiter/dequeue_specific_waiter/g" \
      -e "s/EnterI/enter_internal/g" \
      -e "s/ReenterI/reenter_internal/g" \
      -e "s/UnlinkAfterAcquire/unlink_after_acquire/g" \
      -e "s/ExitEpilog/exit_epilog/g" \
      -e "s/VThreadMonitorEnter/vthread_monitor_enter/g" \
      -e "s/VThreadWait/vthread_wait/g" \
      -e "s/VThreadWaitReenter/vthread_wait_reenter/g" \
      -e "s/TryWithContentionMark/try_with_contention_mark/g" \
      -e "s/TryLock(/try_lock(/g" \
      -e "s/TrySpin/try_spin/g" \
      -e "s/VThreadEpilog/vthread_epilog/g"  $f > $f.new
  diff $f.new $f
  mv $f.new $f
end

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

PR Comment: https://git.openjdk.org/jdk/pull/23450#issuecomment-2636854789

From coleenp at openjdk.org  Fri Mar  7 18:50:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 7 Mar 2025 18:50:36 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v2]
In-Reply-To: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
Message-ID: <wtesmOkH6M5xP3ioVUYEK1XvQwhkaLTPYzIxJwFOwns=.c7c0ed96-81c0-43b5-b8a3-15caf3aff8be@github.com>

> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
> Ran tier1 on Oracle standard platforms.

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

  Typo in sed script.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23450/files
  - new: https://git.openjdk.org/jdk/pull/23450/files/832ed522..51b69761

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

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

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

From schernyshev at openjdk.org  Fri Mar  7 20:19:23 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 7 Mar 2025 20:19:23 GMT
Subject: RFR: 8351382: New test containers/docker/TestMemoryWithSubgroups.java
 is failing
Message-ID: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>

The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):

containers/docker/TestMemoryWithSubgroups.java

[STDERR]

Resource limits are not supported and ignored on cgroups V1 rootless systems

[STDOUT]

mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory

The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.

The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.

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

Commit messages:
 - 8351382: New test containers/docker/TestMemoryWithSubgroups.java is failing

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

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

From schernyshev at openjdk.org  Fri Mar  7 20:22:04 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 7 Mar 2025 20:22:04 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <YB0BPE3YrgPXxXVz-kiybyCy115iGXumKpyaw1-AcEs=.d0ec39ec-b697-4ada-b19e-bad218c0d4d2@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
 <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
 <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
 <YB0BPE3YrgPXxXVz-kiybyCy115iGXumKpyaw1-AcEs=.d0ec39ec-b697-4ada-b19e-bad218c0d4d2@github.com>
Message-ID: <deDJZA73L8kTydeDVemXCML9guQmHHHrkFiUmlZB_dU=.aa941441-2270-4c5f-aab8-fc34fc9e0167@github.com>

On Fri, 7 Mar 2025 04:34:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
>> 
>> Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.
>
> @sercher  your new test is failing in our CI:
> 
> [STDOUT]
> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
> 
> I will file a new bug - [JDK-8351382](https://bugs.openjdk.org/browse/JDK-8351382)

@dholmes-ora I submitted a fix [here](https://github.com/openjdk/jdk/pull/23948). Could you please re-run the tests in your CI?

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2707344030

From azafari at openjdk.org  Fri Mar  7 20:22:53 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Mar 2025 20:22:53 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v2]
In-Reply-To: <Hm7tH0GQ_0k6bDmsDWqxkHwbG585FPDSIU7YSaQMZt0=.ae75e2c3-a592-454c-b8b0-e68fd09f08d1@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
 <pqI8-BOVie8_NtpoT70Bh8Qxy65D5ANTWAQeIV1IK_A=.a12a3e68-c867-4083-91e4-346f1a088dfa@github.com>
 <Hm7tH0GQ_0k6bDmsDWqxkHwbG585FPDSIU7YSaQMZt0=.ae75e2c3-a592-454c-b8b0-e68fd09f08d1@github.com>
Message-ID: <E8ypfc22KCKJ1zQJk2qSONha5qqpUq7g4o4T9Czbe7M=.5ac32a38-1153-47d9-8e09-63540cf7b448@github.com>

On Thu, 6 Mar 2025 15:24:49 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ReservedSpace is accepted as param.
>
> Need to fix the build errors:
> 
> /home/runner/work/jdk/jdk/src/hotspot/share/nmt/memTracker.hpp:224:31: error: invalid use of incomplete type ?const class ReservedSpace?
>   224 |     record_virtual_memory_tag(rs.base(), rs.size(), mem_tag);
>       |                               ^~
> In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:28:
> /home/runner/work/jdk/jdk/src/hotspot/share/memory/metaspace.hpp:38:7: note: forward declaration of ?class ReservedSpace?
>    38 | class ReservedSpace;
>       |       ^~~~~~~~~~~~~
> In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:30:
> /home/runner/work/jdk/jdk/src/hotspot/share/nmt/memTracker.hpp:224:42: error: invalid use of incomplete type ?const class ReservedSpace?
>   224 |     record_virtual_memory_tag(rs.base(), rs.size(), mem_tag);
>       |                                          ^~
> In file included from /home/runner/work/jdk/jdk/src/hotspot/share/memory/allocation.cpp:28:
> /home/runner/work/jdk/jdk/src/hotspot/share/memory/metaspace.hpp:38:7: note: forward declaration of ?class ReservedSpace?
>    ... (rest of output omitted)

@gerard-ziemski and @jdksjolen, new reviews are needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23770#issuecomment-2707346222

From stefank at openjdk.org  Mon Mar 10 07:13:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 10 Mar 2025 07:13:56 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v2]
In-Reply-To: <wtesmOkH6M5xP3ioVUYEK1XvQwhkaLTPYzIxJwFOwns=.c7c0ed96-81c0-43b5-b8a3-15caf3aff8be@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
 <wtesmOkH6M5xP3ioVUYEK1XvQwhkaLTPYzIxJwFOwns=.c7c0ed96-81c0-43b5-b8a3-15caf3aff8be@github.com>
Message-ID: <Sbbfkcg93AXf-tpAKtWKWf20yKS9JTictF_Vzz9BZZU=.8d242ce5-21fb-4309-869d-20f4511612d0@github.com>

On Fri, 7 Mar 2025 18:50:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
>> Ran tier1 on Oracle standard platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo in sed script.

Nice cleanup. Maybe one nit:

src/hotspot/share/runtime/objectMonitor.cpp line 1191:

> 1189: 
> 1190:   if (node->is_wait() && !node->at_reenter()) {
> 1191:     bool acquired_monitor = vthread_waitReenter(current, node, cont);

Should this be vthread_wait_reenter?

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23450#pullrequestreview-2669972619
PR Review Comment: https://git.openjdk.org/jdk/pull/23450#discussion_r1986717980

From jsjolen at openjdk.org  Mon Mar 10 09:00:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Mar 2025 09:00:00 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v5]
In-Reply-To: <0SlK7ixxGv5N7-LQnC7SwgpcK4Oz_9_H24qnrGPrTpc=.9bfd6434-6a48-4563-9dd6-66cff70dafe7@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
 <0SlK7ixxGv5N7-LQnC7SwgpcK4Oz_9_H24qnrGPrTpc=.9bfd6434-6a48-4563-9dd6-66cff70dafe7@github.com>
Message-ID: <uFF2ItN2lHXDx5JWyswyXKFNaETbo7ipep6tpYMfWYg=.491adfec-d269-4f13-a82e-6dccdef9f968@github.com>

On Fri, 7 Mar 2025 16:06:32 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
>> Tests:
>> linux-x64-debug, gtest:NMT* and runtime/NMT*
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'origin/master' into _8350566_size_par_set_tag
>  - new fix.
>  - fixed build problem.
>  - ReservedSpace is accepted as param.
>  - applied also to VMT.
>  - 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag

Please check if this PR is responsible for the test failures before integrating.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23770#pullrequestreview-2670204517

From shade at openjdk.org  Mon Mar 10 11:35:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 11:35:13 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add
Message-ID: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>

See bug for the description of the race. New gtest test case reliably catches fire on my 5950X desktop without this fix.

I needed to add the proper constructor for `MonitorList` to make it testable. In our regular code, it is statically allocated, so its fields are implicitly initialized.

I also made counters `_relaxed` for completeness.

Additional testing:
 - [x] Linux x86_64 server fastdebug, new test now passes
 - [ ] GHA

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

Commit messages:
 - Test touchups
 - Comments
 - Fix

Changes: https://git.openjdk.org/jdk/pull/23961/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23961&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351484
  Stats: 45 lines in 3 files changed: 41 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23961.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23961/head:pull/23961

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

From coleenp at openjdk.org  Mon Mar 10 12:38:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Mar 2025 12:38:53 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v2]
In-Reply-To: <Sbbfkcg93AXf-tpAKtWKWf20yKS9JTictF_Vzz9BZZU=.8d242ce5-21fb-4309-869d-20f4511612d0@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
 <wtesmOkH6M5xP3ioVUYEK1XvQwhkaLTPYzIxJwFOwns=.c7c0ed96-81c0-43b5-b8a3-15caf3aff8be@github.com>
 <Sbbfkcg93AXf-tpAKtWKWf20yKS9JTictF_Vzz9BZZU=.8d242ce5-21fb-4309-869d-20f4511612d0@github.com>
Message-ID: <6HaEGp0sRsYSIAkQwejjSjJBJszqkz6T3fMx98b9gJY=.1dd9392e-c96a-4da5-ab44-3342e82cf346@github.com>

On Mon, 10 Mar 2025 07:09:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo in sed script.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1191:
> 
>> 1189: 
>> 1190:   if (node->is_wait() && !node->at_reenter()) {
>> 1191:     bool acquired_monitor = vthread_waitReenter(current, node, cont);
> 
> Should this be vthread_wait_reenter?

Thank you for seeing this.  I've changed that one too. There are still a couple of data members with mixed names.  _WaitSet, _WaitSetMonitor and _SpinDuration.  Should I change them too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23450#discussion_r1987201137

From coleenp at openjdk.org  Mon Mar 10 12:42:27 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Mar 2025 12:42:27 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v3]
In-Reply-To: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
Message-ID: <B7v_kcatRX7Dx1dV8gYVuEwYPZh43n9ZJDwdyQRqQ3M=.eb8429f7-3a69-4181-9d8d-56b49eecc995@github.com>

> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
> Ran tier1 on Oracle standard platforms.

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

  Rename vthread_waitRenter.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23450/files
  - new: https://git.openjdk.org/jdk/pull/23450/files/51b69761..6f356df0

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

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

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

From coleenp at openjdk.org  Mon Mar 10 12:47:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Mar 2025 12:47:54 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v2]
In-Reply-To: <6HaEGp0sRsYSIAkQwejjSjJBJszqkz6T3fMx98b9gJY=.1dd9392e-c96a-4da5-ab44-3342e82cf346@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
 <wtesmOkH6M5xP3ioVUYEK1XvQwhkaLTPYzIxJwFOwns=.c7c0ed96-81c0-43b5-b8a3-15caf3aff8be@github.com>
 <Sbbfkcg93AXf-tpAKtWKWf20yKS9JTictF_Vzz9BZZU=.8d242ce5-21fb-4309-869d-20f4511612d0@github.com>
 <6HaEGp0sRsYSIAkQwejjSjJBJszqkz6T3fMx98b9gJY=.1dd9392e-c96a-4da5-ab44-3342e82cf346@github.com>
Message-ID: <VBCETdt_CvwuUxci67v-czMyWgRLXUMyA57PTAWK1c8=.b594bc6d-ae31-4570-8ec9-9d037d8cd75e@github.com>

On Mon, 10 Mar 2025 12:35:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1191:
>> 
>>> 1189: 
>>> 1190:   if (node->is_wait() && !node->at_reenter()) {
>>> 1191:     bool acquired_monitor = vthread_waitReenter(current, node, cont);
>> 
>> Should this be vthread_wait_reenter?
>
> Thank you for seeing this.  I've changed that one too. There are still a couple of data members with mixed names.  _WaitSet, _WaitSetMonitor and _SpinDuration.  Should I change them too?

Then this leaves TState in ObjectWaiter which we should deal with separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23450#discussion_r1987214612

From coleenp at openjdk.org  Mon Mar 10 13:11:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Mar 2025 13:11:33 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v4]
In-Reply-To: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
Message-ID: <5fm-uQrf6xoioJFj2THj5IYFVUhhmhNz9OM1dtuiU_g=.17a914f9-ee83-4a2d-baed-8c6aed68cc6e@github.com>

> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
> Ran tier1 on Oracle standard platforms.

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

  Rename WaitSet, WaitSetLock and SpinDuration to follow hotspot coding style.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23450/files
  - new: https://git.openjdk.org/jdk/pull/23450/files/6f356df0..cd95e5b0

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

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

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

From stefank at openjdk.org  Mon Mar 10 13:15:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 10 Mar 2025 13:15:57 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v4]
In-Reply-To: <5fm-uQrf6xoioJFj2THj5IYFVUhhmhNz9OM1dtuiU_g=.17a914f9-ee83-4a2d-baed-8c6aed68cc6e@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
 <5fm-uQrf6xoioJFj2THj5IYFVUhhmhNz9OM1dtuiU_g=.17a914f9-ee83-4a2d-baed-8c6aed68cc6e@github.com>
Message-ID: <hNOjCMVr96ZaAbyRc2E9NUTY7wkM7cMfkzPBRIlt_CM=.6161c313-09f9-4d60-8df0-6b3697a23006@github.com>

On Mon, 10 Mar 2025 13:11:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
>> Ran tier1 on Oracle standard platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename WaitSet, WaitSetLock and SpinDuration to follow hotspot coding style.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23450#pullrequestreview-2670912619

From sgehwolf at openjdk.org  Mon Mar 10 13:51:54 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Mar 2025 13:51:54 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing
In-Reply-To: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
Message-ID: <tZdYaO_7_aRNZfHubReFokE8EMgFOOki9aXctuBTutg=.d4da87e3-2563-4597-b44c-e61b441e1d96@github.com>

On Fri, 7 Mar 2025 20:14:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
> 
> containers/docker/TestMemoryWithSubgroups.java
> 
> [STDERR]
> 
> Resource limits are not supported and ignored on cgroups V1 rootless systems
> 
> [STDOUT]
> 
> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
> 
> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
> 
> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.

This won't work under `podman`:


$ podman info -f '{{println .SecurityOptions}}
> '
Error: template: info:1:10: executing "info" at <.SecurityOptions>: can't evaluate field SecurityOptions in type system.infoReport


I'm not sure we need to go through the `SecurityOptions` thing. How about `if (!Platform.isRoot()) { ... }`?

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

Changes requested by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23948#pullrequestreview-2671024708

From stuefe at openjdk.org  Mon Mar 10 14:11:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 10 Mar 2025 14:11:01 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v5]
In-Reply-To: <oJjAjXaPQgDh7AYdSDzC3vPbxA669H68ZlbjfyLeDUo=.06dd0b2d-6428-4da4-aa8c-7c0c14d26c9d@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <oJjAjXaPQgDh7AYdSDzC3vPbxA669H68ZlbjfyLeDUo=.06dd0b2d-6428-4da4-aa8c-7c0c14d26c9d@github.com>
Message-ID: <VrSCn0QSbirNrG731vQ1iAldcn_GZKRsV4Nrk-NtifY=.c736b36c-078b-4a2f-9b5e-839d6f901459@github.com>

On Fri, 7 Mar 2025 01:46:37 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

+1

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2671094029

From fbredberg at openjdk.org  Mon Mar 10 14:27:56 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 10 Mar 2025 14:27:56 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v4]
In-Reply-To: <5fm-uQrf6xoioJFj2THj5IYFVUhhmhNz9OM1dtuiU_g=.17a914f9-ee83-4a2d-baed-8c6aed68cc6e@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
 <5fm-uQrf6xoioJFj2THj5IYFVUhhmhNz9OM1dtuiU_g=.17a914f9-ee83-4a2d-baed-8c6aed68cc6e@github.com>
Message-ID: <NBLw1ni6MaITOkNo8uvR2dnTnp7JAZQxLHNa7GGDvvg=.cf0ce230-8e65-43c1-a106-f9562b2a1165@github.com>

On Mon, 10 Mar 2025 13:11:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
>> Ran tier1 on Oracle standard platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename WaitSet, WaitSetLock and SpinDuration to follow hotspot coding style.

Nice work!
Really like that you supplied the `sed` script as an overview of the changes.
Also `whatever_internal` is so mush better than the old `WhateverI`.

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

Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23450#pullrequestreview-2671161285

From coleenp at openjdk.org  Mon Mar 10 14:57:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Mar 2025 14:57:13 GMT
Subject: RFR: 8351046: Rename ObjectMonitor functions [v4]
In-Reply-To: <5fm-uQrf6xoioJFj2THj5IYFVUhhmhNz9OM1dtuiU_g=.17a914f9-ee83-4a2d-baed-8c6aed68cc6e@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
 <5fm-uQrf6xoioJFj2THj5IYFVUhhmhNz9OM1dtuiU_g=.17a914f9-ee83-4a2d-baed-8c6aed68cc6e@github.com>
Message-ID: <C6Rzi7PY_v1vYHmyY7_Hcw_YIJCVPsTR2ww2vyX2Jt0=.0c77b29e-a22b-4dbe-b936-6ca491c3d83e@github.com>

On Mon, 10 Mar 2025 13:11:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
>> Ran tier1 on Oracle standard platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename WaitSet, WaitSetLock and SpinDuration to follow hotspot coding style.

I didn't know what the capital "I" stood for reading the code until someone told me.  Thanks for the reviews, Stefan and Fredrick.

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

PR Comment: https://git.openjdk.org/jdk/pull/23450#issuecomment-2710875021

From coleenp at openjdk.org  Mon Mar 10 14:57:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Mar 2025 14:57:13 GMT
Subject: Integrated: 8351046: Rename ObjectMonitor functions
In-Reply-To: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
References: <y7Howu_INfiCTtZAOij9BYt1JWsYEecwgfx4dN9dHOY=.bd88edb6-6b65-49b5-a265-43d1970e0c32@github.com>
Message-ID: <usjh5iuFHdqK0KcUptNFQ5-5PPpuiRu8DgcKyB7HnhE=.0fff71a7-3cf9-4aa3-947d-1eaf2be28a60@github.com>

On Tue, 4 Feb 2025 22:05:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change simply changes the remaining names of functions in objectMonitor that were camel case, now following the hotspot coding standard.  Recent changes have been confused about which style to use, so this helps with this.  This is a mechanical change, largely trivial.  Further improvements can be different PRs, but any names missed could be added to this.
> Ran tier1 on Oracle standard platforms.

This pull request has now been integrated.

Changeset: d90b79a2
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d90b79a2bd2f8bb6e50aa32aafe47748ef6ebeff
Stats:     135 lines in 4 files changed: 0 ins; 0 del; 135 mod

8351046: Rename ObjectMonitor functions

Reviewed-by: stefank, fbredberg

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

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

From rrich at openjdk.org  Mon Mar 10 15:19:41 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 10 Mar 2025 15:19:41 GMT
Subject: RFR: 8350106: [PPC] Avoid ticks_unknown_not_Java
 AsyncGetCallTrace() if JavaFrameAnchor::_last_Java_pc not set [v2]
In-Reply-To: <fG3cfS2iVP5NMb35AvZ0XJ76bDWckrZtDHB1FK7Ez98=.df7b5652-1b62-4201-8609-e2d03ba54f2e@github.com>
References: <fG3cfS2iVP5NMb35AvZ0XJ76bDWckrZtDHB1FK7Ez98=.df7b5652-1b62-4201-8609-e2d03ba54f2e@github.com>
Message-ID: <Wm1fuLYTcgBk8epsfua_re1Q9xUPh61queLKPeqebuM=.4cf97c8b-9026-49db-a325-bb2834d0794f@github.com>

> This pr changes `JavaThread::pd_get_top_frame_for_profiling` to better address situations where
> 
> 1. `JavaThread::last_Java_sp()` returns != null
> 2. `JavaThread::last_Java_pc()` returns null
> 
> If the runtime needs to walk the stack of a java thread in that state, e.g. for gc purposes, it finds the last java pc relative to the last java sp (see [frame::setup()](https://github.com/openjdk/jdk/blob/3f0c1370269db978072814c2170fc3987efade85/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L40)).
> 
> This relies on the runtime method being called to store the return pc to its caller's abi which it will do when pushing a new frame for calling another method.
> 
> For an asynchronous interrupt to sample the stack this means: if there isn't at least one frame between the last java frame and the frame where the interrupt occurred then we can't be sure that the return pc was already saved and `pd_get_top_frame_for_profiling()` needs to return false indicating failure.
> 
> Otherwise we can and should proceed constructing a frame even though `JavaThread::last_Java_pc()` returned null.
> 
> Testing:
> 
> * DaCapo Tomcat with async-profiler on a fastdebug build.
> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master'
 - Better handle _last_Java_pc == null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23640/files
  - new: https://git.openjdk.org/jdk/pull/23640/files/768bfcbd..0f210b81

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

  Stats: 46154 lines in 1399 files changed: 21589 ins; 17852 del; 6713 mod
  Patch: https://git.openjdk.org/jdk/pull/23640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23640/head:pull/23640

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

From jiangli at openjdk.org  Mon Mar 10 17:05:07 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 10 Mar 2025 17:05:07 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
Message-ID: <Tu00R_BUSIQyZaGIk2RKQtF7vInUz1ebQqeN4SN93Q0=.84ae1f8c-1a98-4920-8827-85e1a5e133c3@github.com>

On Tue, 4 Mar 2025 18:48:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> Jiangli and I chatted about this today. We don't think there will be developers looking to specify -server or -client to a static image, instead this is more about the tests. So we think the best think is to look at the tests that still specify -server and see if it can be dropped. Some of the tests (say for C2) might be better off using `@requires vm.compiler2.enabled` or `@requires vm.flavor == "server"`.

@AlanBateman @dholmes-ora @iklam Do you have any other comments/questions about the change? @vnkozlov or others from compiler side, can you please take a look of the change as well? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2711261297

From pchilanomate at openjdk.org  Mon Mar 10 17:32:54 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 10 Mar 2025 17:32:54 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add
In-Reply-To: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
Message-ID: <rm7yogsfw9-tXfZ4BfkVGE6ikPfpoMHrIbYRH0wztAc=.b4efdbd5-b7bf-4a20-a9b4-d3dff66c81f4@github.com>

On Mon, 10 Mar 2025 11:30:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for the description of the race. New gtest test case reliably catches fire on my 5950X desktop without this fix.
> 
> I needed to add the proper constructor for `MonitorList` to make it testable. In our regular code, it is statically allocated, so its fields are implicitly initialized.
> 
> I also made counter updates `_relaxed` for completeness.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test now passes
>  - [x] GHA

Looks good to me.

test/hotspot/gtest/runtime/test_synchronizer.cpp line 81:

> 79: 
> 80:   // Something to reference in OM. It makes no difference which oop it is,
> 81:   // as long as it is correct.

Can?t we still safepoint on `workers.doit()` when calling `VMThreadBlocker::start()`? Maybe we could use a Handle to be safe. Sidenote: This is pre-existent but isn?t `TestThreadGroup::doit()` missing a call to `_blocker->ready()` before starting the worker threads?

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

PR Review: https://git.openjdk.org/jdk/pull/23961#pullrequestreview-2671728147
PR Review Comment: https://git.openjdk.org/jdk/pull/23961#discussion_r1987731880

From shade at openjdk.org  Mon Mar 10 19:37:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 19:37:21 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add [v2]
In-Reply-To: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
Message-ID: <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>

> See bug for the description of the race. New gtest test case reliably catches fire on my 5950X desktop without this fix.
> 
> I needed to add the proper constructor for `MonitorList` to make it testable. In our regular code, it is statically allocated, so its fields are implicitly initialized.
> 
> I also made counter updates `_relaxed` for completeness.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test now passes
>  - [x] GHA

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Can check <=
 - Object handle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23961/files
  - new: https://git.openjdk.org/jdk/pull/23961/files/5625984d..c3cb9fea

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

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

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

From zgu at openjdk.org  Mon Mar 10 19:37:21 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 10 Mar 2025 19:37:21 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add [v2]
In-Reply-To: <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
 <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
Message-ID: <cFGJEsvltOpbXOsJW9fl0zIQ76c3s10aNlOv4fC6Jhk=.ef33fd7c-4e4b-4415-b944-201ab53fce5f@github.com>

On Mon, 10 Mar 2025 19:34:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for the description of the race. New gtest test case reliably catches fire on my 5950X desktop without this fix.
>> 
>> I needed to add the proper constructor for `MonitorList` to make it testable. In our regular code, it is statically allocated, so its fields are implicitly initialized.
>> 
>> I also made counter updates `_relaxed` for completeness.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, new test now passes
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Can check <=
>  - Object handle

src/hotspot/share/runtime/synchronizer.cpp line 83:

> 81:   do {
> 82:     old_max = Atomic::load(&_max);
> 83:     if (count < old_max) {

Can breakout when `count == old_max`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23961#discussion_r1987903286

From shade at openjdk.org  Mon Mar 10 19:37:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 19:37:21 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add [v2]
In-Reply-To: <cFGJEsvltOpbXOsJW9fl0zIQ76c3s10aNlOv4fC6Jhk=.ef33fd7c-4e4b-4415-b944-201ab53fce5f@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
 <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
 <cFGJEsvltOpbXOsJW9fl0zIQ76c3s10aNlOv4fC6Jhk=.ef33fd7c-4e4b-4415-b944-201ab53fce5f@github.com>
Message-ID: <PtnVn26kC9bB38LoeITph3Vr6RA23y7s9WYz19uAPfo=.63d990e7-a051-46ba-9976-0bff7af30293@github.com>

On Mon, 10 Mar 2025 19:32:52 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Can check <=
>>  - Object handle
>
> src/hotspot/share/runtime/synchronizer.cpp line 83:
> 
>> 81:   do {
>> 82:     old_max = Atomic::load(&_max);
>> 83:     if (count < old_max) {
> 
> Can breakout when `count == old_max`

Right! Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23961#discussion_r1987905363

From shade at openjdk.org  Mon Mar 10 19:37:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Mar 2025 19:37:21 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add [v2]
In-Reply-To: <rm7yogsfw9-tXfZ4BfkVGE6ikPfpoMHrIbYRH0wztAc=.b4efdbd5-b7bf-4a20-a9b4-d3dff66c81f4@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
 <rm7yogsfw9-tXfZ4BfkVGE6ikPfpoMHrIbYRH0wztAc=.b4efdbd5-b7bf-4a20-a9b4-d3dff66c81f4@github.com>
Message-ID: <CbchGuzH4WIA0GnLIcmPg6QWwl7YS43DG2p9FhX8PZg=.a95f8832-d1cd-489e-a601-97a8ff9ac2bd@github.com>

On Mon, 10 Mar 2025 17:27:08 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Can check <=
>>  - Object handle
>
> test/hotspot/gtest/runtime/test_synchronizer.cpp line 81:
> 
>> 79: 
>> 80:   // Something to reference in OM. It makes no difference which oop it is,
>> 81:   // as long as it is correct.
> 
> Can?t we still safepoint on `workers.doit()` when calling `VMThreadBlocker::start()`? Maybe we could use a Handle to be safe. Sidenote: This is pre-existent but isn?t `TestThreadGroup::doit()` missing a call to `_blocker->ready()` before starting the worker threads?

Right, I copy-pasted oop allocation from another test, but forgot to copy-paste the oop handle. Fixed now.

For `TestThreadGroup::doit()`, yeah, looks like `_blocker->ready()` is missing. It looks innocuous to this test, but we should really fix it, perhaps separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23961#discussion_r1987903694

From alanb at openjdk.org  Mon Mar 10 19:57:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Mar 2025 19:57:00 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v2]
In-Reply-To: <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <2fluPJGNiu9SvOwq6MfyLch7lChTjPlOJh7dcrXxfa4=.55bdfd48-08dd-4f14-b683-88fccbc66e1e@github.com>
Message-ID: <ASnv4rZ37WiIQTfZnQj9hqkAl18T-69Idm9rieYtiUc=.338fe9f3-1f3e-4539-a228-06ce29683d62@github.com>

On Thu, 6 Mar 2025 02:18:43 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove '-server' from all following tests.
>    
>    Add?@requires vm.flavor == "server" & !vm.emulatedClient since these tests run on c2:
>    - compiler/c2/TestReduceAllocationAndHeapDump.java
>    - compiler/inlining/InlineBimorphicVirtualCallAfterMorphismChanged.java
>    
>    These tests already have @requires?vm.compiler2.enabled:
>    - compiler/c2/TestReduceAllocationAndLoadKlass.java
>    - compiler/c2/TestReduceAllocationAndNonExactAllocate.java
>    - compiler/c2/TestReduceAllocationAndNullableLoads.java
>    - compiler/c2/TestReduceAllocationAndPointerComparisons.java
>    - compiler/escapeAnalysis/TestIterativeEA.java
>    
>    Can run on c1/c2:
>    - compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java
>    
>    Already have @requires vm.flavor == "server":
>    - compiler/intrinsics/math/TestMinMaxIntrinsics.java
>    - compiler/profiling/TestTypeProfiling.java
>    - gc/stress/gcbasher/TestGCBasherWithG1.java
>    - gc/stress/gcbasher/TestGCBasherWithParallel.java
>    - gc/stress/gcbasher/TestGCBasherWithSerial.java
>    
>    Not compiler specific:
>    - runtime/CDSCompressedKPtrs/XShareAuto.java
>  - Revert src/hotspot/share/runtime/arguments.cpp.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23881#pullrequestreview-2672048988

From alanb at openjdk.org  Mon Mar 10 19:57:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Mar 2025 19:57:01 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
Message-ID: <7YqG7ryKpJEk6hBnKnTj3Y_O2p_9x7XfT0M6jNw7nQg=.c5b75d99-9ce0-4898-a174-3646cfc4402a@github.com>

On Tue, 4 Mar 2025 18:48:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> Jiangli and I chatted about this today. We don't think there will be developers looking to specify -server or -client to a static image, instead this is more about the tests. So we think the best think is to look at the tests that still specify -server and see if it can be dropped. Some of the tests (say for C2) might be better off using `@requires vm.compiler2.enabled` or `@requires vm.flavor == "server"`.

> @AlanBateman @dholmes-ora @iklam Do you have any other comments/questions about the change? @vnkozlov or others from compiler side, can you please take a look of the change as well? Thanks

I wasn't initially sure about XShareAuto.java but I see the exchange between you and Ioi so I think all good.

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2711673676

From pchilanomate at openjdk.org  Mon Mar 10 21:37:52 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 10 Mar 2025 21:37:52 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add [v2]
In-Reply-To: <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
 <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
Message-ID: <sK63xmPAt9FNjtVyVccQjSCrJU4XgV0-vWqHuAMyokQ=.df64965f-8d31-4efd-a580-47807db893f1@github.com>

On Mon, 10 Mar 2025 19:37:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for the description of the race. New gtest test case reliably catches fire on my 5950X desktop without this fix.
>> 
>> I needed to add the proper constructor for `MonitorList` to make it testable. In our regular code, it is statically allocated, so its fields are implicitly initialized.
>> 
>> I also made counter updates `_relaxed` for completeness.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, new test now passes
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Can check <=
>  - Object handle

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23961#pullrequestreview-2672250765

From pchilanomate at openjdk.org  Mon Mar 10 21:37:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 10 Mar 2025 21:37:53 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add [v2]
In-Reply-To: <CbchGuzH4WIA0GnLIcmPg6QWwl7YS43DG2p9FhX8PZg=.a95f8832-d1cd-489e-a601-97a8ff9ac2bd@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
 <rm7yogsfw9-tXfZ4BfkVGE6ikPfpoMHrIbYRH0wztAc=.b4efdbd5-b7bf-4a20-a9b4-d3dff66c81f4@github.com>
 <CbchGuzH4WIA0GnLIcmPg6QWwl7YS43DG2p9FhX8PZg=.a95f8832-d1cd-489e-a601-97a8ff9ac2bd@github.com>
Message-ID: <U6OLvu0sYhyjjQQTYkorxtILiJ6fRqvOiANsuUkUkNg=.d2b03f54-392b-4dd2-8889-12fc34dc2f89@github.com>

On Mon, 10 Mar 2025 19:33:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/hotspot/gtest/runtime/test_synchronizer.cpp line 81:
>> 
>>> 79: 
>>> 80:   // Something to reference in OM. It makes no difference which oop it is,
>>> 81:   // as long as it is correct.
>> 
>> Can?t we still safepoint on `workers.doit()` when calling `VMThreadBlocker::start()`? Maybe we could use a Handle to be safe. Sidenote: This is pre-existent but isn?t `TestThreadGroup::doit()` missing a call to `_blocker->ready()` before starting the worker threads?
>
> Right, I copy-pasted oop allocation from another test, but forgot to copy-paste the oop handle. Fixed now.
> 
> For `TestThreadGroup::doit()`, yeah, looks like `_blocker->ready()` is missing. It looks innocuous to this test, but we should really fix it, perhaps separately.

Thanks, filed JDK-8351599 for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23961#discussion_r1988054564

From zgu at openjdk.org  Tue Mar 11 00:52:58 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 11 Mar 2025 00:52:58 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add [v2]
In-Reply-To: <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
 <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
Message-ID: <rRwCoWtPg0kjcr1BNfZkL5bioxTilm1nOKtZVzQ0LTE=.0977d69d-aa2b-4d60-be69-ae4a41472c5c@github.com>

On Mon, 10 Mar 2025 19:37:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for the description of the race. New gtest test case reliably catches fire on my 5950X desktop without this fix.
>> 
>> I needed to add the proper constructor for `MonitorList` to make it testable. In our regular code, it is statically allocated, so its fields are implicitly initialized.
>> 
>> I also made counter updates `_relaxed` for completeness.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, new test now passes
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Can check <=
>  - Object handle

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23961#pullrequestreview-2672468427

From schernyshev at openjdk.org  Tue Mar 11 00:53:34 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 11 Mar 2025 00:53:34 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <tZdYaO_7_aRNZfHubReFokE8EMgFOOki9aXctuBTutg=.d4da87e3-2563-4597-b44c-e61b441e1d96@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <tZdYaO_7_aRNZfHubReFokE8EMgFOOki9aXctuBTutg=.d4da87e3-2563-4597-b44c-e61b441e1d96@github.com>
Message-ID: <L3IFp8JkveJz_p8RDOmQFuhAE3mNVNGZTMYu4ls-2oQ=.fa3daf28-e50d-43b1-9fb4-91b76a22865f@github.com>

On Mon, 10 Mar 2025 13:49:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This won't work under `podman`:
> 
> ```
> $ podman info -f '{{println .SecurityOptions}}
> > '
> Error: template: info:1:10: executing "info" at <.SecurityOptions>: can't evaluate field SecurityOptions in type system.infoReport
> ```
> I'm not sure we need to go through the `SecurityOptions` thing. How about `if (!Platform.isRoot()) { ... }`?

Thanks @jerboaa , I updated the PR, please take a look.
`Platform.isRoot()` works with podman, but it doesn't work with docker. The latter depends on the mode in which the dockerd runs, rather than on whether the container is started with root privileges.

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2712177546

From schernyshev at openjdk.org  Tue Mar 11 00:53:34 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 11 Mar 2025 00:53:34 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
Message-ID: <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>

> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
> 
> containers/docker/TestMemoryWithSubgroups.java
> 
> [STDERR]
> 
> Resource limits are not supported and ignored on cgroups V1 rootless systems
> 
> [STDOUT]
> 
> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
> 
> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
> 
> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  addressed review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23948/files
  - new: https://git.openjdk.org/jdk/pull/23948/files/a2608afc..eff5ac46

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

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

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

From amenkov at openjdk.org  Tue Mar 11 01:39:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 11 Mar 2025 01:39:55 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
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: <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@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:

  restore ThreadBlockInVM in complete

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23405/files
  - new: https://git.openjdk.org/jdk/pull/23405/files/2a3d4346..ed569cc7

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 amenkov at openjdk.org  Tue Mar 11 03:16:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 11 Mar 2025 03:16:57 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
Message-ID: <Cv5gj_nlKbEiEPNQk6K3S4pep8iApUD2JXsTQDl3Qt8=.767a3bac-cb27-4128-827a-0b47e5671ef3@github.com>

On Tue, 11 Mar 2025 01:39:55 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:
> 
>   restore ThreadBlockInVM in complete

Added ThreadBlockInVM in complete() method to do the same as old implementation.
It solves macos-aarch64 failure of test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitUncommitRecommit.java test in GHA

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

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

From iklam at openjdk.org  Tue Mar 11 03:17:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Mar 2025 03:17:58 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <7YqG7ryKpJEk6hBnKnTj3Y_O2p_9x7XfT0M6jNw7nQg=.c5b75d99-9ce0-4898-a174-3646cfc4402a@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
 <7YqG7ryKpJEk6hBnKnTj3Y_O2p_9x7XfT0M6jNw7nQg=.c5b75d99-9ce0-4898-a174-3646cfc4402a@github.com>
Message-ID: <jiL8VUK-AsvsOzEVnERPb6DxewVzp2jJCfLNIlZoI88=.70ed0604-0d0c-4a2a-a5d1-e7f7f5322427@github.com>

On Mon, 10 Mar 2025 19:54:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @AlanBateman @dholmes-ora @iklam Do you have any other comments/questions about the change? @vnkozlov or others from compiler side, can you please take a look of the change as well? Thanks

Please remove  `* @bug 8005933` from XShareAuto.java as it no longer applies to that bug ID.

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2712457754

From iklam at openjdk.org  Tue Mar 11 06:52:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Mar 2025 06:52:11 GMT
Subject: RFR: 8350148: Native stack overflow when writing Java heap objects
 into AOT cache
In-Reply-To: <DSZF9FrQvxSwaPw4zDpjdE-2K5GH9N7FwJYe9hLKsiE=.34cbc757-96ca-4829-8011-7a1496ccf2a0@github.com>
References: <ecYJOXcu9aVwAzcPfOi7b5Jajth4JXcGsiHigLs_Q9c=.4de0ac02-e5d0-4f16-8e03-cdfdc5a51848@github.com>
 <DSZF9FrQvxSwaPw4zDpjdE-2K5GH9N7FwJYe9hLKsiE=.34cbc757-96ca-4829-8011-7a1496ccf2a0@github.com>
Message-ID: <4u8K0yS6Psbta9SBEwSAWRlk6ozuUY828JW2mR55PdU=.b9029a2b-d113-4e13-8743-15806c253987@github.com>

On Wed, 5 Mar 2025 22:35:25 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Please review this patch that fixes a problem that was found in the Leyden repo: when finding all cacheable heap objects with recursive calls to `HeapShared::archive_reachable_objects_from()`, very deep reference chains could cause overflow on the native stack. 
>> 
>> The fix is to do the recursion using a side table, without making any recursive calls.
>> 
>> Note: the kind of deep reference chains do not seem to happen with the mainline. It happened in the Leyden repo only after we enabled the caching of `WeakReference` objects, which are not cacheable in the mainline.
>
> Looks good

Thanks @veresov and @matias9927 for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/23654#issuecomment-2712857893

From iklam at openjdk.org  Tue Mar 11 06:52:11 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 11 Mar 2025 06:52:11 GMT
Subject: Integrated: 8350148: Native stack overflow when writing Java heap
 objects into AOT cache
In-Reply-To: <ecYJOXcu9aVwAzcPfOi7b5Jajth4JXcGsiHigLs_Q9c=.4de0ac02-e5d0-4f16-8e03-cdfdc5a51848@github.com>
References: <ecYJOXcu9aVwAzcPfOi7b5Jajth4JXcGsiHigLs_Q9c=.4de0ac02-e5d0-4f16-8e03-cdfdc5a51848@github.com>
Message-ID: <ET0hrmsqaAl5oNjF_Md7cosbyvjv1VC4KoAflZg9uiM=.e4048406-2d84-4eca-b9cf-266c1a2f9fa9@github.com>

On Sun, 16 Feb 2025 05:16:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this patch that fixes a problem that was found in the Leyden repo: when finding all cacheable heap objects with recursive calls to `HeapShared::archive_reachable_objects_from()`, very deep reference chains could cause overflow on the native stack. 
> 
> The fix is to do the recursion using a side table, without making any recursive calls.
> 
> Note: the kind of deep reference chains do not seem to happen with the mainline. It happened in the Leyden repo only after we enabled the caching of `WeakReference` objects, which are not cacheable in the mainline.

This pull request has now been integrated.

Changeset: 8a5ed47f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a5ed47f00d74d4eb0d2b8027fb92ff2f5c30163
Stats:     104 lines in 2 files changed: 69 ins; 17 del; 18 mod

8350148: Native stack overflow when writing Java heap objects into AOT cache

Reviewed-by: iveresov, matsaave

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

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

From sgehwolf at openjdk.org  Tue Mar 11 10:01:10 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Mar 2025 10:01:10 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
Message-ID: <IPAwPe65wneDge77lwbKCr4GgTPyonrsIPe6dkZfuWM=.58195098-d8bc-45c7-a160-ad0476ec929f@github.com>

On Tue, 11 Mar 2025 00:53:34 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
>> 
>> containers/docker/TestMemoryWithSubgroups.java
>> 
>> [STDERR]
>> 
>> Resource limits are not supported and ignored on cgroups V1 rootless systems
>> 
>> [STDOUT]
>> 
>> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
>> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
>> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
>> 
>> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
>> 
>> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review comment

Looks fine to me. I haven't tested the rootless docker setup, though. So perhaps this should go through Oracle's CI before integrating.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23948#pullrequestreview-2673708923

From sgehwolf at openjdk.org  Tue Mar 11 10:01:11 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Mar 2025 10:01:11 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <L3IFp8JkveJz_p8RDOmQFuhAE3mNVNGZTMYu4ls-2oQ=.fa3daf28-e50d-43b1-9fb4-91b76a22865f@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <tZdYaO_7_aRNZfHubReFokE8EMgFOOki9aXctuBTutg=.d4da87e3-2563-4597-b44c-e61b441e1d96@github.com>
 <L3IFp8JkveJz_p8RDOmQFuhAE3mNVNGZTMYu4ls-2oQ=.fa3daf28-e50d-43b1-9fb4-91b76a22865f@github.com>
Message-ID: <SohE1gESrChD-i2XjdA8hapMWoO83O1ms9z7cMhC7M4=.2fcdc233-d6ec-48f3-92f8-e6d078dfd5e1@github.com>

On Tue, 11 Mar 2025 00:50:42 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> > This won't work under `podman`:
> > ```
> > $ podman info -f '{{println .SecurityOptions}}
> > > '
> > Error: template: info:1:10: executing "info" at <.SecurityOptions>: can't evaluate field SecurityOptions in type system.infoReport
> > ```
> > I'm not sure we need to go through the `SecurityOptions` thing. How about `if (!Platform.isRoot()) { ... }`?
> 
> Thanks @jerboaa , I updated the PR, please take a look. `Platform.isRoot()` works with podman, but it doesn't work with docker. The latter depends on the mode in which the dockerd runs, rather than on whether the container is started with root privileges.

This would be useful info to have in the JBS issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2713445551

From schernyshev at openjdk.org  Tue Mar 11 10:56:53 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 11 Mar 2025 10:56:53 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <IPAwPe65wneDge77lwbKCr4GgTPyonrsIPe6dkZfuWM=.58195098-d8bc-45c7-a160-ad0476ec929f@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
 <IPAwPe65wneDge77lwbKCr4GgTPyonrsIPe6dkZfuWM=.58195098-d8bc-45c7-a160-ad0476ec929f@github.com>
Message-ID: <ouKed_QE8qwiZEQ4i5vG1Mkpq_xdQXr8pp8y631FfUk=.ce42f76f-96fe-46c6-b072-b1f2caed8e9e@github.com>

On Tue, 11 Mar 2025 09:57:24 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Looks fine to me. I haven't tested the rootless docker setup, though. So perhaps this should go through Oracle's CI before integrating.

@dholmes-ora Could you please have a look and re-run the tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2713669976

From coleenp at openjdk.org  Tue Mar 11 12:20:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 12:20:39 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread
Message-ID: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>

This is a minor mostly trivial change I found while reading through code looking for something else.
Tested with tier1-4.

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

Commit messages:
 - 8351651: Cleanup LockStack::is_owning_thread

Changes: https://git.openjdk.org/jdk/pull/23981/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23981&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351651
  Stats: 27 lines in 4 files changed: 8 ins; 15 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23981/head:pull/23981

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

From stefank at openjdk.org  Tue Mar 11 12:56:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Mar 2025 12:56:55 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread
In-Reply-To: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
Message-ID: <kzLcpKFyBii5eFlOASAPwkhJIXakLQOEw-fOzvebA_E=.6e28c26a-8ecb-4f75-b880-69b0fc50e6cd@github.com>

On Tue, 11 Mar 2025 12:15:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a minor mostly trivial change I found while reading through code looking for something else.
> Tested with tier1-4.

Is this change really that important? It looks like this is a small optimization for non-product verification code. Why do we need to micro optimize that?

Or did I miss some subtle part that makes this look cleaner? Could you explain why this is cleaner?

src/hotspot/share/runtime/synchronizer.cpp line 413:

> 411:     return LightweightSynchronizer::quick_enter(obj, lock, current);
> 412:   }
> 413: 

This looks unrelated.

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

PR Review: https://git.openjdk.org/jdk/pull/23981#pullrequestreview-2674348756
PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989189319

From zgu at openjdk.org  Tue Mar 11 12:56:56 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 11 Mar 2025 12:56:56 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread
In-Reply-To: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
Message-ID: <8jisr7VyO6wLNY0rmPPDfObP8c0UzrQlT0S3e_MyL50=.369dde48-904b-48c8-91e4-0dbf053129dc@github.com>

On Tue, 11 Mar 2025 12:15:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a minor mostly trivial change I found while reading through code looking for something else.
> Tested with tier1-4.

src/hotspot/share/runtime/lockStack.cpp line 80:

> 78: #ifndef PRODUCT
> 79: bool LockStack::is_owning_thread(JavaThread* current) const {
> 80:  JavaThread* thread = JavaThread::cast(current);

Superfluous `cast`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989199639

From stefank at openjdk.org  Tue Mar 11 13:01:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Mar 2025 13:01:00 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread
In-Reply-To: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
Message-ID: <n0bZq5S6EM1eMO5kJ_ErGvbEl5bIDfgycYqpeDMV7Tc=.e3f69d20-e915-48ae-ad02-6666f222f59f@github.com>

On Tue, 11 Mar 2025 12:15:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a minor mostly trivial change I found while reading through code looking for something else.
> Tested with tier1-4.

src/hotspot/share/runtime/lockStack.hpp line 70:

> 68: 
> 69:   // Tests if the calling thread is the thread that owns this lock-stack.
> 70:   bool is_owning_thread(JavaThread* current) const PRODUCT_RETURN;

This will not work in product builds.

Even if this is fixed, I think it is somewhat dangerous to leave this function available in product builds if it gives the wrong answer.

I'm voting for keeping this in as a product function. Or, alternatively, compile out the entire declaration in product builds. Thought, I do prefer the former since there's no obvious (to me) need to compile this out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989211012

From coleenp at openjdk.org  Tue Mar 11 13:09:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 13:09:50 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v2]
In-Reply-To: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
Message-ID: <d-H9wYUmRAh5VF8612enwarNKlZYIG3M0k-BGvAXSrQ=.676e3ddd-0414-4620-aac6-139aadac651e@github.com>

> This is a minor mostly trivial change I found while reading through code looking for something else.
> Tested with tier1-4.

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

  Fix PRODUCT

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23981/files
  - new: https://git.openjdk.org/jdk/pull/23981/files/d68342d2..0c9d4768

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

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

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

From coleenp at openjdk.org  Tue Mar 11 13:09:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 13:09:52 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v2]
In-Reply-To: <n0bZq5S6EM1eMO5kJ_ErGvbEl5bIDfgycYqpeDMV7Tc=.e3f69d20-e915-48ae-ad02-6666f222f59f@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <n0bZq5S6EM1eMO5kJ_ErGvbEl5bIDfgycYqpeDMV7Tc=.e3f69d20-e915-48ae-ad02-6666f222f59f@github.com>
Message-ID: <MUiasALvJk2vzWGH55BNJcfRIOqkv3ssMYbHewE4oNU=.15515586-7fe5-4c63-894d-cd12035ec625@github.com>

On Tue, 11 Mar 2025 12:57:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix PRODUCT
>
> src/hotspot/share/runtime/lockStack.hpp line 70:
> 
>> 68: 
>> 69:   // Tests if the calling thread is the thread that owns this lock-stack.
>> 70:   bool is_owning_thread(JavaThread* current) const PRODUCT_RETURN;
> 
> This will not work in product builds.
> 
> Even if this is fixed, I think it is somewhat dangerous to leave this function available in product builds if it gives the wrong answer.
> 
> I'm voting for keeping this in as a product function. Or, alternatively, compile out the entire declaration in product builds. Thought, I do prefer the former since there's no obvious (to me) need to compile this out.

The reason I was here was that I was trying to find wasted code in product mode, then I realized it's not used anywhere in product mode.  So I'd rather it not exist in product mode.

> src/hotspot/share/runtime/synchronizer.cpp line 413:
> 
>> 411:     return LightweightSynchronizer::quick_enter(obj, lock, current);
>> 412:   }
>> 413: 
> 
> This looks unrelated.

It is unrelated, but I mentioned it in the bug report.  Feels like too useless to do on it's own.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989233462
PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989229593

From coleenp at openjdk.org  Tue Mar 11 13:14:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 13:14:20 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v3]
In-Reply-To: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
Message-ID: <HFx0PLGTUTEpRfshC0Ibd_jcHwlDJ2xVa0z3gh9WX5Y=.69592aa6-878c-4aa4-a18e-66a802649d29@github.com>

> This is a minor mostly trivial change I found while reading through code looking for something else.
> Tested with tier1-4.

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

  Fixed cast, compiled out is_owning_thread.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23981/files
  - new: https://git.openjdk.org/jdk/pull/23981/files/0c9d4768..18ddb3b1

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

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

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

From coleenp at openjdk.org  Tue Mar 11 13:14:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 13:14:20 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v3]
In-Reply-To: <8jisr7VyO6wLNY0rmPPDfObP8c0UzrQlT0S3e_MyL50=.369dde48-904b-48c8-91e4-0dbf053129dc@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <8jisr7VyO6wLNY0rmPPDfObP8c0UzrQlT0S3e_MyL50=.369dde48-904b-48c8-91e4-0dbf053129dc@github.com>
Message-ID: <Wvpl4pVe10K-gd7zNtE--NoPh6D2QNKSwgf2i9VEr1s=.8d3904d9-be7f-4426-b116-482796873b36@github.com>

On Tue, 11 Mar 2025 12:52:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed cast, compiled out is_owning_thread.
>
> src/hotspot/share/runtime/lockStack.cpp line 80:
> 
>> 78: #ifndef PRODUCT
>> 79: bool LockStack::is_owning_thread(JavaThread* current) const {
>> 80:  JavaThread* thread = JavaThread::cast(current);
> 
> Superfluous `cast`.

Thanks, I fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989241230

From stefank at openjdk.org  Tue Mar 11 13:26:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Mar 2025 13:26:03 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v3]
In-Reply-To: <MUiasALvJk2vzWGH55BNJcfRIOqkv3ssMYbHewE4oNU=.15515586-7fe5-4c63-894d-cd12035ec625@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <n0bZq5S6EM1eMO5kJ_ErGvbEl5bIDfgycYqpeDMV7Tc=.e3f69d20-e915-48ae-ad02-6666f222f59f@github.com>
 <MUiasALvJk2vzWGH55BNJcfRIOqkv3ssMYbHewE4oNU=.15515586-7fe5-4c63-894d-cd12035ec625@github.com>
Message-ID: <ZrXO-UEnwdOIANDmWmdcwGNS5OgBr05l4iaFmwyNqiI=.969bb8a1-2275-474d-8eee-30d8bf79a6bb@github.com>

On Tue, 11 Mar 2025 13:05:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 413:
>> 
>>> 411:     return LightweightSynchronizer::quick_enter(obj, lock, current);
>>> 412:   }
>>> 413: 
>> 
>> This looks unrelated.
>
> It is unrelated, but I mentioned it in the bug report.  Feels like too useless to do on it's own.

I didn't read the bug report with the anticipation that the PR description had all the necessary information.

I was surprised by this change in a bug named "Cleanup LockStack::is_owning_thread" and I think that future readers might be as well. So, I prefer if you split this into a separate PR. PRs are fast to create nowadays. If you don't want to do that, then at least update the name of the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989267935

From stefank at openjdk.org  Tue Mar 11 13:34:11 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Mar 2025 13:34:11 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v3]
In-Reply-To: <MUiasALvJk2vzWGH55BNJcfRIOqkv3ssMYbHewE4oNU=.15515586-7fe5-4c63-894d-cd12035ec625@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <n0bZq5S6EM1eMO5kJ_ErGvbEl5bIDfgycYqpeDMV7Tc=.e3f69d20-e915-48ae-ad02-6666f222f59f@github.com>
 <MUiasALvJk2vzWGH55BNJcfRIOqkv3ssMYbHewE4oNU=.15515586-7fe5-4c63-894d-cd12035ec625@github.com>
Message-ID: <BEd7LdEjYmhEWK4trd6KVXihVpD0CNSmZ_Wfj2_eehk=.969d9d97-8598-42e3-9d45-072d0b7a8643@github.com>

On Tue, 11 Mar 2025 13:06:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/lockStack.hpp line 70:
>> 
>>> 68: 
>>> 69:   // Tests if the calling thread is the thread that owns this lock-stack.
>>> 70:   bool is_owning_thread(JavaThread* current) const PRODUCT_RETURN;
>> 
>> This will not work in product builds.
>> 
>> Even if this is fixed, I think it is somewhat dangerous to leave this function available in product builds if it gives the wrong answer.
>> 
>> I'm voting for keeping this in as a product function. Or, alternatively, compile out the entire declaration in product builds. Thought, I do prefer the former since there's no obvious (to me) need to compile this out.
>
> The reason I was here was that I was trying to find wasted code in product mode, then I realized it's not used anywhere in product mode.  So I'd rather it not exist in product mode.  I'll compile it out of PRODUCT, that's a better thing to do.

Won't the linker simply remove this? Keep it if you want, but to me these PRODUCT_ONLY / PRODUCT_RETURN / ASSERT just adds noise without giving us anything substantial.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989283783

From stefank at openjdk.org  Tue Mar 11 13:34:09 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Mar 2025 13:34:09 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v3]
In-Reply-To: <HFx0PLGTUTEpRfshC0Ibd_jcHwlDJ2xVa0z3gh9WX5Y=.69592aa6-878c-4aa4-a18e-66a802649d29@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <HFx0PLGTUTEpRfshC0Ibd_jcHwlDJ2xVa0z3gh9WX5Y=.69592aa6-878c-4aa4-a18e-66a802649d29@github.com>
Message-ID: <f9PDSTMkOzQZgfgetgCrR-OZkTJTR2_8mbTyseEelBA=.20a04441-2f6b-4a17-bcb6-07d78f883cf0@github.com>

On Tue, 11 Mar 2025 13:14:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a minor mostly trivial change I found while reading through code looking for something else.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed cast, compiled out is_owning_thread.

src/hotspot/share/runtime/lockStack.cpp line 82:

> 80:  bool is_owning = &current->lock_stack() == this;
> 81:  assert(is_owning == (get_thread() == current), "is_owning sanity");
> 82:  return is_owning;

Suggestion:

  bool is_owning = &current->lock_stack() == this;
  assert(is_owning == (get_thread() == current), "is_owning sanity");
  return is_owning;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989286749

From coleenp at openjdk.org  Tue Mar 11 14:04:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 14:04:38 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v4]
In-Reply-To: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
Message-ID: <zNE7isL7GhPmPG0fzEtBb7d34l5MoLMNRYSMdp1k9GQ=.e8d60829-49a2-4fff-bf7c-e65fc41dcd40@github.com>

> This is a minor mostly trivial change I found while reading through code looking for something else.
> Tested with tier1-4.

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

  Update src/hotspot/share/runtime/lockStack.cpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23981/files
  - new: https://git.openjdk.org/jdk/pull/23981/files/18ddb3b1..f52d1fbd

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

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

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

From jiangli at openjdk.org  Tue Mar 11 15:28:25 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Mar 2025 15:28:25 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <7YqG7ryKpJEk6hBnKnTj3Y_O2p_9x7XfT0M6jNw7nQg=.c5b75d99-9ce0-4898-a174-3646cfc4402a@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
 <7YqG7ryKpJEk6hBnKnTj3Y_O2p_9x7XfT0M6jNw7nQg=.c5b75d99-9ce0-4898-a174-3646cfc4402a@github.com>
Message-ID: <6XSLrtEyc3CqYlhvMUABGsDuIffNP029A7vovct2pD8=.8a4dc0c1-dea8-4da7-8722-149a1b8af3b0@github.com>

On Mon, 10 Mar 2025 19:54:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jiangli and I chatted about this today. We don't think there will be developers looking to specify -server or -client to a static image, instead this is more about the tests. So we think the best think is to look at the tests that still specify -server and see if it can be dropped. Some of the tests (say for C2) might be better off using `@requires vm.compiler2.enabled` or `@requires vm.flavor == "server"`.
>
>> @AlanBateman @dholmes-ora @iklam Do you have any other comments/questions about the change? @vnkozlov or others from compiler side, can you please take a look of the change as well? Thanks
> 
> I wasn't initially sure about XShareAuto.java but I see the exchange between you and Ioi so I think all good.

> > @AlanBateman @dholmes-ora @iklam Do you have any other comments/questions about the change? @vnkozlov or others from compiler side, can you please take a look of the change as well? Thanks
> 
> Please remove `* @bug 8005933` from XShareAuto.java as it no longer applies to that bug ID.

Done. Also updated @summary.

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2714753977

From jiangli at openjdk.org  Tue Mar 11 15:28:25 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Mar 2025 15:28:25 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v3]
In-Reply-To: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
Message-ID: <dILeW7xxhsZ3DKrSWmbS_lv_CaeNT-LizmtjRkv2iuI=.84fd4816-5930-44f1-9529-d2aaa551aff1@github.com>

> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
> 
> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
> 
> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Remove @bug and update @summary.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23881/files
  - new: https://git.openjdk.org/jdk/pull/23881/files/3189513d..3d7331f2

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

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

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

From rrich at openjdk.org  Tue Mar 11 15:58:05 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 11 Mar 2025 15:58:05 GMT
Subject: RFR: 8350106: [PPC] Avoid ticks_unknown_not_Java
 AsyncGetCallTrace() if JavaFrameAnchor::_last_Java_pc not set [v2]
In-Reply-To: <Wm1fuLYTcgBk8epsfua_re1Q9xUPh61queLKPeqebuM=.4cf97c8b-9026-49db-a325-bb2834d0794f@github.com>
References: <fG3cfS2iVP5NMb35AvZ0XJ76bDWckrZtDHB1FK7Ez98=.df7b5652-1b62-4201-8609-e2d03ba54f2e@github.com>
 <Wm1fuLYTcgBk8epsfua_re1Q9xUPh61queLKPeqebuM=.4cf97c8b-9026-49db-a325-bb2834d0794f@github.com>
Message-ID: <xSfhovVcdVQYXU0Fj8uvCm1xiS6M8IzkO_DWSXzurBo=.a9ff15f2-1c6f-43f2-983d-3224c3fcc540@github.com>

On Mon, 10 Mar 2025 15:19:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes `JavaThread::pd_get_top_frame_for_profiling` to better address situations where
>> 
>> 1. `JavaThread::last_Java_sp()` returns != null
>> 2. `JavaThread::last_Java_pc()` returns null
>> 
>> If the runtime needs to walk the stack of a java thread in that state, e.g. for gc purposes, it finds the last java pc relative to the last java sp (see [frame::setup()](https://github.com/openjdk/jdk/blob/3f0c1370269db978072814c2170fc3987efade85/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L40)).
>> 
>> This relies on the runtime method being called to store the return pc to its caller's abi which it will do when pushing a new frame for calling another method.
>> 
>> For an asynchronous interrupt to sample the stack this means: if there isn't at least one frame between the last java frame and the frame where the interrupt occurred then we can't be sure that the return pc was already saved and `pd_get_top_frame_for_profiling()` needs to return false indicating failure.
>> 
>> Otherwise we can and should proceed constructing a frame even though `JavaThread::last_Java_pc()` returned null.
>> 
>> Testing:
>> 
>> * DaCapo Tomcat with async-profiler on a fastdebug build.
>> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master'
>  - Better handle _last_Java_pc == null

Test failure on aarch64 is unrelated.
Thanks for the review Martin.

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

PR Comment: https://git.openjdk.org/jdk/pull/23640#issuecomment-2714862546

From rrich at openjdk.org  Tue Mar 11 15:58:06 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 11 Mar 2025 15:58:06 GMT
Subject: Integrated: 8350106: [PPC] Avoid ticks_unknown_not_Java
 AsyncGetCallTrace() if JavaFrameAnchor::_last_Java_pc not set
In-Reply-To: <fG3cfS2iVP5NMb35AvZ0XJ76bDWckrZtDHB1FK7Ez98=.df7b5652-1b62-4201-8609-e2d03ba54f2e@github.com>
References: <fG3cfS2iVP5NMb35AvZ0XJ76bDWckrZtDHB1FK7Ez98=.df7b5652-1b62-4201-8609-e2d03ba54f2e@github.com>
Message-ID: <T68C25GmLE_OoZeV6qxq4rQ4sgaMyWqtZTQVxSnChB0=.4a767617-8363-4997-a273-9f97c89f6881@github.com>

On Fri, 14 Feb 2025 16:11:05 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr changes `JavaThread::pd_get_top_frame_for_profiling` to better address situations where
> 
> 1. `JavaThread::last_Java_sp()` returns != null
> 2. `JavaThread::last_Java_pc()` returns null
> 
> If the runtime needs to walk the stack of a java thread in that state, e.g. for gc purposes, it finds the last java pc relative to the last java sp (see [frame::setup()](https://github.com/openjdk/jdk/blob/3f0c1370269db978072814c2170fc3987efade85/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L40)).
> 
> This relies on the runtime method being called to store the return pc to its caller's abi which it will do when pushing a new frame for calling another method.
> 
> For an asynchronous interrupt to sample the stack this means: if there isn't at least one frame between the last java frame and the frame where the interrupt occurred then we can't be sure that the return pc was already saved and `pd_get_top_frame_for_profiling()` needs to return false indicating failure.
> 
> Otherwise we can and should proceed constructing a frame even though `JavaThread::last_Java_pc()` returned null.
> 
> Testing:
> 
> * DaCapo Tomcat with async-profiler on a fastdebug build.
> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX.

This pull request has now been integrated.

Changeset: 030c85de
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/030c85de1376123615e804f98084cb3723205819
Stats:     25 lines in 2 files changed: 17 ins; 0 del; 8 mod

8350106: [PPC] Avoid ticks_unknown_not_Java AsyncGetCallTrace() if JavaFrameAnchor::_last_Java_pc not set

Reviewed-by: mdoerr

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

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

From coleenp at openjdk.org  Tue Mar 11 16:13:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 16:13:35 GMT
Subject: RFR: 8351673: Clean up a case of if (LockingMode == LM_LIGHTWEIGHT) in
 a legacy-only locking mode function
Message-ID: <nBqtu7EDYIM26QWHP2HtKZWWeG5X_M87FQjgf3URwWU=.fd730461-1acf-4692-b8a8-341c499bfc6e@github.com>

See title for description.
Tested with tier1-4 with PR https://github.com/openjdk/jdk/pull/23981

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

Commit messages:
 - 8351673: Clean up a case of if (LockingMode == LM_LIGHTWEIGHT) in a legacy-only locking mode function

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

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

From coleenp at openjdk.org  Tue Mar 11 16:17:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 16:17:43 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v5]
In-Reply-To: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
Message-ID: <LGHivo_eqr1IsN1Oqbb2sFqq5qu5WegnwfXNlIXOdBk=.d4ae5a58-94f2-4227-896e-b56a39210e19@github.com>

> This is a minor mostly trivial change I found while reading through code looking for something else.
> Tested with tier1-4.

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

  Restore lightweight case and removed NOT_PRODUCT.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23981/files
  - new: https://git.openjdk.org/jdk/pull/23981/files/f52d1fbd..e2d79f56

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

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

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

From coleenp at openjdk.org  Tue Mar 11 16:24:08 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 16:24:08 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v5]
In-Reply-To: <BEd7LdEjYmhEWK4trd6KVXihVpD0CNSmZ_Wfj2_eehk=.969d9d97-8598-42e3-9d45-072d0b7a8643@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <n0bZq5S6EM1eMO5kJ_ErGvbEl5bIDfgycYqpeDMV7Tc=.e3f69d20-e915-48ae-ad02-6666f222f59f@github.com>
 <MUiasALvJk2vzWGH55BNJcfRIOqkv3ssMYbHewE4oNU=.15515586-7fe5-4c63-894d-cd12035ec625@github.com>
 <BEd7LdEjYmhEWK4trd6KVXihVpD0CNSmZ_Wfj2_eehk=.969d9d97-8598-42e3-9d45-072d0b7a8643@github.com>
Message-ID: <a4nqBpcU8R2085sSVPCY3D4WIRhwLzRUq09FQSvt3eQ=.410094a5-98ba-4bef-ab6c-588b91d2eabc@github.com>

On Tue, 11 Mar 2025 13:30:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The reason I was here was that I was trying to find wasted code in product mode, then I realized it's not used anywhere in product mode.  So I'd rather it not exist in product mode.  I'll compile it out of PRODUCT, that's a better thing to do.
>
> Won't the linker simply remove this? Keep it if you want, but to me these PRODUCT_ONLY / PRODUCT_RETURN / ASSERT just adds noise without giving us anything substantial.

Fixed.

>> It is unrelated, but I mentioned it in the bug report.  Feels like too useless to do on it's own.
>
> I didn't read the bug report with the anticipation that the PR description had all the necessary information.
> 
> I was surprised by this change in a bug named "Cleanup LockStack::is_owning_thread" and I think that future readers might be as well. So, I prefer if you split this into a separate PR. PRs are fast to create nowadays. If you don't want to do that, then at least update the name of the PR.

okay I moved it to another trivial change.  The reason for this cleanup is that this code was in lockStack.inline.hpp indicating it's somewhat performance critical.  In trying to find a performance problem, I don't want to look at this function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989676913
PR Review Comment: https://git.openjdk.org/jdk/pull/23981#discussion_r1989679688

From mbaesken at openjdk.org  Tue Mar 11 16:47:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 16:47:29 GMT
Subject: RFR: 8351665: Remove unused UseNUMA in os_aix.cpp
Message-ID: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>

We have some UseNUMA related coding in os_aix.cpp that is not needed.
UseNUMA is set to false on AIX (with FLAG_SET_ERGO).

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

Commit messages:
 - JDK-8351665

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

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

From mdoerr at openjdk.org  Tue Mar 11 17:23:58 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 11 Mar 2025 17:23:58 GMT
Subject: RFR: 8351665: Remove unused UseNUMA in os_aix.cpp
In-Reply-To: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>
References: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>
Message-ID: <fOoY8r9bky1mBErLFprsQRNt4cHFP41V350r8IKBxpU=.5f4f97b8-03ae-4f0d-bf90-75197ebb58cf@github.com>

On Tue, 11 Mar 2025 16:42:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have some UseNUMA related coding in os_aix.cpp that is not needed.
> UseNUMA is set to false on AIX (with FLAG_SET_ERGO).

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23991#pullrequestreview-2675494236

From shade at openjdk.org  Tue Mar 11 18:42:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Mar 2025 18:42:52 GMT
Subject: RFR: 8351484: Race condition in max stats in MonitorList::add [v2]
In-Reply-To: <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
 <ShgU1py_2o-uYALcNmjBhjynw-qTQBmabA30yaUtuuo=.ab5d285b-cc86-4173-9a2b-caaf5d8c8ff6@github.com>
Message-ID: <hkqNEnIU4onAg0SkbuDXN2qBe5WpyP88evaBnMWm2LM=.5a0c566b-43ce-4f0d-aae6-9862d383494f@github.com>

On Mon, 10 Mar 2025 19:37:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for the description of the race. New gtest test case reliably catches fire on my 5950X desktop without this fix.
>> 
>> I needed to add the proper constructor for `MonitorList` to make it testable. In our regular code, it is statically allocated, so its fields are implicitly initialized.
>> 
>> I also made counter updates `_relaxed` for completeness.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, new test now passes
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Can check <=
>  - Object handle

Thanks! If there are no other comments, I'll integrate soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/23961#issuecomment-2715374750

From pchilanomate at openjdk.org  Tue Mar 11 20:28:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 11 Mar 2025 20:28:56 GMT
Subject: RFR: 8351673: Clean up a case of if (LockingMode ==
 LM_LIGHTWEIGHT) in a legacy-only locking mode function
In-Reply-To: <nBqtu7EDYIM26QWHP2HtKZWWeG5X_M87FQjgf3URwWU=.fd730461-1acf-4692-b8a8-341c499bfc6e@github.com>
References: <nBqtu7EDYIM26QWHP2HtKZWWeG5X_M87FQjgf3URwWU=.fd730461-1acf-4692-b8a8-341c499bfc6e@github.com>
Message-ID: <wPo0Yt_TOvbrzrxIAeOasBgKDF3PZsOW0gw5XV2Vk2g=.2355daa8-144e-4433-8bb2-2099aa410423@github.com>

On Tue, 11 Mar 2025 16:08:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> See title for description.
> Tested with tier1-4 with PR https://github.com/openjdk/jdk/pull/23981

LGTM.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23990#pullrequestreview-2676043586

From coleenp at openjdk.org  Tue Mar 11 20:35:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 20:35:03 GMT
Subject: RFR: 8351673: Clean up a case of if (LockingMode ==
 LM_LIGHTWEIGHT) in a legacy-only locking mode function
In-Reply-To: <nBqtu7EDYIM26QWHP2HtKZWWeG5X_M87FQjgf3URwWU=.fd730461-1acf-4692-b8a8-341c499bfc6e@github.com>
References: <nBqtu7EDYIM26QWHP2HtKZWWeG5X_M87FQjgf3URwWU=.fd730461-1acf-4692-b8a8-341c499bfc6e@github.com>
Message-ID: <eLMJRdgt2CK_eYfIcQe0lAiMRNkeIAsBQ9JaOpifEEo=.d4b67f53-d099-4390-a5e4-368e28428464@github.com>

On Tue, 11 Mar 2025 16:08:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> See title for description.
> Tested with tier1-4 with PR https://github.com/openjdk/jdk/pull/23981

I assume you agree that this is trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/23990#issuecomment-2715637822

From coleenp at openjdk.org  Tue Mar 11 20:35:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 11 Mar 2025 20:35:04 GMT
Subject: Integrated: 8351673: Clean up a case of if (LockingMode ==
 LM_LIGHTWEIGHT) in a legacy-only locking mode function
In-Reply-To: <nBqtu7EDYIM26QWHP2HtKZWWeG5X_M87FQjgf3URwWU=.fd730461-1acf-4692-b8a8-341c499bfc6e@github.com>
References: <nBqtu7EDYIM26QWHP2HtKZWWeG5X_M87FQjgf3URwWU=.fd730461-1acf-4692-b8a8-341c499bfc6e@github.com>
Message-ID: <QMojc6gtemY6eXQn73xk_P1XPA5xLcMwS_JeOWYKVFE=.fad3d9df-d05c-4338-8055-3598c06574a2@github.com>

On Tue, 11 Mar 2025 16:08:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> See title for description.
> Tested with tier1-4 with PR https://github.com/openjdk/jdk/pull/23981

This pull request has now been integrated.

Changeset: 64464eab
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64464eab6291ee498fe677e90bcb8980fe8a9a3c
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8351673: Clean up a case of if (LockingMode == LM_LIGHTWEIGHT) in a legacy-only locking mode function

Reviewed-by: pchilanomate

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

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

From stefank at openjdk.org  Tue Mar 11 21:22:06 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Mar 2025 21:22:06 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v5]
In-Reply-To: <LGHivo_eqr1IsN1Oqbb2sFqq5qu5WegnwfXNlIXOdBk=.d4ae5a58-94f2-4227-896e-b56a39210e19@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <LGHivo_eqr1IsN1Oqbb2sFqq5qu5WegnwfXNlIXOdBk=.d4ae5a58-94f2-4227-896e-b56a39210e19@github.com>
Message-ID: <7pOVC2Oh2DZ7IZ5vR14tFW-gkUlsmN2LPDKFTLKV_eQ=.447345ec-2a89-4b0a-b53d-70623dce9d0c@github.com>

On Tue, 11 Mar 2025 16:17:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a minor mostly trivial change I found while reading through code looking for something else.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore lightweight case and removed NOT_PRODUCT.

So, now you have declared but not defined this function in product builds, which means that the next person that will try to use the function in a product context will hit a linker error. That's not really what I proposed.

I think you need to choose if you want to go with my preferred solution and make this a fully declared and defined product function, or revert back to completely compiling out the function as you did in an earlier version. I prefer the former, the latter is OK, but the current version is confusing.

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

PR Review: https://git.openjdk.org/jdk/pull/23981#pullrequestreview-2676143912

From jiangli at openjdk.org  Tue Mar 11 21:22:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 11 Mar 2025 21:22:15 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static JDK
Message-ID: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>

Please review the change to use `Arguments::get_java_home` to resolve the default classlist path. This avoids the complication of walking up the directory from libjvm and the subtle handling for '/lib' dir, which is what `MetaspaceShared::get_default_classlist` needs to do. This fixes the failure on static JDK for running `-Xshare:dump` with the default classlist. Please see more details in https://bugs.openjdk.org/browse/JDK-8351689.

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

Commit messages:
 - Resolve Whitespace error.
 - Simplify get default classlist.

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

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

From iklam at openjdk.org  Wed Mar 12 02:36:24 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Mar 2025 02:36:24 GMT
Subject: RFR: 8351327: -XX:AOTMode=record interferes with application execution
Message-ID: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>

Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), If `-XX:AOTMode=record` is specified in the command-line, the application's behavior is affected in the following 2 ways:

1. The application is not able to launch new Threads.
2. The exit code is ignored and becomes zero.

The fixes are simple and I also added a test case.

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

Commit messages:
 - 8351327: -XX:AOTMode=record interferes with application execution

Changes: https://git.openjdk.org/jdk/pull/24003/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24003&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351327
  Stats: 126 lines in 4 files changed: 121 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24003/head:pull/24003

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

From iklam at openjdk.org  Wed Mar 12 04:13:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Mar 2025 04:13:47 GMT
Subject: RFR: 8351748: Classes of method handles in AOT cache should be
 AOT-inited
Message-ID: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>

Whenever we store a MethodHandle in the AOT cache, we need to make sure that the class of this method is aot-initialized. Otherwise, the JVM might execute a BSM without first initializing the class of this BSM.

Please see the bug report for detail analysis.

I also fixed a problem in related logging code.

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

Commit messages:
 - 8351748: Classes of method handles in the AOT cache should be AOT-initialized

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

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

From liach at openjdk.org  Wed Mar 12 04:28:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Mar 2025 04:28:53 GMT
Subject: RFR: 8351748: Classes of method handles in AOT cache should be
 AOT-inited
In-Reply-To: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
Message-ID: <3mDMRPXMhLI9xISWzJFfhaD72uNCO49gkAMP1Lfx1AU=.718a7d15-8140-42e7-8ea6-813601be719f@github.com>

On Wed, 12 Mar 2025 04:09:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Whenever we store a MethodHandle in the AOT cache, we need to make sure that the class of this method is aot-initialized. Otherwise, the JVM might execute a BSM without first initializing the class of this BSM.
> 
> Please see the bug report for detail analysis.
> 
> I also fixed a problem in related logging code.

As I know VarHandle can link to implementation classes via VarForm. Unfortunately I don't know if the "class uninitialized" problem can happen on a cached VarHandle, might be worth to try out.

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

PR Comment: https://git.openjdk.org/jdk/pull/24004#issuecomment-2716409998

From shade at openjdk.org  Wed Mar 12 07:24:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Mar 2025 07:24:03 GMT
Subject: Integrated: 8351484: Race condition in max stats in MonitorList::add
In-Reply-To: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
References: <sDso4qSFLPNun6lh1XTKy8YtB3zNOCrDY-lh7VOQuqs=.2e6d4681-103f-4695-8bc4-4cb845fe6889@github.com>
Message-ID: <J42T14rmwd3IdgJ7k5w42rYy1TXvdHwZiyYbSh2giws=.fdc21533-e4df-4952-99ed-4b088aea165a@github.com>

On Mon, 10 Mar 2025 11:30:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for the description of the race. New gtest test case reliably catches fire on my 5950X desktop without this fix.
> 
> I needed to add the proper constructor for `MonitorList` to make it testable. In our regular code, it is statically allocated, so its fields are implicitly initialized.
> 
> I also made counter updates `_relaxed` for completeness.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, new test now passes
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] GHA

This pull request has now been integrated.

Changeset: 1d147ccb
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d147ccb4cfcb1da23664ac941e56ac542a7ac61
Stats:     48 lines in 3 files changed: 44 ins; 0 del; 4 mod

8351484: Race condition in max stats in MonitorList::add

Reviewed-by: pchilanomate, zgu

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

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

From jkern at openjdk.org  Wed Mar 12 11:18:59 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 12 Mar 2025 11:18:59 GMT
Subject: RFR: 8351665: Remove unused UseNUMA in os_aix.cpp
In-Reply-To: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>
References: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>
Message-ID: <1JRsX2f8jeXzxS5Jjh6CWbRj9c6roXCjvVwbd-ZTxeo=.fd7b7eaf-ad99-4550-90b6-c9f8748fcc4f@github.com>

On Tue, 11 Mar 2025 16:42:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have some UseNUMA related coding in os_aix.cpp that is not needed.
> UseNUMA is set to false on AIX (with FLAG_SET_ERGO).

If NUMA is maybe provided by AIX in the future we can easily add it again

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

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23991#pullrequestreview-2678028174

From coleenp at openjdk.org  Wed Mar 12 11:48:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 12 Mar 2025 11:48:59 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v5]
In-Reply-To: <LGHivo_eqr1IsN1Oqbb2sFqq5qu5WegnwfXNlIXOdBk=.d4ae5a58-94f2-4227-896e-b56a39210e19@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <LGHivo_eqr1IsN1Oqbb2sFqq5qu5WegnwfXNlIXOdBk=.d4ae5a58-94f2-4227-896e-b56a39210e19@github.com>
Message-ID: <WRg_gfZySrr2b1VRGpM7H-6HApDvAiLCORL-W52Yorg=.3cfb85df-b2ec-42cf-bebe-ad84c1ff3909@github.com>

On Tue, 11 Mar 2025 16:17:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a minor mostly trivial change I found while reading through code looking for something else.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore lightweight case and removed NOT_PRODUCT.

Okay I won't fix this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23981#issuecomment-2717602168

From coleenp at openjdk.org  Wed Mar 12 11:49:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 12 Mar 2025 11:49:00 GMT
Subject: Withdrawn: 8351651: Cleanup LockStack::is_owning_thread
In-Reply-To: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
Message-ID: <v9Krsay18KVca7FQmSf3TGPvBWw5yRB7DpXqu-VhT8w=.c00e39ac-bbc0-4e29-95e7-85e5ffdcda07@github.com>

On Tue, 11 Mar 2025 12:15:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a minor mostly trivial change I found while reading through code looking for something else.
> Tested with tier1-4.

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Wed Mar 12 12:23:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 12:23:55 GMT
Subject: RFR: 8351665: Remove unused UseNUMA in os_aix.cpp
In-Reply-To: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>
References: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>
Message-ID: <oFU5YDBXLStlitUoXm1RBDYvgOPb47VagZkmAz-Cn-Y=.55ddc3eb-ef87-4b0e-9f37-62be6a5f88b3@github.com>

On Tue, 11 Mar 2025 16:42:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have some UseNUMA related coding in os_aix.cpp that is not needed.
> UseNUMA is set to false on AIX (with FLAG_SET_ERGO).

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23991#issuecomment-2717703093

From mbaesken at openjdk.org  Wed Mar 12 12:23:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 12:23:56 GMT
Subject: Integrated: 8351665: Remove unused UseNUMA in os_aix.cpp
In-Reply-To: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>
References: <hnGcqSJaXtWq6BLkYrGoOYlaDmAxZ51EJjmZVES28X0=.955af796-bd6a-4269-80dc-3947877ea22d@github.com>
Message-ID: <hyrEqQut-mljYJZ89vR05loN5JmZw_FcLiDCBX8FiTY=.cf3ceeed-b405-46d9-a892-5fa62ca4ee2e@github.com>

On Tue, 11 Mar 2025 16:42:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have some UseNUMA related coding in os_aix.cpp that is not needed.
> UseNUMA is set to false on AIX (with FLAG_SET_ERGO).

This pull request has now been integrated.

Changeset: 84f87dd4
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84f87dd4e96bbea42b482a3a23383c8894a40868
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8351665: Remove unused UseNUMA in os_aix.cpp

Reviewed-by: mdoerr, jkern

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

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

From stefank at openjdk.org  Wed Mar 12 15:18:13 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 12 Mar 2025 15:18:13 GMT
Subject: RFR: 8351651: Cleanup LockStack::is_owning_thread [v5]
In-Reply-To: <LGHivo_eqr1IsN1Oqbb2sFqq5qu5WegnwfXNlIXOdBk=.d4ae5a58-94f2-4227-896e-b56a39210e19@github.com>
References: <2IGBOXvhTkaDAb1bxTQFWmPz0vBgVFsqxF6vhJZHPfM=.96cc3063-a507-4ffc-8ad0-63a206974d58@github.com>
 <LGHivo_eqr1IsN1Oqbb2sFqq5qu5WegnwfXNlIXOdBk=.d4ae5a58-94f2-4227-896e-b56a39210e19@github.com>
Message-ID: <i87FK0gTXaLbw_jCP95jZgrmH-DEu4KCY6PNzzxzeFw=.1f6d1065-b1e3-4e67-a689-e4eb5bffe859@github.com>

On Tue, 11 Mar 2025 16:17:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a minor mostly trivial change I found while reading through code looking for something else.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore lightweight case and removed NOT_PRODUCT.

OK, if that is what you want.

As I wrote, I've backed off on my earlier ask to keep the function a product function (including my request for reducing the line noise created by making this a debug-only function).

However, I still think it is important that we don't rush in code that is confusing and/or risks causing the next developer to be confused when the compiler/linker starts to complain. So, if that's a too large ask then I also think that it is good to close not make this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/23981#issuecomment-2718232015

From iklam at openjdk.org  Wed Mar 12 16:26:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Mar 2025 16:26:05 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
 [v3]
In-Reply-To: <dILeW7xxhsZ3DKrSWmbS_lv_CaeNT-LizmtjRkv2iuI=.84fd4816-5930-44f1-9529-d2aaa551aff1@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <dILeW7xxhsZ3DKrSWmbS_lv_CaeNT-LizmtjRkv2iuI=.84fd4816-5930-44f1-9529-d2aaa551aff1@github.com>
Message-ID: <i3exhdUilKjjiCDPzn-NNTmuta0cVWdIBYxA9JJQnMU=.fa7ef3bb-40ea-4568-8418-a2bd13fdddcf@github.com>

On Tue, 11 Mar 2025 15:28:25 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
>> 
>> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
>> 
>> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @bug and update @summary.

CDS test changes look good to me.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23881#pullrequestreview-2679130059

From vlivanov at openjdk.org  Wed Mar 12 17:19:12 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 12 Mar 2025 17:19:12 GMT
Subject: RFR: 8351748: Classes of method handles in AOT cache should be
 AOT-inited
In-Reply-To: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
Message-ID: <IuQn9Km8_bEH055NGnolctNyY1yPYrinqIaHj1PHW3k=.0e4a7c4e-7647-4e49-8c53-2c391143f6b6@github.com>

On Wed, 12 Mar 2025 04:09:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Whenever we store a MethodHandle in the AOT cache, we need to make sure that the class of this method is aot-initialized. Otherwise, the JVM might execute a BSM without first initializing the class of this BSM.
> 
> Please see the bug report for detail analysis.
> 
> I also fixed a problem in related logging code.

Proposed fix only covers Java methods. But there are Java field accessors which can be exposed either as MethodHandles or Varhandles.

src/hotspot/share/cds/heapShared.cpp line 342:

> 340:         Method* m = java_lang_invoke_ResolvedMethodName::vmtarget(obj);
> 341:         if (m != nullptr) {
> 342:           InstanceKlass* method_holder = m->method_holder();

Should you check first that the holder is already initialized before adding it to the list of AOT-inited classes?

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

PR Review: https://git.openjdk.org/jdk/pull/24004#pullrequestreview-2679279676
PR Review Comment: https://git.openjdk.org/jdk/pull/24004#discussion_r1991949260

From vlivanov at openjdk.org  Wed Mar 12 17:22:58 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 12 Mar 2025 17:22:58 GMT
Subject: RFR: 8351748: Classes of method handles in AOT cache should be
 AOT-inited
In-Reply-To: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
Message-ID: <FwKw8opuRkyezr91r0Js-alkd45s-agiHOjNep5s0yU=.c567796f-b4c7-4b65-940d-3b44b3a82c42@github.com>

On Wed, 12 Mar 2025 04:09:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Whenever we store a MethodHandle in the AOT cache, we need to make sure that the class of this method is aot-initialized. Otherwise, the JVM might execute a BSM without first initializing the class of this BSM.
> 
> Please see the bug report for detail analysis.
> 
> I also fixed a problem in related logging code.

IMO a safer alternative is to unconditionally keep all clinit barriers during assembly phase (irrespective of whether relevant class is initialized or not).

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

PR Comment: https://git.openjdk.org/jdk/pull/24004#issuecomment-2718592566

From jiangli at openjdk.org  Wed Mar 12 17:23:11 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Mar 2025 17:23:11 GMT
Subject: Integrated: 8350982: -server|-client causes fatal exception on static
 JDK
In-Reply-To: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
Message-ID: <bBxhx0_zctKzW8sWAT2P-brYlEtdpkGG5fnGE1weALw=.1a54a775-d52a-46e0-8111-c7654d5d60c5@github.com>

On Tue, 4 Mar 2025 01:43:29 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the `Arguments::parse_each_vm_init_arg` change to ignore`-server|-client` options, which avoids unrecognized option error on static JDK. 
> 
> On regular JDK, '-server|-client' options are processed/removed from command-line arguments by `CheckJvmType` during `CreateExecutionEnvironment`. That happens before `Arguments::parse_each_vm_init_arg` is called. With jvm.cfg setting, only server vm is known and client is ignored. So specifying '-server' and '-client' in command-line is really a no-op. 
> 
> On static JDK, the VM is statically linked with the launcher, and `CreateExecutionEnvironment` & `CheckJvmType` are not called. As the result, `Arguments::parse_each_vm_init_arg` could see `-server|-client` when running on static JDK, if the options are specified in the command line.

This pull request has now been integrated.

Changeset: 02c850fc
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02c850fca87372173eadba18dfa0231df33bebb0
Stats:     19 lines in 14 files changed: 2 ins; 5 del; 12 mod

8350982: -server|-client causes fatal exception on static JDK

Reviewed-by: iklam, alanb

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

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

From jiangli at openjdk.org  Wed Mar 12 17:23:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Mar 2025 17:23:10 GMT
Subject: RFR: 8350982: -server|-client causes fatal exception on static JDK
In-Reply-To: <7YqG7ryKpJEk6hBnKnTj3Y_O2p_9x7XfT0M6jNw7nQg=.c5b75d99-9ce0-4898-a174-3646cfc4402a@github.com>
References: <Rx0BWnlSUvlze1Q_7zAOTqJ7O5uWFSfZ19GPjFG3Wx4=.99ff9c89-b3eb-4172-8b05-9684255f3f78@github.com>
 <1UivDxf7iNhuhkTsh0S60VECAnkYkH4HQrYMmlCrZy0=.179c743b-4495-498c-b4ab-9fc0efce9467@github.com>
 <7YqG7ryKpJEk6hBnKnTj3Y_O2p_9x7XfT0M6jNw7nQg=.c5b75d99-9ce0-4898-a174-3646cfc4402a@github.com>
Message-ID: <uhCbtSPN2757efwRoXt4tEx9syn5oaKAZkfLIrQo9-A=.1c84adc0-f9c4-42c8-afd0-2e4e295ce25e@github.com>

On Mon, 10 Mar 2025 19:54:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jiangli and I chatted about this today. We don't think there will be developers looking to specify -server or -client to a static image, instead this is more about the tests. So we think the best think is to look at the tests that still specify -server and see if it can be dropped. Some of the tests (say for C2) might be better off using `@requires vm.compiler2.enabled` or `@requires vm.flavor == "server"`.
>
>> @AlanBateman @dholmes-ora @iklam Do you have any other comments/questions about the change? @vnkozlov or others from compiler side, can you please take a look of the change as well? Thanks
> 
> I wasn't initially sure about XShareAuto.java but I see the exchange between you and Ioi so I think all good.

@AlanBateman @iklam Thanks for the review! Moving forward on this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/23881#issuecomment-2718588289

From shade at openjdk.org  Wed Mar 12 17:52:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Mar 2025 17:52:57 GMT
Subject: RFR: 8351327: -XX:AOTMode=record interferes with application
 execution
In-Reply-To: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
References: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
Message-ID: <6MhKN58jbBlYZOGG4Zp_8v9NLoizKUCKX19EU4uJe94=.0f358f17-068f-4a2b-a4db-a4500d660eca@github.com>

On Wed, 12 Mar 2025 02:32:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), If `-XX:AOTMode=record` is specified in the command-line, the application's behavior is affected in the following 2 ways:
> 
> 1. The application is not able to launch new Threads.
> 2. The exit code is ignored and becomes zero.
> 
> The fixes are simple and I also added a test case.

Looks reasonable.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24003#pullrequestreview-2679386754

From kvn at openjdk.org  Wed Mar 12 18:08:57 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Mar 2025 18:08:57 GMT
Subject: RFR: 8351327: -XX:AOTMode=record interferes with application
 execution
In-Reply-To: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
References: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
Message-ID: <AMwj49Mcap6VSJO2s2GOGj6ljRhEVzV7wJwqzc1cyIk=.b4eadc7f-cf2a-4d1d-bf6d-a1e2be29772f@github.com>

On Wed, 12 Mar 2025 02:32:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), If `-XX:AOTMode=record` is specified in the command-line, the application's behavior is affected in the following 2 ways:
> 
> 1. The application is not able to launch new Threads.
> 2. The exit code is ignored and becomes zero.
> 
> The fixes are simple and I also added a test case.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24003#pullrequestreview-2679426737

From amenkov at openjdk.org  Wed Mar 12 19:32:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 12 Mar 2025 19:32:55 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <GJxbuwM9chjQeU-fbaVvx8iZMRzjm7mu1u9DzbL85-M=.d920d94b-c24d-4561-b758-b8c2bf37ee56@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>
 <GJxbuwM9chjQeU-fbaVvx8iZMRzjm7mu1u9DzbL85-M=.d920d94b-c24d-4561-b758-b8c2bf37ee56@github.com>
Message-ID: <ZcVsG1FAhaQv5WFdpFx9LqBl0srpJlMQ2Fs-KiJwQQ4=.17990e6d-8676-4308-8332-c8fb63594d31@github.com>

On Mon, 10 Feb 2025 18:25:58 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.
>
>> > 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.
> 
> Edit: I'll perform another review round soon!

@jdksjolen , @tstuefe  can you re-review with the last commit please

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

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

From matsaave at openjdk.org  Wed Mar 12 19:53:52 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 12 Mar 2025 19:53:52 GMT
Subject: RFR: 8351327: -XX:AOTMode=record interferes with application
 execution
In-Reply-To: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
References: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
Message-ID: <oLTCmWilaA9Xx6xLmIFjwp5H3_1ZBcTBnlxJwo6175U=.5fb8fc8d-1847-4ae1-85e3-8c42f263d516@github.com>

On Wed, 12 Mar 2025 02:32:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), If `-XX:AOTMode=record` is specified in the command-line, the application's behavior is affected in the following 2 ways:
> 
> 1. The application is not able to launch new Threads.
> 2. The exit code is ignored and becomes zero.
> 
> The fixes are simple and I also added a test case.

LGTM!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24003#pullrequestreview-2679707843

From iklam at openjdk.org  Wed Mar 12 20:11:25 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 12 Mar 2025 20:11:25 GMT
Subject: RFR: 8351871: Disable JIT compiler when dumping AOT cache with
 -XX:+AOTClassLinking
Message-ID: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>

Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), when creating the AOT cache with -XX:AOTMode=create, at the very end of normal Java execution, right before we enter the safepoint VM_PopulateDumpSharedSpace, we reset the states of a few Java objects.

Such reset operations can cause the JIT to observe inconsistent states.

While working on a proper fix, this PR is a work-around that disable the JIT during AOT cache creation.

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

Commit messages:
 - 8351871: Disable JIT compiler when dumping AOT cache with -XX:+AOTClassLinking

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

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

From kvn at openjdk.org  Wed Mar 12 20:34:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Mar 2025 20:34:52 GMT
Subject: RFR: 8351871: Disable JIT compiler when dumping AOT cache with
 -XX:+AOTClassLinking
In-Reply-To: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
References: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
Message-ID: <3EbriCiyedxGcj13RxK7iKJARyDntsOY4Mft17Zffkk=.8a0ad31b-fc95-48bf-8374-9e8b7135d3d9@github.com>

On Wed, 12 Mar 2025 20:06:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), when creating the AOT cache with -XX:AOTMode=create, at the very end of normal Java execution, right before we enter the safepoint VM_PopulateDumpSharedSpace, we reset the states of a few Java objects.
> 
> Such reset operations can cause the JIT to observe inconsistent states.
> 
> While working on a proper fix, this PR is a work-around that disable the JIT during AOT cache creation.

I am okay with this temporary fix.

We will need compiler in assembly phase to generate AOT code but we should not trigger normal JIT compilation and profiling.

This situation looks similar to what @shipilev did in leyden repo: https://github.com/openjdk/leyden/pull/44

Instead of checking `PreloadOnly` we can check AOTMode+AOTClassLinking state.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24019#pullrequestreview-2679794390

From jrose at openjdk.org  Wed Mar 12 20:58:53 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 12 Mar 2025 20:58:53 GMT
Subject: RFR: 8351871: Disable JIT compiler when dumping AOT cache with
 -XX:+AOTClassLinking
In-Reply-To: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
References: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
Message-ID: <gcHoLL6WScVugWgBWuFh4Lhque5-eFbSCEoAvwXgfok=.3e9cb9a1-5b37-40e3-bfcf-15f8dce90deb@github.com>

On Wed, 12 Mar 2025 20:06:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), when creating the AOT cache with -XX:AOTMode=create, at the very end of normal Java execution, right before we enter the safepoint VM_PopulateDumpSharedSpace, we reset the states of a few Java objects.
> 
> Such reset operations can cause the JIT to observe inconsistent states.
> 
> While working on a proper fix, this PR is a work-around that disable the JIT during AOT cache creation.

Is there a global flag we can check that says when object-editing has started?  It's at the very end of AOT assembly phase, so it should be false for some of the time, and later true.  Just as the JIT is locked out of the earliest boot-up phases of the VM, we should think about locking it out of the last shut-down phases, including the dump operation at the end of the AOT assembly phase.

We really need some cleanups and extensions in the java.lang.System boot-level logic.

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

PR Comment: https://git.openjdk.org/jdk/pull/24019#issuecomment-2719108707

From jrose at openjdk.org  Wed Mar 12 21:06:52 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 12 Mar 2025 21:06:52 GMT
Subject: RFR: 8351871: Disable JIT compiler when dumping AOT cache with
 -XX:+AOTClassLinking
In-Reply-To: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
References: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
Message-ID: <u96wa2zj8WxPqu9KFrL4TKRDxUrtZWFcmM-i5f1kQ0U=.ad214e79-bb9d-4900-b82b-2d6e09fdffbf@github.com>

On Wed, 12 Mar 2025 20:06:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), when creating the AOT cache with -XX:AOTMode=create, at the very end of normal Java execution, right before we enter the safepoint VM_PopulateDumpSharedSpace, we reset the states of a few Java objects.
> 
> Such reset operations can cause the JIT to observe inconsistent states.
> 
> While working on a proper fix, this PR is a work-around that disable the JIT during AOT cache creation.

And, uh, I might have dropped a ball there.  Here's a stalled paydown of some of that tech debt:

https://github.com/openjdk/jdk/pull/21514

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

PR Comment: https://git.openjdk.org/jdk/pull/24019#issuecomment-2719125944

From jiangli at openjdk.org  Wed Mar 12 23:52:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Mar 2025 23:52:02 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK
Message-ID: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>

Please review this change that disables TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK. Thanks

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

Commit messages:
 - Disable TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK.

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

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

From jrose at openjdk.org  Thu Mar 13 00:26:51 2025
From: jrose at openjdk.org (John R Rose)
Date: Thu, 13 Mar 2025 00:26:51 GMT
Subject: RFR: 8351327: -XX:AOTMode=record interferes with application
 execution
In-Reply-To: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
References: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
Message-ID: <0MTS8FXKln5qAXrj_tUq8aM7cGiJQ943cpIDE1BozVc=.88827ca2-31eb-45a7-afe8-f4f134cc3c71@github.com>

On Wed, 12 Mar 2025 02:32:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), If `-XX:AOTMode=record` is specified in the command-line, the application's behavior is affected in the following 2 ways:
> 
> 1. The application is not able to launch new Threads.
> 2. The exit code is ignored and becomes zero.
> 
> The fixes are simple and I also added a test case.

I filed JDK-8351894: [premain] more ways to trigger AOT dumps
My purpose is to expedite our creation of a mid-application End Training Run hook.
The sooner we create the hook the sooner we can shake out more bugs
like the one fixed here.
A very simple hook will do; I propose java.lang.System::endTrainingRun().

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

PR Comment: https://git.openjdk.org/jdk/pull/24003#issuecomment-2719430275

From iklam at openjdk.org  Thu Mar 13 05:00:03 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 05:00:03 GMT
Subject: RFR: 8351327: -XX:AOTMode=record interferes with application
 execution
In-Reply-To: <6MhKN58jbBlYZOGG4Zp_8v9NLoizKUCKX19EU4uJe94=.0f358f17-068f-4a2b-a4db-a4500d660eca@github.com>
References: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
 <6MhKN58jbBlYZOGG4Zp_8v9NLoizKUCKX19EU4uJe94=.0f358f17-068f-4a2b-a4db-a4500d660eca@github.com>
Message-ID: <1j6AZS_3y-6HoxS4Ul_cLdxFKw2fS6GFnC93LOizM9Q=.84b8048e-a48e-426b-92d1-bae5fe076a30@github.com>

On Wed, 12 Mar 2025 17:50:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), If `-XX:AOTMode=record` is specified in the command-line, the application's behavior is affected in the following 2 ways:
>> 
>> 1. The application is not able to launch new Threads.
>> 2. The exit code is ignored and becomes zero.
>> 
>> The fixes are simple and I also added a test case.
>
> Looks reasonable.

Thanks @shipilev @vnkozlov @matias9927 for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/24003#issuecomment-2719949366

From iklam at openjdk.org  Thu Mar 13 05:00:04 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 05:00:04 GMT
Subject: Integrated: 8351327: -XX:AOTMode=record interferes with application
 execution
In-Reply-To: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
References: <qU0FvHfcXm3fG8adMi6M9aLgtnctIF3JEroo78ykHcQ=.d1b84f1e-0080-4fe2-9ea6-3ef5c9c99bfa@github.com>
Message-ID: <igjqvJZrIAlDjTO3gFVe4jT4oEmaLqOdBOzyKNWoywQ=.da0450dd-5134-41e5-9aef-2a92179cf546@github.com>

On Wed, 12 Mar 2025 02:32:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), If `-XX:AOTMode=record` is specified in the command-line, the application's behavior is affected in the following 2 ways:
> 
> 1. The application is not able to launch new Threads.
> 2. The exit code is ignored and becomes zero.
> 
> The fixes are simple and I also added a test case.

This pull request has now been integrated.

Changeset: a7ad4144
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7ad4144c8663ed54b9b22cad5fc677273ae9e5c
Stats:     126 lines in 4 files changed: 121 ins; 2 del; 3 mod

8351327: -XX:AOTMode=record interferes with application execution

Reviewed-by: shade, kvn, matsaave

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

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

From iklam at openjdk.org  Thu Mar 13 05:09:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 05:09:57 GMT
Subject: RFR: 8351871: Disable JIT compiler when dumping AOT cache with
 -XX:+AOTClassLinking
In-Reply-To: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
References: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
Message-ID: <rPIv8kzyIwdug7Pk9fE-8r9B9YYCvRQn0AB0EDXGvqw=.7a279c31-9621-45b5-a4d2-33175713b9e8@github.com>

On Wed, 12 Mar 2025 20:06:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), when creating the AOT cache with -XX:AOTMode=create, at the very end of normal Java execution, right before we enter the safepoint VM_PopulateDumpSharedSpace, we reset the states of a few Java objects.
> 
> Such reset operations can cause the JIT to observe inconsistent states.
> 
> While working on a proper fix, this PR is a work-around that disable the JIT during AOT cache creation.

A better fix is https://github.com/openjdk/jdk/pull/24024 . Closing this one without integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/24019#issuecomment-2719961357

From iklam at openjdk.org  Thu Mar 13 05:09:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 05:09:57 GMT
Subject: Withdrawn: 8351871: Disable JIT compiler when dumping AOT cache with
 -XX:+AOTClassLinking
In-Reply-To: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
References: <WG7RIdF8HLQtOvNAoP9olGMUHkOz79Iy16lDpUJWAAs=.29a581de-7865-4a4b-861e-5c83e9c2d211@github.com>
Message-ID: <kdbDq2HMtD85fCxSJfF5ohyEP0jsFFbc9VSEORJ734M=.e987f58a-8d96-4751-8c16-3a77bbad0e8e@github.com>

On Wed, 12 Mar 2025 20:06:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), when creating the AOT cache with -XX:AOTMode=create, at the very end of normal Java execution, right before we enter the safepoint VM_PopulateDumpSharedSpace, we reset the states of a few Java objects.
> 
> Such reset operations can cause the JIT to observe inconsistent states.
> 
> While working on a proper fix, this PR is a work-around that disable the JIT during AOT cache creation.

This pull request has been closed without being integrated.

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

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

From iklam at openjdk.org  Thu Mar 13 05:10:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 05:10:16 GMT
Subject: RFR: 8351778: JIT compiler fails when running -XX:AOTMode=create
Message-ID: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>

Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), `SymbolTable::_shared_table` is corrupted inside the `VM_PopulateDumpSharedSpace` safepoint. Afterwards, the JIT will fail to look up classes/fields/etc, resulting in various mysterious crashes.

The fix is to use a separate table for dumping.

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

Commit messages:
 - 8351778: JIT compiler fails when running -XX:AOTMode=create

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

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

From iklam at openjdk.org  Thu Mar 13 05:10:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 05:10:16 GMT
Subject: RFR: 8351778: JIT compiler fails when running -XX:AOTMode=create
In-Reply-To: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
References: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
Message-ID: <nCCzlgQeFbRvH_1-Mt9rPdh2DAFsk1JmXPU3iTnASco=.67cd3c0c-f8f9-4b30-8f5a-7ce8f2089f04@github.com>

On Thu, 13 Mar 2025 05:04:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), `SymbolTable::_shared_table` is corrupted inside the `VM_PopulateDumpSharedSpace` safepoint. Afterwards, the JIT will fail to look up classes/fields/etc, resulting in various mysterious crashes.
> 
> The fix is to use a separate table for dumping.

This PR replaces https://github.com/openjdk/jdk/pull/24019 (closed without integrating)

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

PR Comment: https://git.openjdk.org/jdk/pull/24024#issuecomment-2719960743

From iklam at openjdk.org  Thu Mar 13 05:19:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 05:19:51 GMT
Subject: RFR: 8351748: Classes of method handles in AOT cache should be
 AOT-inited
In-Reply-To: <FwKw8opuRkyezr91r0Js-alkd45s-agiHOjNep5s0yU=.c567796f-b4c7-4b65-940d-3b44b3a82c42@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
 <FwKw8opuRkyezr91r0Js-alkd45s-agiHOjNep5s0yU=.c567796f-b4c7-4b65-940d-3b44b3a82c42@github.com>
Message-ID: <LXfsmbgnSaiP4-UMtsLhCyIWMgykL5Sq87PI641FEZ4=.1c610b7b-f2f8-4316-8c5f-97a20271663e@github.com>

On Wed, 12 Mar 2025 17:19:55 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> IMO a safer alternative is to unconditionally keep all clinit barriers during assembly phase (irrespective of whether relevant class is initialized or not).

Could you elaborate how this can be done?

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

PR Comment: https://git.openjdk.org/jdk/pull/24004#issuecomment-2719987264

From shade at openjdk.org  Thu Mar 13 08:42:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 13 Mar 2025 08:42:59 GMT
Subject: RFR: 8351778: JIT compiler fails when running -XX:AOTMode=create
In-Reply-To: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
References: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
Message-ID: <2Adm7kxLQWDiidu-60D35ZNOSXxKbtj9B9QSYr295ic=.bb755d12-5a04-4f08-8147-f57b829cdba0@github.com>

On Thu, 13 Mar 2025 05:04:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), `SymbolTable::_shared_table` is corrupted inside the `VM_PopulateDumpSharedSpace` safepoint. Afterwards, the JIT will fail to look up classes/fields/etc, resulting in various mysterious crashes.
> 
> The fix is to use a separate table for dumping.

This makes sense, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24024#pullrequestreview-2680982783

From azafari at openjdk.org  Thu Mar 13 10:26:11 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 13 Mar 2025 10:26:11 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations
Message-ID: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>

In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

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

Commit messages:
 - 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations

Changes: https://git.openjdk.org/jdk/pull/24028/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351661
  Stats: 81 lines in 4 files changed: 58 ins; 3 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028

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

From azafari at openjdk.org  Thu Mar 13 13:13:15 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 13 Mar 2025 13:13:15 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  fixed a bug.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24028/files
  - new: https://git.openjdk.org/jdk/pull/24028/files/1e316e61..768ecd98

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

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

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

From cnorrbin at openjdk.org  Thu Mar 13 15:13:04 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 13 Mar 2025 15:13:04 GMT
Subject: RFR: 8347734: Turning off PerfData logging doesn't work
Message-ID: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>

Hi everyone,

When PerfData is disabled, the corresponding perfdata variables remain uninitialized. However, under certain conditions, logging may attempt to access these variables, leading to a crash. The existing code turns off the relevant tags using `LogConfiguration::configure_stdout`, but this doesn't modify other outputs. For example, the test `runtime/logging/RedefineClasses.java` crashes with `-XX:-UsePerfData` because it uses an output that isn't stdout.

To fix this, I've added a new method `LogConfiguration::disable_tags`. Unlike `configure_stdout`, this function iterates over all outputs and disables the specified tags on each. This way, we correctly disable tags across all outputs and longer try and access the uninitialized perfdata variables.

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

Commit messages:
 - disable_tags function and test

Changes: https://git.openjdk.org/jdk/pull/24036/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24036&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347734
  Stats: 64 lines in 4 files changed: 57 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24036.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24036/head:pull/24036

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

From kvn at openjdk.org  Thu Mar 13 15:51:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 13 Mar 2025 15:51:54 GMT
Subject: RFR: 8351778: JIT compiler fails when running -XX:AOTMode=create
In-Reply-To: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
References: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
Message-ID: <o-Fcwwr5YzHpZa0KgtlZLBzwP4r1I1bdIME7djwk-fg=.1dd34ebf-1257-402e-ae45-7aac13c659b4@github.com>

On Thu, 13 Mar 2025 05:04:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), `SymbolTable::_shared_table` is corrupted inside the `VM_PopulateDumpSharedSpace` safepoint. Afterwards, the JIT will fail to look up classes/fields/etc, resulting in various mysterious crashes.
> 
> The fix is to use a separate table for dumping.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24024#pullrequestreview-2682491172

From gziemski at openjdk.org  Thu Mar 13 16:22:58 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 13 Mar 2025 16:22:58 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
Message-ID: <AzRBV-UYuPidKx9MYLPxr8MRKIfzbXnpurly9rG3eWE=.8e2b6041-4758-4242-85eb-856321df49c1@github.com>

On Thu, 13 Mar 2025 13:13:15 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed a bug.

Changes requested by gziemski (Reviewer).

src/hotspot/share/nmt/vmatree.cpp line 100:

> 98:         stB.in.set_stack(leqA_n->val().out.stack());
> 99:         stA.out.set_second_stack(metadata.stack_idx);
> 100:         stB.in.set_second_stack(metadata.stack_idx);

Did we consider naming them differently?

One obvious choice would be ReserveStack and CommitStack?

Right now, we need to mentally map them one way, and I am afraid that we could possibly get it reversed at some other point in code...

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

PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2682612623
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r1993880091

From vlivanov at openjdk.org  Thu Mar 13 16:53:59 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 13 Mar 2025 16:53:59 GMT
Subject: RFR: 8351748: Classes of method handles in AOT cache should be
 AOT-inited
In-Reply-To: <LXfsmbgnSaiP4-UMtsLhCyIWMgykL5Sq87PI641FEZ4=.1c610b7b-f2f8-4316-8c5f-97a20271663e@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
 <FwKw8opuRkyezr91r0Js-alkd45s-agiHOjNep5s0yU=.c567796f-b4c7-4b65-940d-3b44b3a82c42@github.com>
 <LXfsmbgnSaiP4-UMtsLhCyIWMgykL5Sq87PI641FEZ4=.1c610b7b-f2f8-4316-8c5f-97a20271663e@github.com>
Message-ID: <uzl4WFzLCg7zeft4ReCaDo1t6bU6tltF_lAbZuNwKqc=.42c7bcb6-2b32-4987-a06e-959f871a0b5c@github.com>

On Thu, 13 Mar 2025 05:17:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Could you elaborate how this can be done?

For `MethodHandle`s `DirectMethodHandle.shouldBeInitialized(Class)` determines whether a barrier is needed or not. It can be tweaked to behave conservatively during assembly phase and report `true` irrespective of whether the target class is initialized or not. (And it can take AOT-inited classes into account as well.) 

(`VarHandle`s use `Unsafe.shouldBeInitialized(Class)` directly.)

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

PR Comment: https://git.openjdk.org/jdk/pull/24004#issuecomment-2721973659

From vlivanov at openjdk.org  Thu Mar 13 16:54:58 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 13 Mar 2025 16:54:58 GMT
Subject: RFR: 8351778: JIT compiler fails when running -XX:AOTMode=create
In-Reply-To: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
References: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
Message-ID: <UqF3CkY-jLzVR9cB0_ZNnmu0aqE1PHVbXydTveXWLK8=.b5da054e-68ef-4505-9929-f9a07bdbfbb4@github.com>

On Thu, 13 Mar 2025 05:04:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), `SymbolTable::_shared_table` is corrupted inside the `VM_PopulateDumpSharedSpace` safepoint. Afterwards, the JIT will fail to look up classes/fields/etc, resulting in various mysterious crashes.
> 
> The fix is to use a separate table for dumping.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24024#pullrequestreview-2682737087

From azafari at openjdk.org  Thu Mar 13 17:56:00 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 13 Mar 2025 17:56:00 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <AzRBV-UYuPidKx9MYLPxr8MRKIfzbXnpurly9rG3eWE=.8e2b6041-4758-4242-85eb-856321df49c1@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
 <AzRBV-UYuPidKx9MYLPxr8MRKIfzbXnpurly9rG3eWE=.8e2b6041-4758-4242-85eb-856321df49c1@github.com>
Message-ID: <W3gbNUENhNmioax7Pj5Py12maQKR1X0jBWc8kXbd8kE=.e6b28b0c-b9c3-4277-8455-1f66c32beda9@github.com>

On Thu, 13 Mar 2025 16:18:52 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug.
>
> src/hotspot/share/nmt/vmatree.cpp line 100:
> 
>> 98:         stB.in.set_stack(leqA_n->val().out.stack());
>> 99:         stA.out.set_second_stack(metadata.stack_idx);
>> 100:         stB.in.set_second_stack(metadata.stack_idx);
> 
> Did we consider naming them differently?
> 
> One obvious choice would be ReserveStack and CommitStack?
> 
> Right now, we need to mentally map them one way, and I am afraid that we could possibly get it reversed at some other point in code...

One StackIndex is used for all reserve/commit/uncommit/release operations.
We need another one just used for committing and uncommitting the start-node of the reserved region.
So names like ReserveXXX and CommitXXX would not fit. 
I do not insist on the chosen names and am open to proper alternatives.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r1994053947

From stuefe at openjdk.org  Thu Mar 13 19:32:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 13 Mar 2025 19:32:55 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
Message-ID: <VI4H23m7qkMfZF5cYzD-obuzzEdRftImZpnmceEzb5g=.18d21b4e-8557-40c1-9394-d05c4e0215d6@github.com>

On Tue, 11 Mar 2025 01:39:55 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:
> 
>   restore ThreadBlockInVM in complete

Looks still ok

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2683165827

From amenkov at openjdk.org  Thu Mar 13 20:08:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 13 Mar 2025 20:08:02 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
Message-ID: <eY2hfFxnQOEFfZQDFi6CWqwrEzFNcKvx94zCtY7c2AU=.baa8b750-ce9c-44d2-b8ee-14e8bf17b0a7@github.com>

On Tue, 11 Mar 2025 01:39:55 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:
> 
>   restore ThreadBlockInVM in complete

Thanks for the review

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

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

From amenkov at openjdk.org  Thu Mar 13 20:08:04 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 13 Mar 2025 20:08:04 GMT
Subject: Integrated: 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: <o5cYlJqEZ9hX-SlNDdOUon8XRdHiRvj_7BfxfWjz-K0=.73f9077e-beaa-469a-9cef-70932ec8115b@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

This pull request has now been integrated.

Changeset: cd1be917
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd1be9175714186b8881a4d08628fdfcc9382bbc
Stats:     603 lines in 12 files changed: 471 ins; 40 del; 92 mod

8319055: JCMD should not buffer the whole output of commands

Reviewed-by: stuefe, jsjolen

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

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

From iklam at openjdk.org  Thu Mar 13 21:08:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 21:08:58 GMT
Subject: Integrated: 8351778: JIT compiler fails when running
 -XX:AOTMode=create
In-Reply-To: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
References: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
Message-ID: <bL6nBSTDeCJ0kB6e5HdyhyfFW1ho66PNkEHMIx3HF2E=.0da331aa-0f00-4e65-938e-adf275405931@github.com>

On Thu, 13 Mar 2025 05:04:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), `SymbolTable::_shared_table` is corrupted inside the `VM_PopulateDumpSharedSpace` safepoint. Afterwards, the JIT will fail to look up classes/fields/etc, resulting in various mysterious crashes.
> 
> The fix is to use a separate table for dumping.

This pull request has now been integrated.

Changeset: be36b234
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be36b234319f1ed89ea4f4ee29471b01c1dc89f2
Stats:     26 lines in 1 file changed: 5 ins; 15 del; 6 mod

8351778: JIT compiler fails when running -XX:AOTMode=create

Reviewed-by: shade, kvn, vlivanov

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

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

From iklam at openjdk.org  Thu Mar 13 21:08:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 21:08:57 GMT
Subject: RFR: 8351778: JIT compiler fails when running -XX:AOTMode=create
In-Reply-To: <2Adm7kxLQWDiidu-60D35ZNOSXxKbtj9B9QSYr295ic=.bb755d12-5a04-4f08-8147-f57b829cdba0@github.com>
References: <9kmX7t6PCCQ78RymkJs5POoveMz1HgF8QmmkX7Q3PdY=.41bc46a6-e03d-40ca-8faf-8e12d3529975@github.com>
 <2Adm7kxLQWDiidu-60D35ZNOSXxKbtj9B9QSYr295ic=.bb755d12-5a04-4f08-8147-f57b829cdba0@github.com>
Message-ID: <vBvZ6tIg3jq7OQhIiotH9C2LPj0VAszIx-MCsomnd10=.b8c168fe-dded-41d7-aa09-348fea66aaa4@github.com>

On Thu, 13 Mar 2025 08:40:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), `SymbolTable::_shared_table` is corrupted inside the `VM_PopulateDumpSharedSpace` safepoint. Afterwards, the JIT will fail to look up classes/fields/etc, resulting in various mysterious crashes.
>> 
>> The fix is to use a separate table for dumping.
>
> This makes sense, thanks.

Thanks @shipilev @vnkozlov @iwanowww for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/24024#issuecomment-2722688922

From iklam at openjdk.org  Thu Mar 13 21:25:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 13 Mar 2025 21:25:52 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK
In-Reply-To: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
Message-ID: <BCy6T7iQAnNWuqLyOQ-6-VOIbyncXcho0onrgi4UM24=.b1e00105-fbad-4ba7-bbdd-d4c953937e85@github.com>

On Tue, 11 Mar 2025 20:52:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change to use `Arguments::get_java_home` to resolve the default classlist path. This avoids the complication of walking up the directory from libjvm and the subtle handling for '/lib' dir, which is what `MetaspaceShared::get_default_classlist` needs to do. This fixes the failure on static JDK for running `-Xshare:dump` with the default classlist. Please see more details in https://bugs.openjdk.org/browse/JDK-8351689.

Have you tested on different platforms, especially Windows? Some CDS tests that use `MetaspaceShared::get_default_classlist)` may not be tested in the GitHub actions.

src/hotspot/share/cds/metaspaceShared.cpp line 869:

> 867: 
> 868:   jio_snprintf(default_classlist, JVM_MAXPATHLEN, "%s%slib%sclasslist",
> 869:                Arguments::get_java_home(), filesep, filesep);

I think it's better to move this logic into `MetaspaceShared::get_default_classlist()` to avoid duplication.

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

PR Review: https://git.openjdk.org/jdk/pull/24000#pullrequestreview-2683388567
PR Review Comment: https://git.openjdk.org/jdk/pull/24000#discussion_r1994317680

From manc at openjdk.org  Thu Mar 13 22:05:52 2025
From: manc at openjdk.org (Man Cao)
Date: Thu, 13 Mar 2025 22:05:52 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK
In-Reply-To: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
Message-ID: <fc2C7Mj9NNcxI6xQC7RIHJGr1se9n3Jm1d_B-Nzp6os=.34fb6546-456d-4071-91ba-a9d967a1ce05@github.com>

On Wed, 12 Mar 2025 23:47:03 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that disables TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK. Thanks

Changes LGTM.

Optional suggestion is to add a TODO comment referencing https://bugs.openjdk.org/browse/JDK-8351367, to remind us enabling them when fixing JDK-8351367.

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

Marked as reviewed by manc (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24020#pullrequestreview-2683459146

From jiangli at openjdk.org  Thu Mar 13 23:36:40 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Mar 2025 23:36:40 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
Message-ID: <b73tvazlPA5Z9cE50uTEZRysfj94z1J3Nd3FxUClZvA=.0e0d5d89-1bec-47d7-97e8-e20e5a9698c0@github.com>

> Please review the change to use `Arguments::get_java_home` to resolve the default classlist path. This avoids the complication of walking up the directory from libjvm and the subtle handling for '/lib' dir, which is what `MetaspaceShared::get_default_classlist` needs to do. This fixes the failure on static JDK for running `-Xshare:dump` with the default classlist. Please see more details in https://bugs.openjdk.org/browse/JDK-8351689.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Address iklam's comment:
  - Use get_default_classlist helper function.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24000/files
  - new: https://git.openjdk.org/jdk/pull/24000/files/cdb6b68b..92d3a880

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

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

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

From jiangli at openjdk.org  Thu Mar 13 23:36:41 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Mar 2025 23:36:41 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <BCy6T7iQAnNWuqLyOQ-6-VOIbyncXcho0onrgi4UM24=.b1e00105-fbad-4ba7-bbdd-d4c953937e85@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
 <BCy6T7iQAnNWuqLyOQ-6-VOIbyncXcho0onrgi4UM24=.b1e00105-fbad-4ba7-bbdd-d4c953937e85@github.com>
Message-ID: <5wXx3t9vVK2ltgVwz2vT0QBVC-Rc3OSbKpPy6MFrIv4=.da78ab41-275d-4d71-bc57-a95eab2a348b@github.com>

On Thu, 13 Mar 2025 21:19:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address iklam's comment:
>>   - Use get_default_classlist helper function.
>
> src/hotspot/share/cds/metaspaceShared.cpp line 869:
> 
>> 867: 
>> 868:   jio_snprintf(default_classlist, JVM_MAXPATHLEN, "%s%slib%sclasslist",
>> 869:                Arguments::get_java_home(), filesep, filesep);
> 
> I think it's better to move this logic into `MetaspaceShared::get_default_classlist()` to avoid duplication.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24000#discussion_r1994430230

From jiangli at openjdk.org  Thu Mar 13 23:52:52 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Mar 2025 23:52:52 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <BCy6T7iQAnNWuqLyOQ-6-VOIbyncXcho0onrgi4UM24=.b1e00105-fbad-4ba7-bbdd-d4c953937e85@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
 <BCy6T7iQAnNWuqLyOQ-6-VOIbyncXcho0onrgi4UM24=.b1e00105-fbad-4ba7-bbdd-d4c953937e85@github.com>
Message-ID: <toz-48NknuKBdlzKCJfiIS_0KBbX8Fn9ynHSfl2AS3k=.6fc2fa51-6475-431f-8b33-77898f6a5b66@github.com>

On Thu, 13 Mar 2025 21:22:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Have you tested on different platforms, especially Windows? Some CDS tests that use `MetaspaceShared::get_default_classlist)` may not be tested in the GitHub actions.

@iklam I've mainly tested on Linux and used GHA for other platforms. Could you please run though your tests? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24000#issuecomment-2722946529

From jiangli at openjdk.org  Fri Mar 14 00:48:06 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 14 Mar 2025 00:48:06 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK [v2]
In-Reply-To: <fc2C7Mj9NNcxI6xQC7RIHJGr1se9n3Jm1d_B-Nzp6os=.34fb6546-456d-4071-91ba-a9d967a1ce05@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
 <fc2C7Mj9NNcxI6xQC7RIHJGr1se9n3Jm1d_B-Nzp6os=.34fb6546-456d-4071-91ba-a9d967a1ce05@github.com>
Message-ID: <lk0-g_1px7PYodmEtGFLSZeZFChdS0AJEU0rycewI-s=.e317cfb5-e9d5-4291-84f2-2d91d2aa38a0@github.com>

On Thu, 13 Mar 2025 22:03:43 GMT, Man Cao <manc at openjdk.org> wrote:

> Changes LGTM.

Thanks for the quick review!

> 
> Optional suggestion is to add a TODO comment referencing https://bugs.openjdk.org/browse/JDK-8351367, to remind us enabling them when fixing JDK-8351367.

Added TODO comment with @comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/24020#issuecomment-2723026799

From jiangli at openjdk.org  Fri Mar 14 00:48:06 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 14 Mar 2025 00:48:06 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK [v2]
In-Reply-To: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
Message-ID: <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>

> Please review this change that disables TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK. Thanks

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Address @manc's comment: added @comment for TODO.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24020/files
  - new: https://git.openjdk.org/jdk/pull/24020/files/7d2fb474..f38d8265

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

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

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

From manc at openjdk.org  Fri Mar 14 05:16:57 2025
From: manc at openjdk.org (Man Cao)
Date: Fri, 14 Mar 2025 05:16:57 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK [v2]
In-Reply-To: <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
 <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>
Message-ID: <64RlgON2kgfcHyqmZuP6PfVqryYjXw8nyEbTgD8rdNg=.86f78977-61ee-4a7a-9bf8-a54183115972@github.com>

On Fri, 14 Mar 2025 00:48:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that disables TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK. Thanks
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @manc's comment: added @comment for TODO.

Marked as reviewed by manc (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/24020#pullrequestreview-2684268138

From iklam at openjdk.org  Fri Mar 14 05:32:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Mar 2025 05:32:56 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <toz-48NknuKBdlzKCJfiIS_0KBbX8Fn9ynHSfl2AS3k=.6fc2fa51-6475-431f-8b33-77898f6a5b66@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
 <BCy6T7iQAnNWuqLyOQ-6-VOIbyncXcho0onrgi4UM24=.b1e00105-fbad-4ba7-bbdd-d4c953937e85@github.com>
 <toz-48NknuKBdlzKCJfiIS_0KBbX8Fn9ynHSfl2AS3k=.6fc2fa51-6475-431f-8b33-77898f6a5b66@github.com>
Message-ID: <RZ6wUaY--6yhLfyDozxFnTwGCBPUzo5tOA9CpRzvDPU=.0f98f5e6-0ce3-4239-bd61-85064b5b96ee@github.com>

On Thu, 13 Mar 2025 23:49:51 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > Have you tested on different platforms, especially Windows? Some CDS tests that use `MetaspaceShared::get_default_classlist)` may not be tested in the GitHub actions.
> 
> @iklam I've mainly tested on Linux and used GHA for other platforms. Could you please run though your tests? Thanks!

Hi Jiangli, I've run the patch in our CI through tiers 1 and 4, on all supported platforms, and found no regression.

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

PR Comment: https://git.openjdk.org/jdk/pull/24000#issuecomment-2723594144

From stuefe at openjdk.org  Fri Mar 14 05:46:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Mar 2025 05:46:02 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK [v2]
In-Reply-To: <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
 <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>
Message-ID: <5ry3Lx3LtSJDC0GBGtm7Mdcdz2hd7BWYhVc_WkZQgZY=.7e1bfc05-cf2e-46cc-ac26-fc060335bb56@github.com>

On Fri, 14 Mar 2025 00:48:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that disables TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK. Thanks
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @manc's comment: added @comment for TODO.

Is this a bug that is planned to be fixed? Why not add it to the ProblemList? That is the usual mechanism. We probably need a problemlist for static build anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/24020#issuecomment-2723645383

From jkern at openjdk.org  Fri Mar 14 11:52:40 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 14 Mar 2025 11:52:40 GMT
Subject: RFR: 8352046: AIX: Test testEcoFriendly() in
 /jdk/tools/launcher/ExecutionEnvironment.java makes no sense for aix and musl
Message-ID: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>

The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. So we skip this sub test for aix and musl.

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

Commit messages:
 - JDK-8352046

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

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

From jkern at openjdk.org  Fri Mar 14 15:47:25 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 14 Mar 2025 15:47:25 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
Message-ID: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>

After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.

Now with this change we can enable the statically linked launcher target again.
There are 3 things to do.
1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

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

Commit messages:
 - JDK-8352064

Changes: https://git.openjdk.org/jdk/pull/24062/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352064
  Stats: 66 lines in 5 files changed: 60 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24062/head:pull/24062

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

From gziemski at openjdk.org  Fri Mar 14 16:07:04 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 14 Mar 2025 16:07:04 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <W3gbNUENhNmioax7Pj5Py12maQKR1X0jBWc8kXbd8kE=.e6b28b0c-b9c3-4277-8455-1f66c32beda9@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
 <AzRBV-UYuPidKx9MYLPxr8MRKIfzbXnpurly9rG3eWE=.8e2b6041-4758-4242-85eb-856321df49c1@github.com>
 <W3gbNUENhNmioax7Pj5Py12maQKR1X0jBWc8kXbd8kE=.e6b28b0c-b9c3-4277-8455-1f66c32beda9@github.com>
Message-ID: <ztoIWMbWAtbwT_U1vlzX_phE5HK9oGo1QK8EflOFjjE=.350d0a25-0129-4760-9820-a6417a092b8b@github.com>

On Thu, 13 Mar 2025 17:53:22 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/vmatree.cpp line 100:
>> 
>>> 98:         stB.in.set_stack(leqA_n->val().out.stack());
>>> 99:         stA.out.set_second_stack(metadata.stack_idx);
>>> 100:         stB.in.set_second_stack(metadata.stack_idx);
>> 
>> Did we consider naming them differently?
>> 
>> One obvious choice would be ReserveStack and CommitStack?
>> 
>> Right now, we need to mentally map them one way, and I am afraid that we could possibly get it reversed at some other point in code...
>
> One StackIndex is used for all reserve/commit/uncommit/release operations.
> We need another one just used for committing and uncommitting the start-node of the reserved region.
> So names like ReserveXXX and CommitXXX would not fit. 
> I do not insist on the chosen names and am open to proper alternatives.

In your gtest you have a test called "SeparateStacksForCommitAndReserve", which seems to say to me, that commit and reserve would be good names?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r1995842310

From jiangli at openjdk.org  Fri Mar 14 16:32:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 14 Mar 2025 16:32:02 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <RZ6wUaY--6yhLfyDozxFnTwGCBPUzo5tOA9CpRzvDPU=.0f98f5e6-0ce3-4239-bd61-85064b5b96ee@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
 <BCy6T7iQAnNWuqLyOQ-6-VOIbyncXcho0onrgi4UM24=.b1e00105-fbad-4ba7-bbdd-d4c953937e85@github.com>
 <toz-48NknuKBdlzKCJfiIS_0KBbX8Fn9ynHSfl2AS3k=.6fc2fa51-6475-431f-8b33-77898f6a5b66@github.com>
 <RZ6wUaY--6yhLfyDozxFnTwGCBPUzo5tOA9CpRzvDPU=.0f98f5e6-0ce3-4239-bd61-85064b5b96ee@github.com>
Message-ID: <g0hYFeI_DAVLshe2ewNvlRevi2oeZ4ueuSAoCYAtnCg=.96b94cd0-68a5-4c64-b1bb-9a554b8fb75e@github.com>

On Fri, 14 Mar 2025 05:30:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > > Have you tested on different platforms, especially Windows? Some CDS tests that use `MetaspaceShared::get_default_classlist)` may not be tested in the GitHub actions.
> > 
> > 
> > @iklam I've mainly tested on Linux and used GHA for other platforms. Could you please run though your tests? Thanks!
> 
> Hi Jiangli, I've run the patch in our CI through tiers 1 and 4, on all supported platforms, and found no regression.

Thanks for running through your tests, @iklam!

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

PR Comment: https://git.openjdk.org/jdk/pull/24000#issuecomment-2725186209

From erikj at openjdk.org  Fri Mar 14 17:38:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 14 Mar 2025 17:38:58 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

make/StaticLibs.gmk line 116:

> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \

The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:

Suggestion:

#    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \


You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1996001131

From jiangli at openjdk.org  Fri Mar 14 18:35:01 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 14 Mar 2025 18:35:01 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK [v2]
In-Reply-To: <5ry3Lx3LtSJDC0GBGtm7Mdcdz2hd7BWYhVc_WkZQgZY=.7e1bfc05-cf2e-46cc-ac26-fc060335bb56@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
 <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>
 <5ry3Lx3LtSJDC0GBGtm7Mdcdz2hd7BWYhVc_WkZQgZY=.7e1bfc05-cf2e-46cc-ac26-fc060335bb56@github.com>
Message-ID: <CvHSn-qhYMsDficDb5I2CGLEl49VXP_9s6SBuQVDILQ=.f485def5-c3a7-4906-8785-f346663366f7@github.com>

On Fri, 14 Mar 2025 05:42:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Is this a bug that is planned to be fixed? Why not add it to the ProblemList? That is the usual mechanism. 

https://bugs.openjdk.org/browse/JDK-8351367 is used to collect feedback/input on if (and how) `libjsig` should be supported on static JDK. At this point, it's not fully decided if we want to support `libjsig` on static JDK. Based on that, it seems approbate to skip these tests without putting on ProblemList.

> We probably need a problemlist for static build anyway.

Indeed. For the short term I think we want put the jtreg tests using the `<jdk>/bin` tools (such as `jstat`, `jstack`, etc) on the ProblemList for static JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/24020#issuecomment-2725436573

From iklam at openjdk.org  Fri Mar 14 20:19:12 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Mar 2025 20:19:12 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java
Message-ID: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>

I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:


make test JTREG=AOT_JDK=true \
    TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java


Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies

I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`

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

Commit messages:
 - 8352084: Add more test code in TestSetupAOT.java

Changes: https://git.openjdk.org/jdk/pull/24067/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352084
  Stats: 172 lines in 5 files changed: 158 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24067/head:pull/24067

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

From iklam at openjdk.org  Fri Mar 14 22:07:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Mar 2025 22:07:53 GMT
Subject: RFR: 8351748: Classes of method handles in AOT cache should be
 AOT-inited
In-Reply-To: <uzl4WFzLCg7zeft4ReCaDo1t6bU6tltF_lAbZuNwKqc=.42c7bcb6-2b32-4987-a06e-959f871a0b5c@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
 <FwKw8opuRkyezr91r0Js-alkd45s-agiHOjNep5s0yU=.c567796f-b4c7-4b65-940d-3b44b3a82c42@github.com>
 <LXfsmbgnSaiP4-UMtsLhCyIWMgykL5Sq87PI641FEZ4=.1c610b7b-f2f8-4316-8c5f-97a20271663e@github.com>
 <uzl4WFzLCg7zeft4ReCaDo1t6bU6tltF_lAbZuNwKqc=.42c7bcb6-2b32-4987-a06e-959f871a0b5c@github.com>
Message-ID: <71VxGBiFGMH_Qw3oB1ygLEA57CEZrpHwDl6-NyuoBJs=.25c64e0b-8abe-49ac-8cda-7ca2554c38e2@github.com>

On Thu, 13 Mar 2025 16:51:36 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > Could you elaborate how this can be done?
> 
> For `MethodHandle`s `DirectMethodHandle.shouldBeInitialized(Class)` determines whether a barrier is needed or not. It can be tweaked to behave conservatively during assembly phase and report `true` irrespective of whether the target class is initialized or not. (And it can take AOT-inited classes into account as well.)
> 
> (`VarHandle`s use `Unsafe.shouldBeInitialized(Class)` directly.)

In offline discussion, we agreed that blindly initializing every class may cause undesirable side effects. 

One option is to hard code all the classes that will be used by cached method handles. I wrote a prototype to check it what classes need to explicitly initialized. It found the usual suspects (`LambdaMetafactory` and `StringConcatFactory`), but even for a very simple test case, it also found `java.lang.StringConcatHelper`, which is internally used by StringConcatFactory. So it would be difficult to maintain such an explicit list to match changes inside the JDK.

I tried another suggestion from @iwanowww -- always emit init barriers in the cached  Method/Var handles. This seems to work.

My rough prototype is here: https://github.com/openjdk/jdk/commit/1baaaac1501df7c52a7dd4ab0722849d70265d4d . I can improve it by filtering out the classes that we know are aot-initialized.

Bytecode traces shows the presence of the init barrier in the generated bytecodes, so `LambdaMetafactory.<clinit>` is now executed before the target method is entered.


[3757812] static jobject java.lang.invoke.LambdaForm$DMH/0x800000005.invokeStaticInit(jobject, jobject, jobject, jobject, jobject, jobject, jobject)
[3757812]   233022     0  nofast_aload_0
[3757812]   233023     1  invokestatic 17 <java/lang/invoke/DirectMethodHandle.internalMemberNameEnsureInit(Ljava/lang/Object;)Ljava/lang/Object;> 

[3757812] static jobject java.lang.invoke.DirectMethodHandle.internalMemberNameEnsureInit(jobject)
[3757812]   233024     0  nofast_aload_0
[3757812]   233025     1  checkcast 3 <java/lang/invoke/DirectMethodHandle>
[3757812]   233026     4  astore_1
[3757812]   233027     5  aload_1
[3757812]   233028     6  invokevirtual 427 <java/lang/invoke/DirectMethodHandle.ensureInitialized()V> 

[3757812] virtual void java.lang.invoke.DirectMethodHandle.ensureInitialized()
[3757812]   233029     0  nofast_aload_0
[3757812]   233030     1  nofast_getfield 80 <java/lang/invoke/DirectMethodHandle.member:Ljava/lang/invoke/MemberName;> 
[3757812]   233031     4  invokestatic 453 <java/lang/invoke/DirectMethodHandle.checkInitialized(Ljava/lang/invoke/MemberName;)Z> 

[3757812] static jboolean java.lang.invoke.DirectMethodHandle.checkInitialized(jobject)
[3757812]   233032     0  nofast_aload_0
[3757812]   233033     1  invokevirtual 28 <java/lang/invoke/MemberName.getDeclaringClass()Ljava/lang/Class;> 

[3757812] virtual jobject java.lang.invoke.MemberName.getDeclaringClass()
[3757812]   233034     0  nofast_aload_0
[3757812]   233035     1  nofast_getfield 7 <java/lang/invoke/MemberName.clazz:Ljava/lang/Class;> 
[3757812]   233036     4  areturn

[3757812] static jboolean java.lang.invoke.DirectMethodHandle.checkInitialized(jobject)
[3757812]   233037     4  astore_1
[3757812]   233038     5  getstatic 436 <java/lang/invoke/MethodHandleStatics.UNSAFE:Ljdk/internal/misc/Unsafe;> 
[3757812]   233039     8  aload_1
[3757812]   233040     9  invokevirtual 440 <jdk/internal/misc/Unsafe.ensureClassInitialized(Ljava/lang/Class;)V> 

[3757812] virtual void jdk.internal.misc.Unsafe.ensureClassInitialized(jobject)
[3757812]   233041     0  aload_1
[3757812]   233042     1  ifnonnull 12
[3757812]   233043    12  nofast_aload_0
[3757812]   233044    13  aload_1
[3757812]   233045    14  invokevirtual 273 <jdk/internal/misc/Unsafe.ensureClassInitialized0(Ljava/lang/Class;)V> 

[3757812] static void java.lang.invoke.LambdaMetafactory.<clinit>()
[3757812]   233046     0  iconst_0
[3757812]   233047     1  anewarray java/lang/Class

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

PR Comment: https://git.openjdk.org/jdk/pull/24004#issuecomment-2725861980

From kvn at openjdk.org  Fri Mar 14 23:30:51 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Mar 2025 23:30:51 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java
In-Reply-To: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
Message-ID: <suU2s9WGvO4ExSQSsz9SlyqijE4HtfUtsa8uHX2jvM0=.bc892317-c498-4b2d-805f-235d14bf3ebb@github.com>

On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
> 
> 
> make test JTREG=AOT_JDK=true \
>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
> 
> 
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
> 
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2687063032

From lmesnik at openjdk.org  Fri Mar 14 23:30:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 14 Mar 2025 23:30:52 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java
In-Reply-To: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
Message-ID: <AI71Z1yZUZ1UIGvxMOqPO2PLGbqa48RCVtNeuz4YHyM=.caedc3e0-e8ee-4167-9e85-188c8e337049@github.com>

On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
> 
> 
> make test JTREG=AOT_JDK=true \
>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
> 
> 
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
> 
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`

Changes requested by lmesnik (Reviewer).

make/RunTests.gmk line 738:

> 736:   $1_AOT_JDK_CACHE := $$($1_TEST_SUPPORT_DIR)/aot/jdk.aotcache
> 737:   $1_AOT_JDK_LOG := $$($1_TEST_SUPPORT_DIR)/aot/TestSetupAOT.log
> 738:   $1_AOT_JDK_OUTPUT_DIR := $$($1_TEST_SUPPORT_DIR)/aot

Better to move it before line 735, and reuse in other definitions instead of $$($1_TEST_SUPPORT_DIR)/aot

test/setup_aot/TestSetupAOT.java line 147:

> 145: 
> 146: 
> 147:     static void streamOps(String args[]) {

Can you please add a comment with explanation of purpose of 'streamOps' method.

test/setup_aot/TestSetupAOT.java line 201:

> 199:         String CSCC   = "string" + s + "string" + c;
> 200: 
> 201:         long l = System.currentTimeMillis();

the l should be logged and  allow to be defined using property.
So any testing could be repeated.
 long l =  Long.getLong("test.aot.seed", System.currentTimeMillis());

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

PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2687055469
PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996419066
PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996422306
PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996424173

From erikj at openjdk.org  Fri Mar 14 23:46:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 14 Mar 2025 23:46:52 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java
In-Reply-To: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
Message-ID: <rZz0XBMUzJ7zmpN6jQk3RL77tydtmSJJVWs-mSjLnaY=.7ae66043-c89c-4666-ad72-c981a9479260@github.com>

On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
> 
> 
> make test JTREG=AOT_JDK=true \
>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
> 
> 
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
> 
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`

make/test/BuildTestSetupAOT.gmk line 62:

> 60:              JavacBenchApp$$FileManager.class \
> 61:              JavacBenchApp$$SourceFile.class \
> 62:              TestSetupAOT.class, \

Listing all class files like this is cumbersome. Perhaps we should build this into a jar file instead now that there are more classes? It should be as easy as adding `JAR := <name of jar>` to the SetupJavaCompilation call above and then copy that file. Or would that interfere with the classpath requirements when using the tool?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996434862

From iklam at openjdk.org  Sat Mar 15 02:08:34 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 15 Mar 2025 02:08:34 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v2]
In-Reply-To: <AI71Z1yZUZ1UIGvxMOqPO2PLGbqa48RCVtNeuz4YHyM=.caedc3e0-e8ee-4167-9e85-188c8e337049@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
 <AI71Z1yZUZ1UIGvxMOqPO2PLGbqa48RCVtNeuz4YHyM=.caedc3e0-e8ee-4167-9e85-188c8e337049@github.com>
Message-ID: <lkWA_sPUQtJk4QanCRIZTR6EuT1dwADBU97g1bS9TrI=.be682a6d-25ac-466a-9cd1-461ead0f52b7@github.com>

On Fri, 14 Mar 2025 23:21:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from @erikj79 and @lmesnik
>
> make/RunTests.gmk line 738:
> 
>> 736:   $1_AOT_JDK_CACHE := $$($1_TEST_SUPPORT_DIR)/aot/jdk.aotcache
>> 737:   $1_AOT_JDK_LOG := $$($1_TEST_SUPPORT_DIR)/aot/TestSetupAOT.log
>> 738:   $1_AOT_JDK_OUTPUT_DIR := $$($1_TEST_SUPPORT_DIR)/aot
> 
> Better to move it before line 735, and reuse in other definitions instead of $$($1_TEST_SUPPORT_DIR)/aot

Fixed.

> test/setup_aot/TestSetupAOT.java line 147:
> 
>> 145: 
>> 146: 
>> 147:     static void streamOps(String args[]) {
> 
> Can you please add a comment with explanation of purpose of 'streamOps' method.

I renamed the method to `invokedynamicTests()` and added comments.

> test/setup_aot/TestSetupAOT.java line 201:
> 
>> 199:         String CSCC   = "string" + s + "string" + c;
>> 200: 
>> 201:         long l = System.currentTimeMillis();
> 
> the l should be logged and  allow to be defined using property.
> So any testing could be repeated.
>  long l =  Long.getLong("test.aot.seed", System.currentTimeMillis());

I changed it to not depend on system time. Now the program should be deterministic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996506289
PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996506299
PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996506308

From iklam at openjdk.org  Sat Mar 15 02:08:34 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 15 Mar 2025 02:08:34 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v2]
In-Reply-To: <rZz0XBMUzJ7zmpN6jQk3RL77tydtmSJJVWs-mSjLnaY=.7ae66043-c89c-4666-ad72-c981a9479260@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
 <rZz0XBMUzJ7zmpN6jQk3RL77tydtmSJJVWs-mSjLnaY=.7ae66043-c89c-4666-ad72-c981a9479260@github.com>
Message-ID: <cevw5GQjST-LH1WUG3lUEGBXLP_rWSoEH89IK6bAtfE=.95c8dff7-8645-4f43-a292-f14dd28ed99e@github.com>

On Fri, 14 Mar 2025 23:43:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from @erikj79 and @lmesnik
>
> make/test/BuildTestSetupAOT.gmk line 62:
> 
>> 60:              JavacBenchApp$$FileManager.class \
>> 61:              JavacBenchApp$$SourceFile.class \
>> 62:              TestSetupAOT.class, \
> 
> Listing all class files like this is cumbersome. Perhaps we should build this into a jar file instead now that there are more classes? It should be as easy as adding `JAR := <name of jar>` to the SetupJavaCompilation call above and then copy that file. Or would that interfere with the classpath requirements when using the tool?

I changed the output to a JAR file so there's no need to enumerate all classes. When running the tool, I need to extract the class files to `$$($1_AOT_JDK_OUTPUT_DIR)` due to the reasons described in RunTests.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1996506325

From iklam at openjdk.org  Sat Mar 15 02:08:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 15 Mar 2025 02:08:33 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v2]
In-Reply-To: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
Message-ID: <1qxCBc_BDj7Gj7dcYamPqTRzvrfJXyIgUwKmdjOGjZE=.906f78f4-4675-4b6e-8fad-b3c500072526@github.com>

> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
> 
> 
> make test JTREG=AOT_JDK=true \
>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
> 
> 
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
> 
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Review comments from @erikj79 and @lmesnik

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24067/files
  - new: https://git.openjdk.org/jdk/pull/24067/files/7c486a8b..82b2c11d

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

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

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

From lmesnik at openjdk.org  Sat Mar 15 03:19:58 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 15 Mar 2025 03:19:58 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v2]
In-Reply-To: <1qxCBc_BDj7Gj7dcYamPqTRzvrfJXyIgUwKmdjOGjZE=.906f78f4-4675-4b6e-8fad-b3c500072526@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
 <1qxCBc_BDj7Gj7dcYamPqTRzvrfJXyIgUwKmdjOGjZE=.906f78f4-4675-4b6e-8fad-b3c500072526@github.com>
Message-ID: <Hjo4-jfsUbzeusqW5qja9-aiRevrPb--F31u6EesXBU=.d8111c78-4300-452d-805d-2898228bf962@github.com>

On Sat, 15 Mar 2025 02:08:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
>> 
>> 
>> make test JTREG=AOT_JDK=true \
>>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
>> 
>> 
>> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
>> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
>> 
>> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from @erikj79 and @lmesnik

Thanks for fixing those things.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2687294741

From iklam at openjdk.org  Sat Mar 15 20:36:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 15 Mar 2025 20:36:09 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v3]
In-Reply-To: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
Message-ID: <RteUnEI6U8UZx20SaFJuiyCU1p0ehX1JOJtcm2GObHA=.65dcb686-5cf9-41b2-9bc0-7e03d01d99cb@github.com>

> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
> 
> 
> make test JTREG=AOT_JDK=true \
>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
> 
> 
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
> 
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed windows path problem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24067/files
  - new: https://git.openjdk.org/jdk/pull/24067/files/82b2c11d..70291772

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

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

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

From iklam at openjdk.org  Sun Mar 16 02:59:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 16 Mar 2025 02:59:32 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
Message-ID: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>

This PR tries to cut down the use of `WhiteBox` in the HotSpot test cases. It modifies `VMProps` to save the set of VM properties into a file called "vm.properties" under Jtreg's work directory. The new API `jdk.test.lib.VMPropsGetter` loads the properties from this file to pass onto individual test cases.

See `getJtregWorkDir()` for the code that figures out the work directory. It assumes that `VMProps` and all test cases are always executed under

- `workDir/scratch/` ; or
- `workDir/scratch/[0-9]+/` 

This is probably not the right thing to do. I would be better for Jtreg to pass the location of the work directory to the test cases, with a command-line options like `-Djtreg.work.dir=<dir>`.

To show the benefit of this PR, I modified a few test cases to remove their use of WhiteBox.

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

Commit messages:
 - 8352107: Allow jtreg test cases to query test VM properties

Changes: https://git.openjdk.org/jdk/pull/24071/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24071&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352107
  Stats: 202 lines in 7 files changed: 192 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24071.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24071/head:pull/24071

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

From dholmes at openjdk.org  Mon Mar 17 05:47:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 05:47:54 GMT
Subject: RFR: 8347734: Turning off PerfData logging doesn't work
In-Reply-To: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
References: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
Message-ID: <M-QPZLcwP-TflTS79Kfuhen4VZtUszWsDQ1kZqAwS1k=.9d1b2dac-a5b5-4429-8669-9d722c391a1e@github.com>

On Thu, 13 Mar 2025 15:07:07 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> When PerfData is disabled, the corresponding perfdata variables remain uninitialized. However, under certain conditions, logging may attempt to access these variables, leading to a crash. The existing code turns off the relevant tags using `LogConfiguration::configure_stdout`, but this doesn't modify other outputs. For example, the test `runtime/logging/RedefineClasses.java` crashes with `-XX:-UsePerfData` because it uses an output that isn't stdout.
> 
> To fix this, I've added a new method `LogConfiguration::disable_tags`. Unlike `configure_stdout`, this function iterates over all outputs and disables the specified tags on each. This way, we correctly disable tags across all outputs and longer try and access the uninitialized perfdata variables.

This looks good to me. Thanks for fixing it Casper!

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24036#pullrequestreview-2689171336

From dholmes at openjdk.org  Mon Mar 17 05:52:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 05:52:52 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v2]
In-Reply-To: <bXiWo1gfSuKU7FpQZyfIi9f4HHIoMvTdur3Lh3-mA7g=.3301a575-da75-448c-8b27-e938fcd37f4c@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <VY8wZOwMgOaNgfKYlYWeb9b2XupI_8oZ8_hmy4i2syY=.86058d22-2c1f-4758-94e3-0a8fb938ced9@github.com>
 <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com>
 <zRILbqqqfapzSSqehYXi0aByi7vKRgSmmdZna5jx7Vg=.0bf97ac0-1406-4379-afa8-03b22115fe20@github.com>
 <dQlSzANca3fgrran6u4v4NJL4wmUjzo7SppQLzDLFX4=.2b541d09-96e2-49eb-a97b-0f4b33752e46@github.com>
 <bXiWo1gfSuKU7FpQZyfIi9f4HHIoMvTdur3Lh3-mA7g=.3301a575-da75-448c-8b27-e938fcd37f4c@github.com>
Message-ID: <Em_-v3GPZk-3ydYC0ZaIj2jklgu0IgCcJ-cVaOBXGVE=.881af30f-47ff-407f-8a73-4356aca5e1a1@github.com>

On Thu, 6 Mar 2025 08:50:54 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> Sorry I'm not sure what you are asking.
>
> I think tools/jpackage/helpers/jdk/jpackage/test/Executor.java is not run in GHA.

Correct. That is a tier2 test and IIUC GHA only runs tier1.

But I'm not sure why you're asking. I was pointing out that the jpackage test uses chcp in a simpler way than you have used, so I was suggesting you simplify your code and see if it still works.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r1997972281

From dholmes at openjdk.org  Mon Mar 17 06:49:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 06:49:53 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <ouKed_QE8qwiZEQ4i5vG1Mkpq_xdQXr8pp8y631FfUk=.ce42f76f-96fe-46c6-b072-b1f2caed8e9e@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
 <IPAwPe65wneDge77lwbKCr4GgTPyonrsIPe6dkZfuWM=.58195098-d8bc-45c7-a160-ad0476ec929f@github.com>
 <ouKed_QE8qwiZEQ4i5vG1Mkpq_xdQXr8pp8y631FfUk=.ce42f76f-96fe-46c6-b072-b1f2caed8e9e@github.com>
Message-ID: <Sh2ZqZXm37vuY6gvHoauR-__jVaONvnR0SjgwHovWIo=.9f46791c-66c1-49e6-b10e-9a91524fa0ad@github.com>

On Tue, 11 Mar 2025 10:54:16 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Looks fine to me. I haven't tested the rootless docker setup, though. So perhaps this should go through Oracle's CI before integrating.
>
>> Looks fine to me. I haven't tested the rootless docker setup, though. So perhaps this should go through Oracle's CI before integrating.
> 
> @dholmes-ora Could you please have a look and re-run the tests?

@sercher apologies I have been away and still catching up. Will test this now ...

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2728370999

From dholmes at openjdk.org  Mon Mar 17 07:19:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 07:19:00 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <b73tvazlPA5Z9cE50uTEZRysfj94z1J3Nd3FxUClZvA=.0e0d5d89-1bec-47d7-97e8-e20e5a9698c0@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
 <b73tvazlPA5Z9cE50uTEZRysfj94z1J3Nd3FxUClZvA=.0e0d5d89-1bec-47d7-97e8-e20e5a9698c0@github.com>
Message-ID: <0DXUGGAW4jSFGprqAMu-hawFDXt77gKQmNpuG4vhPyI=.42a61744-f26f-4082-8863-251c95111eac@github.com>

On Thu, 13 Mar 2025 23:36:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the change to use `Arguments::get_java_home` to resolve the default classlist path. This avoids the complication of walking up the directory from libjvm and the subtle handling for '/lib' dir, which is what `MetaspaceShared::get_default_classlist` needs to do. This fixes the failure on static JDK for running `-Xshare:dump` with the default classlist. Please see more details in https://bugs.openjdk.org/browse/JDK-8351689.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address iklam's comment:
>   - Use get_default_classlist helper function.

This seems much simpler regardless of static: walk down from the top, rather up from the bottom.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24000#pullrequestreview-2689345101

From dholmes at openjdk.org  Mon Mar 17 07:28:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 07:28:57 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
Message-ID: <tH498H59PDiDzXIooSDlcubbAYwvK9BRT1pjb2M0Fzo=.7c1e4181-c55c-4470-abac-9fc83f6f3bde@github.com>

On Tue, 11 Mar 2025 00:53:34 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
>> 
>> containers/docker/TestMemoryWithSubgroups.java
>> 
>> [STDERR]
>> 
>> Resource limits are not supported and ignored on cgroups V1 rootless systems
>> 
>> [STDOUT]
>> 
>> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
>> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
>> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
>> 
>> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
>> 
>> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review comment

Test fails:

[STDERR]
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Error: template: info:1:2: executing "info" at <.SecurityOptions>: can't evaluate field SecurityOptions in type *define.Info

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2728436875

From dholmes at openjdk.org  Mon Mar 17 07:31:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 07:31:05 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK [v2]
In-Reply-To: <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
 <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>
Message-ID: <xcJzwAvSLQotSBI-svn3vb13JLJMhbYDcWP-EUoJTb8=.3a89620c-7711-48bb-958b-f1cbd5e3351a@github.com>

On Fri, 14 Mar 2025 00:48:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this change that disables TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK. Thanks
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @manc's comment: added @comment for TODO.

Ok.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24020#pullrequestreview-2689366355

From stefank at openjdk.org  Mon Mar 17 07:57:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 17 Mar 2025 07:57:55 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
Message-ID: <k5OEtMPDAD3uEQXBdHClJu4ZckUoNKLcwHljckuPD7o=.cbcb5fbc-9dfa-45f7-85ab-f83d59769182@github.com>

On Sun, 16 Mar 2025 02:54:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is probably not the right thing to do.

I agree that this doesn't sound like the right thing to do. This breaks the jtreg -othervm mode.

I use the -othervm mode whenever I want to run reproduce a failure in jtreg. In -othervm mode the pwd is the same as the final destination of the log files, hs_err files, jars, etc. So, when the logs says "hs_err files is written to xyz" it actually is left in that directory. In -agentvm mode the JVM says that the hs_err files is in scratch/<0>, but you won't find a hs_err file there, because jtreg moved it. Even more annoying is that in -agentvm mode it moves the whitebox.jar file, so the printed "rerun" line is not usable. If you run in -othervm mode you can copy and past the rerun line and it actually works, even when you are using the whitebox APIs.

Is there a way to get this patch to also work in -othervm mode?

When I run the test above with -othervm -retain -concurrency:1 I get the log files here:

jtreg_open_test_hotspot_jtreg_runtime_cds_appcds_aotClassLinking_BulkLoaderTest_java/runtime/cds/appcds/aotClassLinking/BulkLoaderTest_aot


but the vm.properties file is located here:

jtreg_open_test_hotspot_jtreg_runtime_cds_appcds_aotClassLinking_BulkLoaderTest_java/vm.properties


So, I'm not sure what's the easiest way to fix that. Maybe walk the chain of parent directories until you find the vm.properties file?

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2728492700

From iklam at openjdk.org  Mon Mar 17 08:48:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Mar 2025 08:48:56 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <k5OEtMPDAD3uEQXBdHClJu4ZckUoNKLcwHljckuPD7o=.cbcb5fbc-9dfa-45f7-85ab-f83d59769182@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
 <k5OEtMPDAD3uEQXBdHClJu4ZckUoNKLcwHljckuPD7o=.cbcb5fbc-9dfa-45f7-85ab-f83d59769182@github.com>
Message-ID: <dC9PPIjPJ26NGvrApdk3e2DF7nFJsHc7jS4yxCrotJQ=.3f29134d-e9d5-4c3f-939c-0e0839d2bca8@github.com>

On Mon, 17 Mar 2025 07:55:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > This is probably not the right thing to do.
> 
> I agree that this doesn't sound like the right thing to do. This breaks the jtreg -othervm mode.
> 
> I use the -othervm mode whenever I want to run reproduce a failure in jtreg. In -othervm mode the pwd is the same as the final destination of the log files, hs_err files, jars, etc. So, when the logs says "hs_err files is written to xyz" it actually is left in that directory. In -agentvm mode the JVM says that the hs_err files is in scratch/<0>, but you won't find a hs_err file there, because jtreg moved it. Even more annoying is that in -agentvm mode it moves the whitebox.jar file, so the printed "rerun" line is not usable. If you run in -othervm mode you can copy and past the rerun line and it actually works, even when you are using the whitebox APIs.
> 
> Is there a way to get this patch to also work in -othervm mode?
> 
> When I run the test above with -othervm -retain -concurrency:1 I get the log files here:
> 
> ```
> jtreg_open_test_hotspot_jtreg_runtime_cds_appcds_aotClassLinking_BulkLoaderTest_java/runtime/cds/appcds/aotClassLinking/BulkLoaderTest_aot
> ```
> 
> but the vm.properties file is located here:
> 
> ```
> jtreg_open_test_hotspot_jtreg_runtime_cds_appcds_aotClassLinking_BulkLoaderTest_java/vm.properties
> ```
> 
> So, I'm not sure what's the easiest way to fix that. Maybe walk the chain of parent directories until you find the vm.properties file?

Actually my PR may not cover all VM properties. VMProps is just for computing the "extra" properties:


requires.extraPropDefns = ../jtreg-ext/requires/VMProps.java


But jtreg also computes "built-in" properties like `jdk.version.major`, `os.simpleArch`, etc:

https://openjdk.org/jtreg/tag-spec.html#requires_names

So I think the best solution may be for jtreg to save the properties to a location of its choice, and pass this location to the test cases with a property like `test.vm.properties.file`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2728610838

From azafari at openjdk.org  Mon Mar 17 09:58:54 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 17 Mar 2025 09:58:54 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <ztoIWMbWAtbwT_U1vlzX_phE5HK9oGo1QK8EflOFjjE=.350d0a25-0129-4760-9820-a6417a092b8b@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
 <AzRBV-UYuPidKx9MYLPxr8MRKIfzbXnpurly9rG3eWE=.8e2b6041-4758-4242-85eb-856321df49c1@github.com>
 <W3gbNUENhNmioax7Pj5Py12maQKR1X0jBWc8kXbd8kE=.e6b28b0c-b9c3-4277-8455-1f66c32beda9@github.com>
 <ztoIWMbWAtbwT_U1vlzX_phE5HK9oGo1QK8EflOFjjE=.350d0a25-0129-4760-9820-a6417a092b8b@github.com>
Message-ID: <usQWyIH-N-YYXFrrZRpWQIXwBqM5-HL1CvVP1u2vjbI=.040b8617-5f27-4719-8d54-c08f01106d7b@github.com>

On Fri, 14 Mar 2025 16:04:04 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> One StackIndex is used for all reserve/commit/uncommit/release operations.
>> We need another one just used for committing and uncommitting the start-node of the reserved region.
>> So names like ReserveXXX and CommitXXX would not fit. 
>> I do not insist on the chosen names and am open to proper alternatives.
>
> In your gtest you have a test called "SeparateStacksForCommitAndReserve", which seems to say to me, that commit and reserve would be good names?

The full name should be something like:
commit_stack_at_start_of_region
or
stack_for_commit_at_region_base
Although it is also used for uncommit but we don't show uncommit stack traces in NMT report. 
What do you think? Any other better naming?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r1998362656

From jkern at openjdk.org  Mon Mar 17 10:04:56 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 10:04:56 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
Message-ID: <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>

On Fri, 14 Mar 2025 17:35:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> make/StaticLibs.gmk line 116:
> 
>> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
>> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
>> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \
> 
> The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:
> 
> Suggestion:
> 
> #    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \
> 
> 
> You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.

Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998375442

From schernyshev at openjdk.org  Mon Mar 17 10:21:05 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 17 Mar 2025 10:21:05 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <tH498H59PDiDzXIooSDlcubbAYwvK9BRT1pjb2M0Fzo=.7c1e4181-c55c-4470-abac-9fc83f6f3bde@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
 <tH498H59PDiDzXIooSDlcubbAYwvK9BRT1pjb2M0Fzo=.7c1e4181-c55c-4470-abac-9fc83f6f3bde@github.com>
Message-ID: <GJrWjwLR8XWGDT6wube0Ub3t_vYNOUyv3G69Ns0Lmo4=.d9219981-74ba-447c-8c65-1b3149b35e51@github.com>

On Mon, 17 Mar 2025 07:26:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Test fails:
> 
> ```
> [STDERR]
> Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
> Error: template: info:1:2: executing "info" at <.SecurityOptions>: can't evaluate field SecurityOptions in type *define.Info
> ```

Thanks @dholmes-ora for running the test! I understand the problem - the `info` format is from Podman while the command line is `docker`. I'll see what can be done.

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2728948007

From jsjolen at openjdk.org  Mon Mar 17 10:28:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 17 Mar 2025 10:28:07 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
Message-ID: <CnYLmMNbpQKmTPLOdQghXFhc_zdO4zrdagRG-rQ19ig=.393bb2b3-5533-45d0-a423-e3475534866d@github.com>

On Thu, 13 Mar 2025 13:13:15 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed a bug.

Hi,

I'd like to see this have clearer defined semantics written out into words in the PR description.

What are the expected semantics of this snippet in terms of the resulting nodes and their stacks?


// (address, size, callstack) arguments
# Case 1
tree.reserve(0, 100, s1);
tree.commit(25, 25, s2);
# Case 2
tree.reserve(0, 100, s1);
tree.reserve(10, 10, s2);
# Case 3
tree.commit(0, 100, s1);
# Case 4
tree.commit(0, 100, s1);
tree.reserve(0, 100, s2);


I'd expect them to be:


# Case 1
[] 0 R[s1] - [s1]R 25 RC[s1, s2] - [s1, s2]RC 50 - R[s1]  - [s1]R 100 []
# Case 2
[] 0 R[s2] - [s2]R 100 []
# Case 3
[] 0 RC[s1, s1] - [s1, s1]RC 100 []
# Case 4
[] 0 R[s2] - [s2]R 100 []


Is my intuition correct?

Thanks,
Johan

src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 53:

> 51: 
> 52:   static bool is_invalid(StackIndex a) {
> 53:     return a == invalid || a < 0;

If this change is necessary, then there's a bug in the code.

src/hotspot/share/nmt/vmatree.cpp line 96:

> 94:           && !(state == StateType::Reserved && !use_tag_inplace)            // we are not reserving a new region
> 95:           && !NativeCallStackStorage::is_invalid(leqA_n->val().out.stack()) // the primary stack is already filled
> 96:          ) {

These conditions can be refactored out and given useful names:

```c++
bool baz = ...;
bool foo = ...;
boo bar = ...;
if (baz || (foo && bar)) { /* ... */ }

src/hotspot/share/nmt/vmatree.hpp line 95:

> 93:     uint8_t type_tag[2];
> 94:     NativeCallStackStorage::StackIndex sidx;       // call-stack of all operations
> 95:     NativeCallStackStorage::StackIndex second_idx; // call-stack when committing/uncommitting the start-node of a reserved region

These can be called `primary_stack` and `secondary_stack`. Does an uncommitted region really have a stack?

src/hotspot/share/nmt/vmatree.hpp line 128:

> 126: 
> 127:     NativeCallStackStorage::StackIndex second_stack() const {
> 128:       return second_idx;

Rename accessors into `reserved_stack` and `committed_stack` and add `bool has_committed_stack()`?

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

PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2689829076
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r1998370903
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r1998386428
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r1998377261
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r1998379132

From sgehwolf at openjdk.org  Mon Mar 17 10:38:52 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 17 Mar 2025 10:38:52 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <GJrWjwLR8XWGDT6wube0Ub3t_vYNOUyv3G69Ns0Lmo4=.d9219981-74ba-447c-8c65-1b3149b35e51@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
 <tH498H59PDiDzXIooSDlcubbAYwvK9BRT1pjb2M0Fzo=.7c1e4181-c55c-4470-abac-9fc83f6f3bde@github.com>
 <GJrWjwLR8XWGDT6wube0Ub3t_vYNOUyv3G69Ns0Lmo4=.d9219981-74ba-447c-8c65-1b3149b35e51@github.com>
Message-ID: <81g7En-FY_tiH1FAGxUdtz_NNPDjFSo_iMZUV5ff7l4=.d14e4ab4-18ff-467c-a634-469a8381f064@github.com>

On Mon, 17 Mar 2025 10:18:16 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> > Test fails:
> > ```
> > [STDERR]
> > Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
> > Error: template: info:1:2: executing "info" at <.SecurityOptions>: can't evaluate field SecurityOptions in type *define.Info
> > ```
> 
> Thanks @dholmes-ora for running the test! I understand the problem - the `info` format is from Podman while the command line is `docker`. I'll see what can be done.

This looks to be a test-setup issue. If no `docker` is installed, but `podman-docker` which installs a docker shim for `podman`, then the tests should specify running with podman instead? The tests already support this by specifying `-Djdk.test.container.command=podman`. So supporting this in this particular test seems a work-around at best.

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2729012711

From jpai at openjdk.org  Mon Mar 17 10:58:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Mar 2025 10:58:02 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <dC9PPIjPJ26NGvrApdk3e2DF7nFJsHc7jS4yxCrotJQ=.3f29134d-e9d5-4c3f-939c-0e0839d2bca8@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
 <k5OEtMPDAD3uEQXBdHClJu4ZckUoNKLcwHljckuPD7o=.cbcb5fbc-9dfa-45f7-85ab-f83d59769182@github.com>
 <dC9PPIjPJ26NGvrApdk3e2DF7nFJsHc7jS4yxCrotJQ=.3f29134d-e9d5-4c3f-939c-0e0839d2bca8@github.com>
Message-ID: <AoEU6OcFkUhlXsWdWJHxGM6rfl8SMXXMC8_B7d4eAz4=.6cddc1dc-04ba-4765-a07f-820209365666@github.com>

On Mon, 17 Mar 2025 08:46:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> So I think the best solution may be for jtreg to save the properties to a location of its choice, and pass this location to the test cases with a property like test.vm.properties.file.

>From what I understand of the use case, certain parts of the test code would like to use key/value pairs whose keys are pre-defined in the JDK testsuite and values are computed by testsuite specific class, before jtreg launches the tests. These set of key/value pairs are currently used by jtreg in the evaluation of the `@requires` tag of the test definition. The proposal here is to make available that same key/value pairs to the test code itself (once the test is launched) so that they can do additional decisions based on those properties. 

If I understood that correctly then the proposal in jtreg would be to expose the https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/RegressionContext.java#L38. Since tests are not expected to rely on jtreg classes/types, the way to expose that detail would be by persisting the key/value pairs to a (properties) file whose path is then passed along to the test as a standard jtreg system property like the ones noted in https://openjdk.org/jtreg/tag-spec.html#testvars. I think that's doable. Could you file a request for this in the CODETOOLS project? I would need additional inputs from others in that project whether it's a good thing to expose this but based on my limited knowledge of that project, I think it's OK to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2729061175

From erikj at openjdk.org  Mon Mar 17 12:56:03 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Mar 2025 12:56:03 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v3]
In-Reply-To: <RteUnEI6U8UZx20SaFJuiyCU1p0ehX1JOJtcm2GObHA=.65dcb686-5cf9-41b2-9bc0-7e03d01d99cb@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
 <RteUnEI6U8UZx20SaFJuiyCU1p0ehX1JOJtcm2GObHA=.65dcb686-5cf9-41b2-9bc0-7e03d01d99cb@github.com>
Message-ID: <1DUpAZC6naigkZlpRx4410UdrSXnwei8Ypvc3FmaFKE=.fd7cab72-2602-4ea1-a530-3ec7a6aca15e@github.com>

On Sat, 15 Mar 2025 20:36:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
>> 
>> 
>> make test JTREG=AOT_JDK=true \
>>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
>> 
>> 
>> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
>> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
>> 
>> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed windows path problem

make/RunTests.gmk line 758:

> 756: 	$$(call ExecuteWithLog, $$($1_AOT_JDK_OUTPUT_DIR), ( \
> 757:             cd $$($1_AOT_JDK_OUTPUT_DIR); \
> 758: 	    $$(FIXPATH) $(JAR_CMD) --extract --file $(TEST_IMAGE_DIR)/setup_aot/TestSetupAOT.jar; \

The variable `JAR` already has fixpath prefixed when needed.
Suggestion:

	    $$(JAR) --extract --file $(TEST_IMAGE_DIR)/setup_aot/TestSetupAOT.jar; \

make/test/BuildTestSetupAOT.gmk line 57:

> 55: # Copy to hotspot jtreg test image
> 56: $(eval $(call SetupCopyFiles, COPY_SETUP_AOT, \
> 57:     SRC := $(SETUP_AOT_SUPPORT), \

With just one file being copied, the SRC argument can be omitted. It will default to the directory of the first file in FILES.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1998658649
PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r1998668399

From jkern at openjdk.org  Mon Mar 17 13:13:53 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 13:13:53 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
Message-ID: <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>

On Mon, 17 Mar 2025 10:02:12 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> make/StaticLibs.gmk line 116:
>> 
>>> 114: #    DEPS :=  $(STATIC_LIB_FILE), \
>>> 115: #    OUTPUT_FILE := $(STATIC_LIB_EXPORT_FILES), \
>>> 116: #    COMMAND := $(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@, \
>> 
>> The problem with using SetupExecute here is using `$@` variables in the command line. To get this to work you need to delay resolving such variables. It may work by adding an adequate number of extra `$`, but I'm not sure how many would be needed or if it would actually work. You could try this, but it's probably trickier to get right than just doubling:
>> 
>> Suggestion:
>> 
>> #    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | sort -u >$$@, \
>> 
>> 
>> You are probably better off using the explicit output file variable `$(STATIC_LIB_EXPORT_FILES)`.
>
> Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?

The problem seems to be that `$(generate_export_list)` is empty and I do not know why.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998701815

From erikj at openjdk.org  Mon Mar 17 13:16:52 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Mar 2025 13:16:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
 <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
Message-ID: <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>

On Mon, 17 Mar 2025 13:11:14 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Thanks Eric, this might help with the command, but my problem is the dependency. The rules to generate the export files is not called, because in the build output I cannot find any line 'Generating export list for static libs'. Can you help out here too?
>
> The problem seems to be that `$(generate_export_list)` is empty and I do not know why.

Looks like this variable is misspelled (missing "S").

DEPS := $(STATIC_LIB_FILE), \

Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998708773

From schernyshev at openjdk.org  Mon Mar 17 13:38:18 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 17 Mar 2025 13:38:18 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v3]
In-Reply-To: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
Message-ID: <wjoIIlCy7Iui9_brWndOvXKopeYGpfVgthpIe1y4hGo=.5a8f3f57-6eff-4a72-a063-60b5d8f4213e@github.com>

> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
> 
> containers/docker/TestMemoryWithSubgroups.java
> 
> [STDERR]
> 
> Resource limits are not supported and ignored on cgroups V1 rootless systems
> 
> [STDOUT]
> 
> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
> 
> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
> 
> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  fix Podman emulating Docker CLI.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23948/files
  - new: https://git.openjdk.org/jdk/pull/23948/files/eff5ac46..979fa75a

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

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

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

From schernyshev at openjdk.org  Mon Mar 17 13:38:19 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 17 Mar 2025 13:38:19 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v2]
In-Reply-To: <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <MjhU0_Mw4jRBYMhJq1UG8yWmCr_8vNcN2TfpEkFXYco=.597a3a39-1085-41a3-8290-bb4a38cca476@github.com>
Message-ID: <sMa4ovajS8jt-JfMhLZkiWXj6vPLf1js3GYoUBIrVDQ=.6ec30bba-6427-45c1-9077-8298a8c9be44@github.com>

On Tue, 11 Mar 2025 00:53:34 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
>> 
>> containers/docker/TestMemoryWithSubgroups.java
>> 
>> [STDERR]
>> 
>> Resource limits are not supported and ignored on cgroups V1 rootless systems
>> 
>> [STDOUT]
>> 
>> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
>> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
>> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
>> 
>> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
>> 
>> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review comment

One can ignore the error code of `docker info` and query for either `{{.Host.Security.Rootless}}` or `{{.SecurityOptions}}`. Please see the updated patch 979fa75a.

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2729535809

From sgehwolf at openjdk.org  Mon Mar 17 13:54:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 17 Mar 2025 13:54:55 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v3]
In-Reply-To: <wjoIIlCy7Iui9_brWndOvXKopeYGpfVgthpIe1y4hGo=.5a8f3f57-6eff-4a72-a063-60b5d8f4213e@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <wjoIIlCy7Iui9_brWndOvXKopeYGpfVgthpIe1y4hGo=.5a8f3f57-6eff-4a72-a063-60b5d8f4213e@github.com>
Message-ID: <tYTZqLoD60ptHZ1eI3l7dprrnOvFzjyqiBmXzbJ8_Kk=.6fb936af-6fe8-423f-9021-62fa7d31cdd3@github.com>

On Mon, 17 Mar 2025 13:38:18 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
>> 
>> containers/docker/TestMemoryWithSubgroups.java
>> 
>> [STDERR]
>> 
>> Resource limits are not supported and ignored on cgroups V1 rootless systems
>> 
>> [STDOUT]
>> 
>> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
>> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
>> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
>> 
>> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
>> 
>> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Podman emulating Docker CLI.

Seems a good solution. Please add a comment and this should be good to go if it now also passes Oracle CI. Thanks!

test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 58:

> 56:         return (getEngineInfo("{{.Host.Security.Rootless}}").contains("true") ||
> 57:                 getEngineInfo("{{.SecurityOptions}}").contains("name=rootless"));
> 58:     }

Please add a comment why need to check both (i.e. `docker => .SecurityOptions; podman => .Host.Security.Rootless`. Now it's no longer clear why we query two different values.

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

PR Review: https://git.openjdk.org/jdk/pull/23948#pullrequestreview-2690593281
PR Review Comment: https://git.openjdk.org/jdk/pull/23948#discussion_r1998777994

From jkern at openjdk.org  Mon Mar 17 15:03:52 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 17 Mar 2025 15:03:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
 <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
 <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>
Message-ID: <f_IVM6Xaku2Dd49hJBw6zcfjCuyAsJp_KKJIi6_wRqo=.9eb79ea1-09a0-4546-a3a3-066d6dd6c113@github.com>

On Mon, 17 Mar 2025 13:14:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The problem seems to be that `$(generate_export_list)` is empty and I do not know why.
>
> Looks like this variable is misspelled (missing "S").
> 
> DEPS := $(STATIC_LIB_FILE), \
> 
> Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.

Ups, thank you for giving me the 'S'. But nevertheless if I make with
`make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r1998959519

From schernyshev at openjdk.org  Mon Mar 17 16:00:47 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 17 Mar 2025 16:00:47 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v4]
In-Reply-To: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
Message-ID: <lsNqFBIw-Fy1BLpI5mi6qeEIPnVxjiduQY5vlf083xo=.8ad72fef-87db-421e-bf44-34224e3020a6@github.com>

> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
> 
> containers/docker/TestMemoryWithSubgroups.java
> 
> [STDERR]
> 
> Resource limits are not supported and ignored on cgroups V1 rootless systems
> 
> [STDOUT]
> 
> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
> 
> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
> 
> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  added a comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23948/files
  - new: https://git.openjdk.org/jdk/pull/23948/files/979fa75a..39657218

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

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

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

From schernyshev at openjdk.org  Mon Mar 17 16:00:49 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 17 Mar 2025 16:00:49 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v3]
In-Reply-To: <tYTZqLoD60ptHZ1eI3l7dprrnOvFzjyqiBmXzbJ8_Kk=.6fb936af-6fe8-423f-9021-62fa7d31cdd3@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <wjoIIlCy7Iui9_brWndOvXKopeYGpfVgthpIe1y4hGo=.5a8f3f57-6eff-4a72-a063-60b5d8f4213e@github.com>
 <tYTZqLoD60ptHZ1eI3l7dprrnOvFzjyqiBmXzbJ8_Kk=.6fb936af-6fe8-423f-9021-62fa7d31cdd3@github.com>
Message-ID: <0OEyWbXqXMPA8UC4Un2B2lm7dr8n4ARXMhDEJ2ERMgc=.b1b6e89b-48c1-43ef-8b1b-d8b018d00c89@github.com>

On Mon, 17 Mar 2025 13:51:29 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix Podman emulating Docker CLI.
>
> test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 58:
> 
>> 56:         return (getEngineInfo("{{.Host.Security.Rootless}}").contains("true") ||
>> 57:                 getEngineInfo("{{.SecurityOptions}}").contains("name=rootless"));
>> 58:     }
> 
> Please add a comment why need to check both (i.e. `docker => .SecurityOptions; podman => .Host.Security.Rootless`. Now it's no longer clear why we query two different values.

done, added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23948#discussion_r1999088053

From lmesnik at openjdk.org  Mon Mar 17 16:29:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 17 Mar 2025 16:29:39 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v3]
In-Reply-To: <RteUnEI6U8UZx20SaFJuiyCU1p0ehX1JOJtcm2GObHA=.65dcb686-5cf9-41b2-9bc0-7e03d01d99cb@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
 <RteUnEI6U8UZx20SaFJuiyCU1p0ehX1JOJtcm2GObHA=.65dcb686-5cf9-41b2-9bc0-7e03d01d99cb@github.com>
Message-ID: <W3QKe1sM2b0WNXRv6yB7SetsK9QBTAn6gb_HTcH-XMQ=.58ea7afb-6c39-4250-9ced-46b90a51caee@github.com>

On Sat, 15 Mar 2025 20:36:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
>> 
>> 
>> make test JTREG=AOT_JDK=true \
>>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
>> 
>> 
>> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
>> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
>> 
>> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed windows path problem

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2691173425

From sgehwolf at openjdk.org  Mon Mar 17 16:32:46 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 17 Mar 2025 16:32:46 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v4]
In-Reply-To: <lsNqFBIw-Fy1BLpI5mi6qeEIPnVxjiduQY5vlf083xo=.8ad72fef-87db-421e-bf44-34224e3020a6@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <lsNqFBIw-Fy1BLpI5mi6qeEIPnVxjiduQY5vlf083xo=.8ad72fef-87db-421e-bf44-34224e3020a6@github.com>
Message-ID: <1RU_hrN0xUNmDuJDuMmwm7owFlayX0h2EmxenGqx-3Q=.080a10af-9412-426e-9178-c729dd8bafa7@github.com>

On Mon, 17 Mar 2025 16:00:47 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
>> 
>> containers/docker/TestMemoryWithSubgroups.java
>> 
>> [STDERR]
>> 
>> Resource limits are not supported and ignored on cgroups V1 rootless systems
>> 
>> [STDOUT]
>> 
>> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
>> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
>> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
>> 
>> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
>> 
>> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added a comment

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23948#pullrequestreview-2691265860

From iklam at openjdk.org  Mon Mar 17 16:35:12 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Mar 2025 16:35:12 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v4]
In-Reply-To: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
Message-ID: <oOg8vrDznJaZjVqNQB8aE4BSDo9qeWOy8gaw6qjHXPc=.6bb53638-a9c6-4e1d-b423-b7a60dd17710@github.com>

> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
> 
> 
> make test JTREG=AOT_JDK=true \
>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
> 
> 
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
> 
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @erikj79 comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24067/files
  - new: https://git.openjdk.org/jdk/pull/24067/files/70291772..ae241b5e

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

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

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

From jiangli at openjdk.org  Mon Mar 17 16:35:35 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 17 Mar 2025 16:35:35 GMT
Subject: RFR: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig and
 XCheckJSig.java on static JDK [v2]
In-Reply-To: <xcJzwAvSLQotSBI-svn3vb13JLJMhbYDcWP-EUoJTb8=.3a89620c-7711-48bb-958b-f1cbd5e3351a@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
 <w6R5ODpVlCWxfbr-yLjGjSk3zdgQtJDta4uWv_kh0TE=.9c2c0111-6b85-4d49-91fb-2aa7603ff954@github.com>
 <xcJzwAvSLQotSBI-svn3vb13JLJMhbYDcWP-EUoJTb8=.3a89620c-7711-48bb-958b-f1cbd5e3351a@github.com>
Message-ID: <gBrfCqEkyPZHojmb583CX0048KTN-M-nQ-9YeuH9GGc=.c0ea1bc3-4266-4171-ac12-489704097c50@github.com>

On Mon, 17 Mar 2025 07:27:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address @manc's comment: added @comment for TODO.
>
> Ok.

Thanks for the review, @dholmes-ora!

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

PR Comment: https://git.openjdk.org/jdk/pull/24020#issuecomment-2730158438

From iklam at openjdk.org  Mon Mar 17 16:38:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Mar 2025 16:38:28 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <AoEU6OcFkUhlXsWdWJHxGM6rfl8SMXXMC8_B7d4eAz4=.6cddc1dc-04ba-4765-a07f-820209365666@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
 <k5OEtMPDAD3uEQXBdHClJu4ZckUoNKLcwHljckuPD7o=.cbcb5fbc-9dfa-45f7-85ab-f83d59769182@github.com>
 <dC9PPIjPJ26NGvrApdk3e2DF7nFJsHc7jS4yxCrotJQ=.3f29134d-e9d5-4c3f-939c-0e0839d2bca8@github.com>
 <AoEU6OcFkUhlXsWdWJHxGM6rfl8SMXXMC8_B7d4eAz4=.6cddc1dc-04ba-4765-a07f-820209365666@github.com>
Message-ID: <sF_ruuloy1B6PSb0ebEz7oAYkedHsexyxgC7FeG2MhY=.5c198106-f7f4-4f0c-affb-f7e99c811f30@github.com>

On Mon, 17 Mar 2025 10:55:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > So I think the best solution may be for jtreg to save the properties to a location of its choice, and pass this location to the test cases with a property like test.vm.properties.file.
> 
> From what I understand of the use case, certain parts of the test code would like to use key/value pairs whose keys are pre-defined in the JDK testsuite and values are computed by testsuite specific class, before jtreg launches the tests. These set of key/value pairs are currently used by jtreg in the evaluation of the `@requires` tag of the test definition. The proposal here is to make available that same key/value pairs to the test code itself (once the test is launched) so that they can do additional decisions based on those properties.
> 
> If I understood that correctly then the proposal in jtreg would be to expose the https://github.com/openjdk/jtreg/blob/master/src/share/classes/com/sun/javatest/regtest/config/RegressionContext.java#L38. Since tests are not expected to rely on jtreg classes/types, the way to expose that detail would be by persisting the key/value pairs to a (properties) file whose path is then passed along to the test as a standard jtreg system property like the ones noted in https://openjdk.org/jtreg/tag-spec.html#testvars. I think that's doable. Could you file a request for this in the CODETOOLS project? I would need additional inputs from others in that project whether it's a good thing to expose this but based on my limited knowledge of that project, I think it's OK to do that.

Thanks @jaikiran . I filed [CODETOOLS-7903975](https://bugs.openjdk.org/browse/CODETOOLS-7903975)

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2730167839

From jiangli at openjdk.org  Mon Mar 17 16:40:22 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 17 Mar 2025 16:40:22 GMT
Subject: Integrated: 8351891: Disable TestBreakSignalThreadDump.java#with_jsig
 and XCheckJSig.java on static JDK
In-Reply-To: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
References: <ZnVD4OFeLfRhWhM2F6WUYozEtqUHrB1wZpJOkHLBhcI=.9e205b4a-9b52-4c00-8f2d-c5c9e62e64fb@github.com>
Message-ID: <dfwa0c4eF1b6RzY7oQXtVPrQrASrcS13_cbTz_qK2SI=.ec3c4ec7-99a6-4892-95f7-7632f30bbe03@github.com>

On Wed, 12 Mar 2025 23:47:03 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this change that disables TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK. Thanks

This pull request has now been integrated.

Changeset: 2674a31b
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2674a31bb85a3f7b2dcca9a9bb10a79fba026da0
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8351891: Disable TestBreakSignalThreadDump.java#with_jsig and XCheckJSig.java on static JDK

Reviewed-by: manc, dholmes

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

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

From jiangli at openjdk.org  Mon Mar 17 16:43:08 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 17 Mar 2025 16:43:08 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <0DXUGGAW4jSFGprqAMu-hawFDXt77gKQmNpuG4vhPyI=.42a61744-f26f-4082-8863-251c95111eac@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
 <b73tvazlPA5Z9cE50uTEZRysfj94z1J3Nd3FxUClZvA=.0e0d5d89-1bec-47d7-97e8-e20e5a9698c0@github.com>
 <0DXUGGAW4jSFGprqAMu-hawFDXt77gKQmNpuG4vhPyI=.42a61744-f26f-4082-8863-251c95111eac@github.com>
Message-ID: <YoKA_pnpxtt7gENvoj813bgWiHivX4xioW4bAeVCspI=.0ea4744f-6357-4192-9071-db6d5e8b3fd3@github.com>

On Mon, 17 Mar 2025 07:16:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address iklam's comment:
>>   - Use get_default_classlist helper function.
>
> This seems much simpler regardless of static: walk down from the top, rather up from the bottom.
> 
> Thanks

@dholmes-ora Thanks for the review!

@iklam Any additional comment? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/24000#issuecomment-2730186465

From kbarrett at openjdk.org  Mon Mar 17 16:46:23 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 17 Mar 2025 16:46:23 GMT
Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime
 error: shift exponent 65 is too large for 64-bit type 'long unsigned
 int' [v4]
In-Reply-To: <AW1ePGyDD01rR0muxgEtH00frMe6jMRo74TBFUKQEiA=.6e93469f-df9b-42eb-a534-4da92811bdc3@github.com>
References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com>
 <AW1ePGyDD01rR0muxgEtH00frMe6jMRo74TBFUKQEiA=.6e93469f-df9b-42eb-a534-4da92811bdc3@github.com>
Message-ID: <eT6Z1JPWCcbCnkI5xgrkFOqqP-5nmDEZNhbDy8bQMug=.d447debb-0a25-4bc3-88e1-e4892969c3ef@github.com>

On Thu, 13 Feb 2025 09:31:08 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The issue existed in making Fingerprints of method names. Each parameter in the methods' arguments is decoded as a 4-bits value. The 64-bits `fingertprint_t` can hold up to 14 parameters plus return type and static bit. To make the Fingerprint, the signature is iterated one parameter at a time and the corresponding code is accumulated after shifting the bits up.
>> Some compilers do not mask the shift value to the base size and UBSAN catches the case. 
>> In this PR, the number of parameters (`_param_count`) is used and compared with the max (14) to do the shift operation safely. The pre-existing `_param_size` is not reflecting the number of parameters, since it is incremented by 2 for `T_DOUBLE` and `T_LONG` types.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   count member is removed. Axel's suggestion is implemented.

My concerns about an earlier version of this change have been addressed.  The latest
version looks okay to me, but I'm not really familiar with the signature handling code,
so don't count me as a reviewer.

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

PR Review: https://git.openjdk.org/jdk/pull/22807#pullrequestreview-2691320069

From iklam at openjdk.org  Mon Mar 17 16:54:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 17 Mar 2025 16:54:09 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <b73tvazlPA5Z9cE50uTEZRysfj94z1J3Nd3FxUClZvA=.0e0d5d89-1bec-47d7-97e8-e20e5a9698c0@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
 <b73tvazlPA5Z9cE50uTEZRysfj94z1J3Nd3FxUClZvA=.0e0d5d89-1bec-47d7-97e8-e20e5a9698c0@github.com>
Message-ID: <wQj2mDKgORdhYjZk5jeCSOoBFboms17pfKGIljuJ66g=.cdb2a02d-b103-47f9-929e-b878d143ccfa@github.com>

On Thu, 13 Mar 2025 23:36:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the change to use `Arguments::get_java_home` to resolve the default classlist path. This avoids the complication of walking up the directory from libjvm and the subtle handling for '/lib' dir, which is what `MetaspaceShared::get_default_classlist` needs to do. This fixes the failure on static JDK for running `-Xshare:dump` with the default classlist. Please see more details in https://bugs.openjdk.org/browse/JDK-8351689.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address iklam's comment:
>   - Use get_default_classlist helper function.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24000#pullrequestreview-2691352564

From jiangli at openjdk.org  Mon Mar 17 16:58:13 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 17 Mar 2025 16:58:13 GMT
Subject: RFR: 8351689: -Xshare:dump with default classlist fails on static
 JDK [v2]
In-Reply-To: <b73tvazlPA5Z9cE50uTEZRysfj94z1J3Nd3FxUClZvA=.0e0d5d89-1bec-47d7-97e8-e20e5a9698c0@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
 <b73tvazlPA5Z9cE50uTEZRysfj94z1J3Nd3FxUClZvA=.0e0d5d89-1bec-47d7-97e8-e20e5a9698c0@github.com>
Message-ID: <FHiqkAQGZYNi9R7hLBXpWmXGrMEoXktlNW-3dPaX7z0=.55e660fa-953c-482d-91c2-5f4b19225627@github.com>

On Thu, 13 Mar 2025 23:36:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the change to use `Arguments::get_java_home` to resolve the default classlist path. This avoids the complication of walking up the directory from libjvm and the subtle handling for '/lib' dir, which is what `MetaspaceShared::get_default_classlist` needs to do. This fixes the failure on static JDK for running `-Xshare:dump` with the default classlist. Please see more details in https://bugs.openjdk.org/browse/JDK-8351689.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address iklam's comment:
>   - Use get_default_classlist helper function.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24000#issuecomment-2730231793

From jiangli at openjdk.org  Mon Mar 17 16:58:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 17 Mar 2025 16:58:14 GMT
Subject: Integrated: 8351689: -Xshare:dump with default classlist fails on
 static JDK
In-Reply-To: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
References: <9GQ5DaV1vEBHpZXop4JfQIhVbNIZfkpOsUZpT3P99Ag=.f101c676-d07e-4897-a69d-3e52b6c36734@github.com>
Message-ID: <-I5dmto0leRxp2W93mX6AUgkcTIRL2EesmAphNK7td4=.5fd6a29c-7d42-4f10-8d51-2fab284a0b92@github.com>

On Tue, 11 Mar 2025 20:52:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change to use `Arguments::get_java_home` to resolve the default classlist path. This avoids the complication of walking up the directory from libjvm and the subtle handling for '/lib' dir, which is what `MetaspaceShared::get_default_classlist` needs to do. This fixes the failure on static JDK for running `-Xshare:dump` with the default classlist. Please see more details in https://bugs.openjdk.org/browse/JDK-8351689.

This pull request has now been integrated.

Changeset: 47c19609
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47c19609659a85397e3eed7c2a3a918ff6055edc
Stats:     26 lines in 1 file changed: 0 ins; 21 del; 5 mod

8351689: -Xshare:dump with default classlist fails on static JDK

Reviewed-by: iklam, dholmes

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

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

From erikj at openjdk.org  Mon Mar 17 17:37:22 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 17 Mar 2025 17:37:22 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v4]
In-Reply-To: <oOg8vrDznJaZjVqNQB8aE4BSDo9qeWOy8gaw6qjHXPc=.6bb53638-a9c6-4e1d-b423-b7a60dd17710@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
 <oOg8vrDznJaZjVqNQB8aE4BSDo9qeWOy8gaw6qjHXPc=.6bb53638-a9c6-4e1d-b423-b7a60dd17710@github.com>
Message-ID: <_uEgF1C6bBPSqmc2zN2JKVJ1HfRI-VkwIUwnO6_UO4k=.e6bcb686-2ec1-4dd2-aabe-07845ce2fb6b@github.com>

On Mon, 17 Mar 2025 16:35:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
>> 
>> 
>> make test JTREG=AOT_JDK=true \
>>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
>> 
>> 
>> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
>> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
>> 
>> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @erikj79 comments

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24067#pullrequestreview-2691495023

From ayang at openjdk.org  Mon Mar 17 20:03:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Mar 2025 20:03:53 GMT
Subject: RFR: 8352178: Add precondition in Handshake::execute to prevent
 deadlock
Message-ID: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>

Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
All existing callsites satisfy this precondition already.

Test: tier1-5

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

Commit messages:
 - handshake-assert

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

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

From amenkov at openjdk.org  Mon Mar 17 20:43:16 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 17 Mar 2025 20:43:16 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
Message-ID: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>

The change fixes crash on AIX after JDK-8319055
Can't test it on AIX, but the reason is obvious from the stack trace.
AIX is the only platform that does not implement `reply_writer` yet

Testing: sanity tier1

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

Commit messages:
 - fix

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

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

From dholmes at openjdk.org  Mon Mar 17 23:33:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 23:33:07 GMT
Subject: RFR: 8352178: Add precondition in Handshake::execute to prevent
 deadlock
In-Reply-To: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
Message-ID: <lf7xau4JhHJjM9-NXm0m6eIsZL-R6LOvKLTDaAUw5I8=.6b6fb833-f548-4dd4-b06f-c4cfbd967c77@github.com>

On Mon, 17 Mar 2025 19:57:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
> All existing callsites satisfy this precondition already.
> 
> Test: tier1-5

Looks fine. One comment typo.

Thanks

src/hotspot/share/runtime/handshake.cpp line 356:

> 354:   // The current thread must not belong to the SuspendibleThreadSet, because an
> 355:   // on-the-fly safepoint can be waiting for the current thread, and the
> 356:   // current thread will be blocked in VMThread::execute, resulting into

Suggestion:

  // current thread will be blocked in VMThread::execute, resulting in

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24088#pullrequestreview-2692352157
PR Review Comment: https://git.openjdk.org/jdk/pull/24088#discussion_r1999839180

From amenkov at openjdk.org  Tue Mar 18 00:22:51 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 00:22:51 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
Message-ID: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>

The change fixes regression from JDK-8319055 (see David's evaluation in the CR description)

Testing: sanity tier1;
  tier6, tier7 - in progress

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

Commit messages:
 - ThreadBlockInVM in close

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

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

From iklam at openjdk.org  Tue Mar 18 00:52:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Mar 2025 00:52:15 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v3]
In-Reply-To: <W3QKe1sM2b0WNXRv6yB7SetsK9QBTAn6gb_HTcH-XMQ=.58ea7afb-6c39-4250-9ced-46b90a51caee@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
 <RteUnEI6U8UZx20SaFJuiyCU1p0ehX1JOJtcm2GObHA=.65dcb686-5cf9-41b2-9bc0-7e03d01d99cb@github.com>
 <W3QKe1sM2b0WNXRv6yB7SetsK9QBTAn6gb_HTcH-XMQ=.58ea7afb-6c39-4250-9ced-46b90a51caee@github.com>
Message-ID: <fPF6CcS-GlVjZ0M2h4NdO8A9tQflRepWV1YQMI0Pqg4=.92fec6ef-e042-4c9b-9f9a-bb776855a497@github.com>

On Mon, 17 Mar 2025 16:07:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed windows path problem
>
> Marked as reviewed by lmesnik (Reviewer).

Thanks @lmesnik @erikj79 @vnkozlov for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/24067#issuecomment-2731289843

From iklam at openjdk.org  Tue Mar 18 00:52:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Mar 2025 00:52:16 GMT
Subject: Integrated: 8352084: Add more test code in TestSetupAOT.java
In-Reply-To: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
Message-ID: <rj89IGT9-7kXOCbB1j6V2diZjYur6P8MU8rXw0nPWEI=.5b0fe114-6e35-4312-82eb-e2a4d6b12995@github.com>

On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
> 
> 
> make test JTREG=AOT_JDK=true \
>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
> 
> 
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
> 
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`

This pull request has now been integrated.

Changeset: 38499b3f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38499b3fbfcd22252ddf860d42b9eb0bf6f77235
Stats:     185 lines in 5 files changed: 159 ins; 1 del; 25 mod

8352084: Add more test code in TestSetupAOT.java

Reviewed-by: erikj, kvn, lmesnik

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

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

From dholmes at openjdk.org  Tue Mar 18 02:04:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Mar 2025 02:04:12 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
Message-ID: <Es-9rYh9ZNbqOO_iN_cTr_2Jq1P5Yt5qDoURThhJ5Hc=.91bc3158-4f90-4133-a550-edcc0d54968e@github.com>

On Mon, 17 Mar 2025 20:35:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes crash on AIX after JDK-8319055
> Can't test it on AIX, but the reason is obvious from the stack trace.
> AIX is the only platform that does not implement `reply_writer` yet
> 
> Testing: sanity tier1

This is obviously a necessary fix (per the comment on `complete`.) and so I'm hitting approve. But I'm not sure this is sufficient.

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

> 128:   // If reply_writer is provided, writes the results.
> 129:   void complete() {
> 130:     if (_reply_writer != nullptr) {

Is this sufficient? I'm looking at JDK-8319055 for the first time and I can't figure out how the value of `_reply_writer` affects the `_allow_streaming` logic that accesses the reply-writer. We seem to enable streaming mode in platform independent code, yet the availability of the reply-writer is platform dependent! ???

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24089#pullrequestreview-2692593449
PR Review Comment: https://git.openjdk.org/jdk/pull/24089#discussion_r1999992737

From dholmes at openjdk.org  Tue Mar 18 02:08:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Mar 2025 02:08:19 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <Es-9rYh9ZNbqOO_iN_cTr_2Jq1P5Yt5qDoURThhJ5Hc=.91bc3158-4f90-4133-a550-edcc0d54968e@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <Es-9rYh9ZNbqOO_iN_cTr_2Jq1P5Yt5qDoURThhJ5Hc=.91bc3158-4f90-4133-a550-edcc0d54968e@github.com>
Message-ID: <hKipfeFCMwh8QgdYAkpV_jTNVB1UqhN1Te8OFDGx-uY=.064bec94-4cd6-4037-ac48-9872bc835f1c@github.com>

On Tue, 18 Mar 2025 02:00:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The change fixes crash on AIX after JDK-8319055
>> Can't test it on AIX, but the reason is obvious from the stack trace.
>> AIX is the only platform that does not implement `reply_writer` yet
>> 
>> Testing: sanity tier1
>
> src/hotspot/share/services/attachListener.cpp line 130:
> 
>> 128:   // If reply_writer is provided, writes the results.
>> 129:   void complete() {
>> 130:     if (_reply_writer != nullptr) {
> 
> Is this sufficient? I'm looking at JDK-8319055 for the first time and I can't figure out how the value of `_reply_writer` affects the `_allow_streaming` logic that accesses the reply-writer. We seem to enable streaming mode in platform independent code, yet the availability of the reply-writer is platform dependent! ???

Ah found it - sorry:

_allow_streaming(reply_writer == nullptr ? false : allow_streaming),

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24089#discussion_r1999997622

From dholmes at openjdk.org  Tue Mar 18 02:52:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Mar 2025 02:52:11 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
In-Reply-To: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
Message-ID: <DXm4w2it939kzDfA5g4fmOK4WA41OTx8NGB8Mdn4QF0=.01f4affa-d23a-4780-97a4-22b6da240bfd@github.com>

On Tue, 18 Mar 2025 00:16:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes regression from JDK-8319055 (see David's evaluation in the CR description)
> 
> Testing: sanity tier1;
>   tier6, tier7 - in progress

Fix looks good.

Any idea on why things are taking so long? Is the pipe undersized?

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24091#pullrequestreview-2692723214

From iklam at openjdk.org  Tue Mar 18 03:55:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Mar 2025 03:55:01 GMT
Subject: RFR: 8351748: Classes of method handles in AOT cache should be
 AOT-inited [v2]
In-Reply-To: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
Message-ID: <UpygeU7Cqcx9ebgfjyoKhTWTNKfOwWc6P6nO3Iyu5-w=.88eab0b0-8b12-45ad-be70-767dbf11bdca@github.com>

> Whenever we store a MethodHandle in the AOT cache, we need to make sure that the class of this method is aot-initialized. Otherwise, the JVM might execute a BSM without first initializing the class of this BSM.
> 
> Please see the bug report for detail analysis.
> 
> I also fixed a problem in related logging code.

Ioi Lam 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:

 - clean up
 - Merge branch 'master' into 8351748-classes-of-cached-method-handles-should-be-aot-inited
 - Added CDS::needsClassInitBarrier() for adding init barriers to cached Method/Var Handles
 - Merge branch 'master' into 8351748-classes-of-cached-method-handles-should-be-aot-inited
 - Experiment: always include init barriers in cached MethodHandle/VarHandle
 - 8351748: Classes of method handles in the AOT cache should be AOT-initialized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24004/files
  - new: https://git.openjdk.org/jdk/pull/24004/files/f683312a..7acc985d

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

  Stats: 14885 lines in 414 files changed: 8724 ins; 3706 del; 2455 mod
  Patch: https://git.openjdk.org/jdk/pull/24004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24004/head:pull/24004

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

From dholmes at openjdk.org  Tue Mar 18 05:39:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Mar 2025 05:39:08 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v4]
In-Reply-To: <lsNqFBIw-Fy1BLpI5mi6qeEIPnVxjiduQY5vlf083xo=.8ad72fef-87db-421e-bf44-34224e3020a6@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <lsNqFBIw-Fy1BLpI5mi6qeEIPnVxjiduQY5vlf083xo=.8ad72fef-87db-421e-bf44-34224e3020a6@github.com>
Message-ID: <yhx8SBPEXsa1FCl0tYwaZSWuHt89HJurfhLBNGRTnOo=.f3979f3f-3c71-460b-aecf-6a7517222345@github.com>

On Mon, 17 Mar 2025 16:00:47 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
>> 
>> containers/docker/TestMemoryWithSubgroups.java
>> 
>> [STDERR]
>> 
>> Resource limits are not supported and ignored on cgroups V1 rootless systems
>> 
>> [STDOUT]
>> 
>> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
>> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
>> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
>> 
>> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
>> 
>> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added a comment

Looks fine to me. Thanks

Test now passes in our CI. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23948#pullrequestreview-2693034247
PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2731725973

From schernyshev at openjdk.org  Tue Mar 18 07:35:15 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 18 Mar 2025 07:35:15 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v4]
In-Reply-To: <yhx8SBPEXsa1FCl0tYwaZSWuHt89HJurfhLBNGRTnOo=.f3979f3f-3c71-460b-aecf-6a7517222345@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <lsNqFBIw-Fy1BLpI5mi6qeEIPnVxjiduQY5vlf083xo=.8ad72fef-87db-421e-bf44-34224e3020a6@github.com>
 <yhx8SBPEXsa1FCl0tYwaZSWuHt89HJurfhLBNGRTnOo=.f3979f3f-3c71-460b-aecf-6a7517222345@github.com>
Message-ID: <ffZq2muxlPGCzQocu3JOCjsdnGvUskQ1lJnX3p4ljk4=.495856d1-737a-4117-858e-ccf302b05f64@github.com>

On Tue, 18 Mar 2025 05:34:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added a comment
>
> Test now passes in our CI. Thanks

Thanks @dholmes-ora @jerboaa for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2731952079

From duke at openjdk.org  Tue Mar 18 07:35:15 2025
From: duke at openjdk.org (duke)
Date: Tue, 18 Mar 2025 07:35:15 GMT
Subject: RFR: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing [v4]
In-Reply-To: <lsNqFBIw-Fy1BLpI5mi6qeEIPnVxjiduQY5vlf083xo=.8ad72fef-87db-421e-bf44-34224e3020a6@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
 <lsNqFBIw-Fy1BLpI5mi6qeEIPnVxjiduQY5vlf083xo=.8ad72fef-87db-421e-bf44-34224e3020a6@github.com>
Message-ID: <EPculoxDVVEPLAH1KxU7kt6jJHJE5StA_TI7qmF0QKc=.92709ef9-8e23-4b2a-ae75-9c73b55fffc7@github.com>

On Mon, 17 Mar 2025 16:00:47 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
>> 
>> containers/docker/TestMemoryWithSubgroups.java
>> 
>> [STDERR]
>> 
>> Resource limits are not supported and ignored on cgroups V1 rootless systems
>> 
>> [STDOUT]
>> 
>> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
>> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
>> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
>> 
>> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
>> 
>> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added a comment

@sercher 
Your change (at version 39657218874f89eddbeb6ff0564725433afe0cb5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23948#issuecomment-2731954143

From alanb at openjdk.org  Tue Mar 18 07:44:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Mar 2025 07:44:09 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
In-Reply-To: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
Message-ID: <Imjzg82Tl3Y2iVCniAbvpUE2YsVG1l33W4bGgXMt6Ew=.e675596e-ad87-495c-8237-e08756982676@github.com>

On Tue, 18 Mar 2025 00:16:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes regression from JDK-8319055 (see David's evaluation in the CR description)
> 
> Testing: sanity tier1;
>   tier6, tier7 - in progress

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24091#pullrequestreview-2693319363

From alanb at openjdk.org  Tue Mar 18 07:44:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Mar 2025 07:44:10 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
In-Reply-To: <DXm4w2it939kzDfA5g4fmOK4WA41OTx8NGB8Mdn4QF0=.01f4affa-d23a-4780-97a4-22b6da240bfd@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
 <DXm4w2it939kzDfA5g4fmOK4WA41OTx8NGB8Mdn4QF0=.01f4affa-d23a-4780-97a4-22b6da240bfd@github.com>
Message-ID: <UvUBCvW0o8r0s2bHJc_Si26P33GGKQjP70cYrITL_18=.c90c355f-f1da-4353-af85-90e40b553c41@github.com>

On Tue, 18 Mar 2025 02:49:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Any idea on why things are taking so long? Is the pipe undersized?

It's usually just handled by Windows although I think you can override/configure with SetNamedPipeHandleState.

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

PR Comment: https://git.openjdk.org/jdk/pull/24091#issuecomment-2731972419

From azafari at openjdk.org  Tue Mar 18 08:13:18 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Mar 2025 08:13:18 GMT
Subject: Integrated: 8331201: UBSAN enabled  build reports on Linux x86_64
 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned
 int'
In-Reply-To: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com>
References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com>
Message-ID: <uUSmkKupBXWqfHGvgX2sUPjtuebB7CHugy6SMDt7eAs=.5385cfd3-ebc2-413f-8d3d-53c0423f03b8@github.com>

On Wed, 18 Dec 2024 09:42:20 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The issue existed in making Fingerprints of method names. Each parameter in the methods' arguments is decoded as a 4-bits value. The 64-bits `fingertprint_t` can hold up to 14 parameters plus return type and static bit. To make the Fingerprint, the signature is iterated one parameter at a time and the corresponding code is accumulated after shifting the bits up.
> Some compilers do not mask the shift value to the base size and UBSAN catches the case. 
> In this PR, the number of parameters (`_param_count`) is used and compared with the max (14) to do the shift operation safely. The pre-existing `_param_size` is not reflecting the number of parameters, since it is incremented by 2 for `T_DOUBLE` and `T_LONG` types.

This pull request has now been integrated.

Changeset: f4ddac5e
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4ddac5e58322a801182eda005a9592c78128569
Stats:     9 lines in 2 files changed: 2 ins; 2 del; 5 mod

8331201: UBSAN enabled  build reports on Linux x86_64 runtime error: shift exponent 65 is too large for 64-bit type 'long unsigned int'

Reviewed-by: dlong, aboldtch

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

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

From azafari at openjdk.org  Tue Mar 18 08:13:18 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Mar 2025 08:13:18 GMT
Subject: RFR: 8331201: UBSAN enabled build reports on Linux x86_64 runtime
 error: shift exponent 65 is too large for 64-bit type 'long unsigned
 int' [v4]
In-Reply-To: <eT6Z1JPWCcbCnkI5xgrkFOqqP-5nmDEZNhbDy8bQMug=.d447debb-0a25-4bc3-88e1-e4892969c3ef@github.com>
References: <1xv_UU8XMBN6C87Rk5R0l5IKp-9s3_efJkQ19y7kpsA=.a7a72779-59df-4a96-873b-76aa4c7e0b56@github.com>
 <AW1ePGyDD01rR0muxgEtH00frMe6jMRo74TBFUKQEiA=.6e93469f-df9b-42eb-a534-4da92811bdc3@github.com>
 <eT6Z1JPWCcbCnkI5xgrkFOqqP-5nmDEZNhbDy8bQMug=.d447debb-0a25-4bc3-88e1-e4892969c3ef@github.com>
Message-ID: <3Q_mbFpqfi5OG23uV9CgwPTCEYVBYJvw_1_DIFtEGaU=.5964fb4f-5c0c-4070-b713-09513e371a51@github.com>

On Mon, 17 Mar 2025 16:43:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   count member is removed. Axel's suggestion is implemented.
>
> My concerns about an earlier version of this change have been addressed.  The latest
> version looks okay to me, but I'm not really familiar with the signature handling code,
> so don't count me as a reviewer.

Thank you again @kimbarrett , @dean-long and @Axel for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22807#issuecomment-2732040778

From ayang at openjdk.org  Tue Mar 18 08:48:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Mar 2025 08:48:21 GMT
Subject: RFR: 8352178: Add precondition in Handshake::execute to prevent
 deadlock [v2]
In-Reply-To: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
Message-ID: <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>

> Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
> All existing callsites satisfy this precondition already.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/handshake.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24088/files
  - new: https://git.openjdk.org/jdk/pull/24088/files/e9b48b70..7480c141

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

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

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

From shade at openjdk.org  Tue Mar 18 09:15:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Mar 2025 09:15:10 GMT
Subject: RFR: 8352178: Add precondition in Handshake::execute to prevent
 deadlock [v2]
In-Reply-To: <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
Message-ID: <3I9v-cKqH_9Vk_3sMqJOqUc-sdZxlaPGZbrhdsB84aI=.9a5924a4-c60c-422f-b07f-0aca795bec3f@github.com>

On Tue, 18 Mar 2025 08:48:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
>> All existing callsites satisfy this precondition already.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/handshake.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Looks reasonable. Have you caught the deadlock like this anywhere, e.g. in development for some feature?

GHA is misbehaving a bit, not the fault of this patch, I think. Still, maybe wait a little and trigger more GHA runs to see if the patch is green?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24088#pullrequestreview-2693596863

From azafari at openjdk.org  Tue Mar 18 09:20:59 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Mar 2025 09:20:59 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v3]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <2_es29DUqfL80VeGUDoCVehTDmGaLtW3PflzXXeA5Xc=.3104544b-a4d4-40d5-95bd-5a173147e83f@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  review comments applied.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24028/files
  - new: https://git.openjdk.org/jdk/pull/24028/files/768ecd98..9415f9c1

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

  Stats: 87 lines in 5 files changed: 36 ins; 1 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/24028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028

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

From azafari at openjdk.org  Tue Mar 18 09:20:59 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Mar 2025 09:20:59 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
Message-ID: <SSi4YHEnmyH8Nmy8ukLKxnOpmmwJ7jeE2LM5YsjEKM0=.fbbf077b-d112-4f93-bd59-d74b99dc9b7a@github.com>

On Thu, 13 Mar 2025 13:13:15 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed a bug.

The cases and their result:

// (address, size, callstack) arguments

// x == invalid stack == not-filled

# Case 1
tree.reserve(0, 100, s1);
tree.commit(25, 25 , s2);
    0       25         50         100
--------  --------  --------  --------
in   out  in   out  in   out  in   out 
x    s1   s1   s2   s2   x    s1   x
x    x    x    x    x    x     x   x

commit is not at start of the region.

# Case 2
tree.reserve(0, 100, s1);
tree.reserve(10, 10, s2);
    0       10         20         100
--------  --------  --------  --------
in   out  in   out  in   out  in   out 
x    s1   s1   s2   s2   x    s1   x
x    x    x    x    x    x     x   x

# Case 3
tree.commit(0, 100, s1);
    0       100  
--------  --------
in   out  in   out
x    s1   s1   x 
x    x    x    x  

it is not acceptable to committ a region without reserving it.

# Case 4
tree.commit(0, 100, s1);
tree.reserve(0, 100, s2);
    0       100  
--------  --------
in   out  in   out
x    s2   s2   x 
x    s1   s1   x

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

PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2732247346

From azafari at openjdk.org  Tue Mar 18 09:21:00 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Mar 2025 09:21:00 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <CnYLmMNbpQKmTPLOdQghXFhc_zdO4zrdagRG-rQ19ig=.393bb2b3-5533-45d0-a423-e3475534866d@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
 <CnYLmMNbpQKmTPLOdQghXFhc_zdO4zrdagRG-rQ19ig=.393bb2b3-5533-45d0-a423-e3475534866d@github.com>
Message-ID: <9_3sYw2keSqnZeoHKEESDm6rg-1WwSDC1GUHewPaTAs=.904a1f7b-40b5-48a3-b92f-1574919a0a93@github.com>

On Mon, 17 Mar 2025 10:07:50 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug.
>
> src/hotspot/share/nmt/vmatree.cpp line 96:
> 
>> 94:           && !(state == StateType::Reserved && !use_tag_inplace)            // we are not reserving a new region
>> 95:           && !NativeCallStackStorage::is_invalid(leqA_n->val().out.stack()) // the primary stack is already filled
>> 96:          ) {
> 
> These conditions can be refactored out and given useful names:
> 
> ```c++
> bool baz = ...;
> bool foo = ...;
> boo bar = ...;
> if (baz || (foo && bar)) { /* ... */ }

Done.

> src/hotspot/share/nmt/vmatree.hpp line 128:
> 
>> 126: 
>> 127:     NativeCallStackStorage::StackIndex second_stack() const {
>> 128:       return second_idx;
> 
> Rename accessors into `reserved_stack` and `committed_stack` and add `bool has_committed_stack()`?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2000558687
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2000559027

From mdoerr at openjdk.org  Tue Mar 18 09:24:12 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Mar 2025 09:24:12 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
Message-ID: <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>

On Mon, 17 Mar 2025 20:35:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes crash on AIX after JDK-8319055
> Can't test it on AIX, but the reason is obvious from the stack trace.
> AIX is the only platform that does not implement `reply_writer` yet
> 
> Testing: sanity tier1

LGTM. Thanks for fixing it so quickly! Should `reply_writer` get implemented? We could file an RFE.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24089#pullrequestreview-2693629227

From azafari at openjdk.org  Tue Mar 18 09:26:21 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Mar 2025 09:26:21 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <CnYLmMNbpQKmTPLOdQghXFhc_zdO4zrdagRG-rQ19ig=.393bb2b3-5533-45d0-a423-e3475534866d@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
 <CnYLmMNbpQKmTPLOdQghXFhc_zdO4zrdagRG-rQ19ig=.393bb2b3-5533-45d0-a423-e3475534866d@github.com>
Message-ID: <AH0hXX1XNAz1laC0_-ef8C7QgJWUWACfE5pADjJmAEo=.59f8861f-c3f8-47f4-a040-9d71198ca7e3@github.com>

On Mon, 17 Mar 2025 09:59:42 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a bug.
>
> src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 53:
> 
>> 51: 
>> 52:   static bool is_invalid(StackIndex a) {
>> 53:     return a == invalid || a < 0;
> 
> If this change is necessary, then there's a bug in the code.

fixed.

> src/hotspot/share/nmt/vmatree.hpp line 95:
> 
>> 93:     uint8_t type_tag[2];
>> 94:     NativeCallStackStorage::StackIndex sidx;       // call-stack of all operations
>> 95:     NativeCallStackStorage::StackIndex second_idx; // call-stack when committing/uncommitting the start-node of a reserved region
> 
> These can be called `primary_stack` and `secondary_stack`. Does an uncommitted region really have a stack?

renamed.

Yes uncommit also has stack although never reported. `VMATree::register_mapping()` will save the stack in the nodes, regardless of the operation. It is done when constructing the `stA` and `stB` interval-states:

IntervalChange stA{
      IntervalState{StateType::Released, empty_regiondata},
      IntervalState{              state,   metadata}
  };
  IntervalChange stB{
      IntervalState{              state,   metadata},
      IntervalState{StateType::Released, empty_regiondata}
  };

The stack may be empty or whatever passed in by `metadata` arg.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2000569649
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2000569358

From ayang at openjdk.org  Tue Mar 18 09:36:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Mar 2025 09:36:06 GMT
Subject: RFR: 8352178: Add precondition in Handshake::execute to prevent
 deadlock [v2]
In-Reply-To: <3I9v-cKqH_9Vk_3sMqJOqUc-sdZxlaPGZbrhdsB84aI=.9a5924a4-c60c-422f-b07f-0aca795bec3f@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
 <3I9v-cKqH_9Vk_3sMqJOqUc-sdZxlaPGZbrhdsB84aI=.9a5924a4-c60c-422f-b07f-0aca795bec3f@github.com>
Message-ID: <TZGPYZkoGQ4brTJwyjtKvfoBROyTg8_y1joXVOthaYA=.526ac27f-4057-4659-9228-b9ceff41abae@github.com>

On Tue, 18 Mar 2025 09:12:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Have you caught the deadlock like this anywhere, e.g. in development for some feature?

Not really, but the background is https://github.com/openjdk/jdk/pull/23739#discussion_r1991489399

> Still, maybe wait a little and trigger more GHA runs to see if the patch is green?

Sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/24088#issuecomment-2732302130

From schernyshev at openjdk.org  Tue Mar 18 09:40:24 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 18 Mar 2025 09:40:24 GMT
Subject: Integrated: 8351382: New test
 containers/docker/TestMemoryWithSubgroups.java is failing
In-Reply-To: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
References: <a4FmvRd6wG0xWW5wCw7xHJOTzkr5xVE2DDkV7-VyuQI=.940b20c7-6ef0-4314-a929-add5e2e5dc49@github.com>
Message-ID: <MKsJBrg_XxyfpKBUAoX22Yp5iDza0jlTVmUQEKTLbAg=.a7dce8a9-c5be-4e5c-8708-ee788021d84b@github.com>

On Fri, 7 Mar 2025 20:14:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> The new test fails in rootless Docker mode after [JDK-8343191](https://bugs.openjdk.org/browse/JDK-8343191):
> 
> containers/docker/TestMemoryWithSubgroups.java
> 
> [STDERR]
> 
> Resource limits are not supported and ignored on cgroups V1 rootless systems
> 
> [STDOUT]
> 
> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
> 
> The test TestMemoryWithSubgroups.java uses `--privileged` mode to modify process' cgroup, that has no effect in rootless mode. The test has to be skiped.
> 
> The fix is to query `info -f {{println .SecurityOptions}}` and check whether it has `name=rootless` in the output.

This pull request has now been integrated.

Changeset: 46b3d1d8
Author:    Sergey Chernyshev <schernyshev at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46b3d1d8cfd03e01d993be19d725cdbcafef7865
Stats:     17 lines in 1 file changed: 17 ins; 0 del; 0 mod

8351382: New test containers/docker/TestMemoryWithSubgroups.java is failing

Reviewed-by: sgehwolf, dholmes

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

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

From jsjolen at openjdk.org  Tue Mar 18 10:08:09 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 18 Mar 2025 10:08:09 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <SSi4YHEnmyH8Nmy8ukLKxnOpmmwJ7jeE2LM5YsjEKM0=.fbbf077b-d112-4f93-bd59-d74b99dc9b7a@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
 <SSi4YHEnmyH8Nmy8ukLKxnOpmmwJ7jeE2LM5YsjEKM0=.fbbf077b-d112-4f93-bd59-d74b99dc9b7a@github.com>
Message-ID: <xh2gQdozXh0olqvcgHWxKGnMdqUadtqU-TbuGa2Pmxc=.051caa15-c714-48ad-9e9c-ece8d686bbf1@github.com>

On Tue, 18 Mar 2025 09:16:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The cases and their result:
> 
> ```
> // (address, size, callstack) arguments
> 
> // x == invalid stack == not-filled
> 
> # Case 1
> tree.reserve(0, 100, s1);
> tree.commit(25, 25 , s2);
>     0       25         50         100
> --------  --------  --------  --------
> in   out  in   out  in   out  in   out 
> x    s1   s1   s2   s2   x    s1   x
> x    x    x    x    x    x     x   x
> 
> commit is not at start of the region.
> 
> # Case 2
> tree.reserve(0, 100, s1);
> tree.reserve(10, 10, s2);
>     0       10         20         100
> --------  --------  --------  --------
> in   out  in   out  in   out  in   out 
> x    s1   s1   s2   s2   x    s1   x
> x    x    x    x    x    x     x   x
> 
> # Case 3
> tree.commit(0, 100, s1);
>     0       100  
> --------  --------
> in   out  in   out
> x    s1   s1   x 
> x    x    x    x  
> 
> it is not acceptable to commit a region without reserving it.
> 
> # Case 4
> tree.commit(0, 100, s1);
> tree.reserve(0, 100, s2);
>     0       100  
> --------  --------
> in   out  in   out
> x    s2   s2   x 
> x    s1   s1   x  
> ```

Let's go backwards:

# Case 4

This should only have the reserved stack s2, not the committed stack s1. Reserving after committing is the same as uncommitting. In fact, that is how we define `uncommit`.

# Case 3
Committing without reserving is fine, and we must support it. This should be interpreted as reserving implicitly.

# Case 2

Oops, here I interpreted what I wrote incorrectly. Your results seem correct.

# Case 1

Aha, so here the inner region actually ignores the outer reserved region. That doesn't seem right, how are you supposed to know what the reserved call stack is?

Consider this:


tree.reserve(0, 100, s1);
tree.commit(50, 25, s2);
tree.commit(51, 5, s3);
tree.reserve(0, 50, s4);
tree.reserve(56, 100 - 56, s4);
produce_report();


How is the reporter supposed to know what the reserved stack is of the innermost region `[51, 56)`? It can't,because we've lost that information.

We need a better definition of what is supposed to happen in these cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2732497643

From jkern at openjdk.org  Tue Mar 18 10:47:07 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 10:47:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <f_IVM6Xaku2Dd49hJBw6zcfjCuyAsJp_KKJIi6_wRqo=.9eb79ea1-09a0-4546-a3a3-066d6dd6c113@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
 <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
 <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>
 <f_IVM6Xaku2Dd49hJBw6zcfjCuyAsJp_KKJIi6_wRqo=.9eb79ea1-09a0-4546-a3a3-066d6dd6c113@github.com>
Message-ID: <ekyWbnSIG4DOI8fRoqEnW-gI0tjyohDY7LUfRkBV4Pw=.e37709b7-c680-4334-87e4-b645c600eeb5@github.com>

On Mon, 17 Mar 2025 15:01:10 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Looks like this variable is misspelled (missing "S").
>> 
>> DEPS := $(STATIC_LIB_FILE), \
>> 
>> Also note that by default log level INFO is not printed. You would need to run the build with `make LOG=info` to see the message.
>
> Ups, thank you for giving me the 'S'. But nevertheless if I make with
> `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list

I did not get the SetupExecute function, even if I strip it down to a simple example

$(eval $(call SetupExecute, generate_export_list, \
    INFO := Generating export list for static libs, \
    DEPS := /path/libjli.a, \
    OUTPUT_FILE := /path/libjli.a.exp, \
    COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | $(SORT) -u >$$@, \
))

$(java): $(STATIC_LIB_FILES) /path/libjli.a.exp

I still get
`gmake[3]: *** No rule to make target '/path/libjli.a.exp', needed by '/path2/java'.  Stop.
`
Why does make not recognize, that the rule is in my
 `call SetupExecute, generate_export_list,`
macro?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000736109

From shade at openjdk.org  Tue Mar 18 10:52:26 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Mar 2025 10:52:26 GMT
Subject: RFR: 8348829: Remove ObjectMonitor perf counters [v3]
In-Reply-To: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
References: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
Message-ID: <fHJett6TXtqhUAmCCtE8Iv8Zlz0rFF0Xp5D1ObHYYVg=.e77fe610-4093-4452-a838-7a9d1b0b382b@github.com>

> See bug for more discussion. I believe these counters are useless and come with more trouble than their worth.

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8348829-remove-om-counters
 - Merge branch 'master' into JDK-8348829-remove-om-counters
 - Counters removal

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

Changes: https://git.openjdk.org/jdk/pull/23326/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23326&range=02
  Stats: 116 lines in 4 files changed: 0 ins; 116 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23326/head:pull/23326

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

From jsjolen at openjdk.org  Tue Mar 18 10:58:19 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 18 Mar 2025 10:58:19 GMT
Subject: Withdrawn: 8342504: Remove NMT header and footer canaries
In-Reply-To: <NVr0MyQvhl3UdAhSZlmUVynN2qpkzOPUDRLlIS0cflY=.b9ebb7e4-0a5e-44c9-9cc1-ef2bd2255006@github.com>
References: <NVr0MyQvhl3UdAhSZlmUVynN2qpkzOPUDRLlIS0cflY=.b9ebb7e4-0a5e-44c9-9cc1-ef2bd2255006@github.com>
Message-ID: <iXTZQa7qPKFTPnvJUC_eY1eGTplRQnRJq3lqnCFzy4w=.0cfb20f6-edd3-4bbc-bb32-68e8caac2bf7@github.com>

On Thu, 17 Oct 2024 10:04:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Today NMT has two canaries: A header and a footer canary. These enable mainly two things:
> 
> 1. For NMT to aid in describing a pointer
> 2. A basic form of out-of-bounds protection
> 
> With the introduction of UBSan and Asan into OpenJDK we have gained stronger tools for this sort of analysis, without requiring NMT to be activated. Therefore, I believe that point 2 is no longer something that NMT needs to support. For point number one, we will unfortunately be losing this ability.
> 
> I want to delete these canaries to open up a few free bytes. These can allow us to have "practically unlimited" (4 bytes) of memory tags.
> 
> tier1-tier2 tests succeeded.
> 
> I am awaiting discussion on the Hotspot-dev mailing list, but keeping this PR open for review.

This pull request has been closed without being integrated.

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

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

From shade at openjdk.org  Tue Mar 18 11:42:15 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Mar 2025 11:42:15 GMT
Subject: RFR: 8348829: Remove ObjectMonitor perf counters [v3]
In-Reply-To: <fHJett6TXtqhUAmCCtE8Iv8Zlz0rFF0Xp5D1ObHYYVg=.e77fe610-4093-4452-a838-7a9d1b0b382b@github.com>
References: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
 <fHJett6TXtqhUAmCCtE8Iv8Zlz0rFF0Xp5D1ObHYYVg=.e77fe610-4093-4452-a838-7a9d1b0b382b@github.com>
Message-ID: <THqfsJzbZ8Jon4Mmlrn-OnB5Q4KxhEFa1gjTF4raQ6I=.c7ec27ce-e5b4-4ceb-89e4-aad23be0ecf6@github.com>

On Tue, 18 Mar 2025 10:52:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for more discussion. I believe these counters are useless and come with more trouble than their worth.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8348829-remove-om-counters
>  - Merge branch 'master' into JDK-8348829-remove-om-counters
>  - Counters removal

Progress: Remerged after recent updates to OM and JFR events. Found another gap: [JDK-8352256](https://bugs.openjdk.org/browse/JDK-8352256) -- I'll handle that first.

Meanwhile, CSR is updated, and [JDK-8349549](https://bugs.openjdk.org/browse/JDK-8349549) is the release note for this work.

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

PR Comment: https://git.openjdk.org/jdk/pull/23326#issuecomment-2732899830

From ihse at openjdk.org  Tue Mar 18 11:47:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 11:47:12 GMT
Subject: RFR: 8352084: Add more test code in TestSetupAOT.java [v4]
In-Reply-To: <oOg8vrDznJaZjVqNQB8aE4BSDo9qeWOy8gaw6qjHXPc=.6bb53638-a9c6-4e1d-b423-b7a60dd17710@github.com>
References: <LOscj-aAxqdxNJVNXVw6sDEfDQ9YZeF_qRn8VQRIvRc=.277ba64c-a1e5-4e3b-b745-fb97f29a4e7c@github.com>
 <oOg8vrDznJaZjVqNQB8aE4BSDo9qeWOy8gaw6qjHXPc=.6bb53638-a9c6-4e1d-b423-b7a60dd17710@github.com>
Message-ID: <FsHrrENqIiaHCawif0CrJmku4orII7m_K4WByvDYjf0=.b08a0e23-8733-4c07-93cd-3815d330736a@github.com>

On Mon, 17 Mar 2025 16:35:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I modified TestSetupAOT.java to exercise more functionalities in the JDK so that we can have a more substantial AOT cache when running tests with `AOT_JDK=true`. E.g:
>> 
>> 
>> make test JTREG=AOT_JDK=true \
>>     TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
>> 
>> 
>> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125 resolved indies
>> After:  the generated AOT cache is about 34 MB, with 4703 classes and 912 resolved indies
>> 
>> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have the label `.*aot.jdkcache.*`
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @erikj79 comments

make/RunTests.gmk line 757:

> 755: 	$$(call LogWarn, AOT: Create cache configuration) \
> 756: 	$$(call ExecuteWithLog, $$($1_AOT_JDK_OUTPUT_DIR), ( \
> 757:             cd $$($1_AOT_JDK_OUTPUT_DIR); \

@iklam I missed commenting on both this and the prior PR that introduced this function, but if you go back and modify this function again, please use `&&` instead of `;` to separate shell commands. That will chain them so that if the first one fails, the rest will not be executed. (We are setting the `-e` flag so the current code should have the same behavior, but writing `&&` makes it explicit for the reader, and is the style we have been adopting elsewhere in the build system.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24067#discussion_r2000860852

From shade at openjdk.org  Tue Mar 18 11:49:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Mar 2025 11:49:09 GMT
Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event
 notification path
Message-ID: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>

Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `jdk_jfr`

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/24097/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24097&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352256
  Stats: 26 lines in 3 files changed: 16 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24097/head:pull/24097

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

From coleenp at openjdk.org  Tue Mar 18 12:05:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 18 Mar 2025 12:05:06 GMT
Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event
 notification path
In-Reply-To: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
Message-ID: <NVqIGJKQ01a6iEM7Gwp6AE_QZPDH56Nbr-QOpkX9XMc=.03376671-37c5-42f5-be25-b71ecb08fc55@github.com>

On Tue, 18 Mar 2025 11:42:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

This looks good.  At one point, because of this lack of encapsulation, I wanted us to get rid of quick_notify because I didn't think it was quicker.  This improves the encapsulation too and we can figure out if it's useful later.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24097#pullrequestreview-2694257790

From ihse at openjdk.org  Tue Mar 18 12:12:13 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 12:12:13 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <VFAbug4SzdYGjO_SeLsr2OGWch5d7lQfEfSMXNp31do=.365c784a-93d4-4c39-85ed-548e24fc7984@github.com>

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

make/StaticLibs.gmk line 112:

> 110: $(STATIC_LIB_EXPORT_FILES): $(STATIC_LIB_FILES)
> 111: 	$(AR) $(ARFLAGS) -w $(patsubst %.exp, %, $@) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | sort -u >$@
> 112: #$(eval $(call SetupExecute, generate_export_list, \

I think there are multiple issues at hand here.

1) There is a current bug in SetupExecute that requires you to execute any command with redirection in a subshell, that is, you need to wrap the COMMAND in `(` ... `)`.

2) STATIC_LIB_EXPORT_FILES is not a single file, it is a list of file. So what you have written above is not a single recipe, it is a multi-file recipe template. But it's weird, it will evaluate to like:
libjvm.so.exp libjava.so.exp libjli.so.exp: libjvm.so libjava.so libjli.so
which makes no sense, since you do not need to have a dependency to  libjava.so libjli.so for libjvm.so.exp.

What you really want is to have a single rule per library that creates the corresponding exp file for that library, and which is dependent only on that library.

Or, possibly, you can just concatenate the export of all libraries into a single file. It will make the final linker command line simpler, since you would only need a single `-Wl,-bE:<the export file>`, but it is potentially worse for an incremental rebuild, since all native libraries need to be re-scanned for exported functions.

My preferred solution would to make this explicit by creating a loop over STATIC_LIB_FILES, and doing a SetupExecute for each such lib. Then you can get it down to something like:

$(foreach lib, $(STATIC_LIB_FILES), \
  $(eval $(call SetupExecute, generate_export_list_$(lib),
      INFO := Generating export list for $(lib), \
      DEPS :=  $(lib), \
      OUTPUT_FILE := $(lib).exp, \
      COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | sort -u > $(lib).exp ), \
  ) \
  $(eval STATIC_LIB_EXPORT_FILES += $(lib).exp) \
)

make/StaticLibs.gmk line 136:

> 134: ))
> 135: 
> 136: $(java): $(STATIC_LIB_FILES) $(if $(call isTargetOs, aix), $(STATIC_LIB_EXPORT_FILES))

This is just clunky. Leave the original line, and add:

ifeq ($(call isTargetOs, aix), true)
  $(java): $(STATIC_LIB_EXPORT_FILES)
endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000901430
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000904229

From ihse at openjdk.org  Tue Mar 18 12:15:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 18 Mar 2025 12:15:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <ekyWbnSIG4DOI8fRoqEnW-gI0tjyohDY7LUfRkBV4Pw=.e37709b7-c680-4334-87e4-b645c600eeb5@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <PAn4gofspUjggpw1GVIuTTx4vjPipj6SsEExGCTL3J0=.11327593-a3dd-4a68-aeb5-7e415063a859@github.com>
 <PWWdL4SxpdnlYLLK16JIMok6Q1ZkpvrXXuGt2j2EEFg=.e05cd719-b148-438a-8ef7-71e5af25bb2a@github.com>
 <O-y9kINZE5SSF7IOKgzgRgt1FjNruBXbCuCyvIO1jy0=.4bae8b73-0f8b-42f2-a0d1-b0d52ba65eac@github.com>
 <r8pBzu1NfgRrIac0QwYhzKOmvf96EDzEk5oBfsUHmzQ=.0f593544-2bbd-44c7-be75-76f718e5ac84@github.com>
 <f_IVM6Xaku2Dd49hJBw6zcfjCuyAsJp_KKJIi6_wRqo=.9eb79ea1-09a0-4546-a3a3-066d6dd6c113@github.com>
 <ekyWbnSIG4DOI8fRoqEnW-gI0tjyohDY7LUfRkBV4Pw=.e37709b7-c680-4334-87e4-b645c600eeb5@github.com>
Message-ID: <SQgrvqJ1O64cqR7aL_pXoimBpmB2Yy2dSwCz_gc0_qk=.a5eaf8ff-02a5-48d2-81da-b737cb8ef95d@github.com>

On Tue, 18 Mar 2025 10:44:46 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Ups, thank you for giving me the 'S'. But nevertheless if I make with
>> `make all LOG=info` an `$(info generate_export_list: $(generate_export_list))` still shows an empty list
>
> I did not get the SetupExecute to function, even if I strip it down to a simple example
> 
> $(eval $(call SetupExecute, generate_export_list, \
>     INFO := Generating export list for static libs, \
>     DEPS := /path/libjli.a, \
>     OUTPUT_FILE := /path/libjli.a.exp, \
>     COMMAND := $(AR) $(ARFLAGS) -w $$(patsubst %.exp, %, $$@) | $(GREP) -v '^.' | $(AWK) '{print $$$$1}' | $(SORT) -u >$$@, \
> ))
> 
> $(java): $(STATIC_LIB_FILES) /path/libjli.a.exp
> 
> I still get
> `gmake[3]: *** No rule to make target '/path/libjli.a.exp', needed by '/path2/java'.  Stop.
> `
> Why does make not recognize, that the rule is in my
>  `call SetupExecute, generate_export_list,`
> macro?

This is likely due to the missing subshell. There is an enhancement filed to fix this automatically but it has unfortunately not been prioritized: https://bugs.openjdk.org/browse/JDK-8233115

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2000909674

From fbredberg at openjdk.org  Tue Mar 18 13:37:45 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 18 Mar 2025 13:37:45 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire()
Message-ID: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>

This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 

It has passed tier1-tier8 tests.

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

Commit messages:
 - Fixed two typos, and moved one assert()
 - 8351655: Optimize ObjectMonitor::unlink_after_acquire()

Changes: https://git.openjdk.org/jdk/pull/24078/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24078&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351655
  Stats: 78 lines in 2 files changed: 56 ins; 14 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24078/head:pull/24078

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

From pchilanomate at openjdk.org  Tue Mar 18 13:41:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 18 Mar 2025 13:41:11 GMT
Subject: RFR: 8352178: Add precondition in Handshake::execute to prevent
 deadlock [v2]
In-Reply-To: <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
Message-ID: <7BZhsMLgKqPUkxaAuFfx3IbO_5mGMJZgTgmzJ5jgo6U=.4de59921-fa6c-4fad-a38f-88eb76d736b3@github.com>

On Tue, 18 Mar 2025 08:48:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
>> All existing callsites satisfy this precondition already.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/handshake.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/share/runtime/handshake.cpp line 359:

> 357:   // deadlock.
> 358:   assert(!current_thread->is_suspendible_thread(), "precondition");
> 359:   assert(!current_thread->is_indirectly_suspendible_thread(), "precondition");

Why not move the asserts to VMThread::execute() to cover any operation, not just VM_HandshakeAllThreads?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24088#discussion_r2001072591

From azafari at openjdk.org  Tue Mar 18 14:44:07 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Mar 2025 14:44:07 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v2]
In-Reply-To: <xh2gQdozXh0olqvcgHWxKGnMdqUadtqU-TbuGa2Pmxc=.051caa15-c714-48ad-9e9c-ece8d686bbf1@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <nuu6I-NYUKM2ktljEpZ5WgkBivjJTNaKanI8noUKRNo=.7f8c18bf-d999-44d3-83d4-6409c6433d43@github.com>
 <SSi4YHEnmyH8Nmy8ukLKxnOpmmwJ7jeE2LM5YsjEKM0=.fbbf077b-d112-4f93-bd59-d74b99dc9b7a@github.com>
 <xh2gQdozXh0olqvcgHWxKGnMdqUadtqU-TbuGa2Pmxc=.051caa15-c714-48ad-9e9c-ece8d686bbf1@github.com>
Message-ID: <BKdTQPotbo8sE_zqRpRBU_ayO_TafYpMDNBTa2pW1NE=.59c3103e-6724-482d-b9c8-a28e0cdda247@github.com>

On Tue, 18 Mar 2025 10:04:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> We need a better definition of what is supposed to happen in these cases

It depends what we want to print in the report. Currently it is like this:

[A-B] reserved from 
  [mem address] function_1
  [mem address] function_2
     [X-Y] committed from 
        [mem address] function_3
        [mem address] function_4 

which shows the stack for 'reserved region' only once. Then, for every sub-region inside that it shows the committed regions with their stacks. IOW, not all the commits have 'reserved'-stack.

We can define a new report that would be like this:

Region [A-X], Reserved , mtXXX, stack_1
Region [X-Y], Reserved and Committed, stack_2
Region [Y-B], Reserved , mtXXX, stack_1

or something similar. 

Which form of output do we want to have in the report?

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

PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2733507229

From azafari at openjdk.org  Tue Mar 18 14:49:12 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Mar 2025 14:49:12 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v3]
In-Reply-To: <2_es29DUqfL80VeGUDoCVehTDmGaLtW3PflzXXeA5Xc=.3104544b-a4d4-40d5-95bd-5a173147e83f@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <2_es29DUqfL80VeGUDoCVehTDmGaLtW3PflzXXeA5Xc=.3104544b-a4d4-40d5-95bd-5a173147e83f@github.com>
Message-ID: <IQRXgeNQjO3YSoCvxo4za3fDwXFKUYlJvsYZQn94l9I=.e3f75d72-fdfc-4916-a49b-dd8cb06a62dd@github.com>

On Tue, 18 Mar 2025 09:20:59 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied.

We should also re-think about the uncommit stacks. What is the expected?

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

PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2733522388

From ayang at openjdk.org  Tue Mar 18 14:55:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Mar 2025 14:55:12 GMT
Subject: RFR: 8352178: Add precondition in VMThread::execute to prevent
 deadlock [v3]
In-Reply-To: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
Message-ID: <hNkwh4P3WaznOCE9m6f0nM53gW3XPOnX_ZSZjnex7Yg=.1e55b089-ba91-4e4c-89f8-454c687cce2a@github.com>

> Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
> All existing callsites satisfy this precondition already.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24088/files
  - new: https://git.openjdk.org/jdk/pull/24088/files/7480c141..3d727bca

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

  Stats: 17 lines in 2 files changed: 7 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24088/head:pull/24088

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

From ayang at openjdk.org  Tue Mar 18 14:55:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Mar 2025 14:55:14 GMT
Subject: RFR: 8352178: Add precondition in VMThread::execute to prevent
 deadlock [v2]
In-Reply-To: <7BZhsMLgKqPUkxaAuFfx3IbO_5mGMJZgTgmzJ5jgo6U=.4de59921-fa6c-4fad-a38f-88eb76d736b3@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
 <7BZhsMLgKqPUkxaAuFfx3IbO_5mGMJZgTgmzJ5jgo6U=.4de59921-fa6c-4fad-a38f-88eb76d736b3@github.com>
Message-ID: <4pLJyRUOo1Yn2zbXkIFjk_CvULVqKebUi6Ao2aOVaRI=.7069a9d1-1f3e-4ddd-b94f-2269e13fd63e@github.com>

On Tue, 18 Mar 2025 13:38:01 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/runtime/handshake.cpp
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/runtime/handshake.cpp line 359:
> 
>> 357:   // deadlock.
>> 358:   assert(!current_thread->is_suspendible_thread(), "precondition");
>> 359:   assert(!current_thread->is_indirectly_suspendible_thread(), "precondition");
> 
> Why not move the asserts to VMThread::execute() to cover any operation, not just VM_HandshakeAllThreads?

Moved to `VMThread::execute` and edited the title.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24088#discussion_r2001241626

From jkern at openjdk.org  Tue Mar 18 16:18:52 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 16:18:52 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v2]
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <fhpXOopQR_7IjqVcK6H0DdpeeFVf_wAS48NzS_hbIBU=.a726fb32-a173-4680-a3f0-19da5670bacf@github.com>

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  following Magnus proposals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/48668be6..6e76f114

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

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

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

From jkern at openjdk.org  Tue Mar 18 16:21:14 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 18 Mar 2025 16:21:14 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <IHrNDLGrQ5s-8yrsiXRmqLOyo6K9RuSE_5AXkfgDSx8=.ce6b3994-d912-4ddf-b654-6e7f5e6cc6d7@github.com>

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

I applied all of magnus proposals, but I still get
`gmake[3]: *** No rule to make target '/static_libs/jdk/build/aix-ppc64-server-fastdebug/support/native/java.base/libverify/static/libverify.a.exp', needed by '/static_libs/jdk/build/aix-ppc64-server-fastdebug/support/static-native/launcher/java'.  Stop.`

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

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2733873645

From shade at openjdk.org  Tue Mar 18 17:47:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Mar 2025 17:47:12 GMT
Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event
 notification path
In-Reply-To: <NVqIGJKQ01a6iEM7Gwp6AE_QZPDH56Nbr-QOpkX9XMc=.03376671-37c5-42f5-be25-b71ecb08fc55@github.com>
References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
 <NVqIGJKQ01a6iEM7Gwp6AE_QZPDH56Nbr-QOpkX9XMc=.03376671-37c5-42f5-be25-b71ecb08fc55@github.com>
Message-ID: <oneTN1KTFtRQJcJau1Zn8DgGP1OMnxZIMLs6AtfWNYw=.12f06362-22fe-45cd-8c06-48c53fa557d1@github.com>

On Tue, 18 Mar 2025 12:02:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks good. At one point, because of this lack of encapsulation, I wanted us to get rid of quick_notify because I didn't think it was quicker. This improves the encapsulation too and we can figure out if it's useful later.

Yeah, I wondered about these "quick" functions myself when doing this. I guess there is a papercut performance optimization for not re-checking the owner and waitset, which is why I opted to do `ObjectMonitor::quick_*` entries that bypass those checks as well. But I am doubtful those checks matter.

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

PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2734186068

From amenkov at openjdk.org  Tue Mar 18 17:57:14 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 17:57:14 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
In-Reply-To: <UvUBCvW0o8r0s2bHJc_Si26P33GGKQjP70cYrITL_18=.c90c355f-f1da-4353-af85-90e40b553c41@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
 <DXm4w2it939kzDfA5g4fmOK4WA41OTx8NGB8Mdn4QF0=.01f4affa-d23a-4780-97a4-22b6da240bfd@github.com>
 <UvUBCvW0o8r0s2bHJc_Si26P33GGKQjP70cYrITL_18=.c90c355f-f1da-4353-af85-90e40b553c41@github.com>
Message-ID: <FemDN4NorXIndhSaKNjC9bakMegrYAv0oV-IjC6DMjE=.a5352840-9806-4ccf-90e5-e49c35780839@github.com>

On Tue, 18 Mar 2025 07:40:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Any idea on why things are taking so long? Is the pipe undersized?

I don't think this in a buffer issue.
One problem I see is self-attach. FlushFileBuffers waits until all data is read by the client, but is we are at safepoint, the client cannot read the data

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

PR Comment: https://git.openjdk.org/jdk/pull/24091#issuecomment-2734221965

From amenkov at openjdk.org  Tue Mar 18 17:57:15 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 17:57:15 GMT
Subject: Integrated: 8352180: AttachListenerThread causes many tests to timeout
 on Windows
In-Reply-To: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
Message-ID: <_b3Qh7NZHKhwUtBtO_MAsMEh4JAkrWPHRaeVtmVsS0Q=.2b65d38f-628b-4fc0-8574-93cd955b1b90@github.com>

On Tue, 18 Mar 2025 00:16:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes regression from JDK-8319055 (see David's evaluation in the CR description)
> 
> Testing: sanity tier1;
>   tier6, tier7 - in progress

This pull request has now been integrated.

Changeset: 53c5b93c
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53c5b93ca528ec21628c2b03dd6064e02f7ac408
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8352180: AttachListenerThread causes many tests to timeout on Windows

Reviewed-by: dholmes, alanb

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

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

From amenkov at openjdk.org  Tue Mar 18 18:02:12 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 18:02:12 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
Message-ID: <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>

On Tue, 18 Mar 2025 09:21:42 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> LGTM. Thanks for fixing it so quickly! Should `reply_writer` get implemented? We could file an RFE.

Yes, AIX implementation needs update (it does not support attach API v2 and streaming output). I was going to file RFE after the code is stabilized (AIX implementation is basically the same as posix implementation)

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

PR Comment: https://git.openjdk.org/jdk/pull/24089#issuecomment-2734237925

From amenkov at openjdk.org  Tue Mar 18 18:02:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 18:02:13 GMT
Subject: Integrated: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
Message-ID: <MpPs7pw_KxIE4BdpjAj2QPK91M5lioM65e64g6x2UuY=.85abcb7a-9230-44b7-bef1-c9ac0fd3e360@github.com>

On Mon, 17 Mar 2025 20:35:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes crash on AIX after JDK-8319055
> Can't test it on AIX, but the reason is obvious from the stack trace.
> AIX is the only platform that does not implement `reply_writer` yet
> 
> Testing: sanity tier1

This pull request has now been integrated.

Changeset: a3540be5
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3540be502ef2f93c0fdc3fb2496c29ae7c8b041
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8352163: [AIX] SIGILL in AttachOperation::ReplyWriter::write_fully after 8319055

Reviewed-by: dholmes, mdoerr

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

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

From gziemski at openjdk.org  Tue Mar 18 18:18:51 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 18 Mar 2025 18:18:51 GMT
Subject: RFR: 8301404: Replace os::malloc with os::realloc,
 so we only have 1 code path
Message-ID: <-wGc_naQpZeZA9rOjHoui1owsSOzdRmasEvq6xNkh8E=.60b7b9b2-f9ca-49a7-9136-b5a4062dfc34@github.com>

This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from https://github.com/openjdk/jdk/pull/23786):

proposed:


time:72,642,827[ns]
[samples:807,804] [NMT headers:382,064]
[malloc#:588,703] [realloc#:12,462] [free#:206,639]
memory requested:57,274,288 bytes, allocated:69,004,800 bytes
malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]


existing code:


time:73,085,446[ns]
[samples:807,804] [NMT headers:382,064]
[malloc#:588,703] [realloc#:12,462] [free#:206,639]
memory requested:57,274,288 bytes, allocated:69,004,800 bytes
malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]


Note: the NMTBenchmark reports `realloc(nullptr)` as `mallocs()`, which is why both versions show the same count for `mallocs/reallocs`.

The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).

This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).

To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

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

Commit messages:
 - revert pre-init cache
 - check for NMT, rename offset to chunk
 - fix memset
 - fix memset
 - fix memset
 - cleanup
 - factor out common malloc/realloc code
 - fix build
 - fix build
 - fix build
 - ... and 2 more: https://git.openjdk.org/jdk/compare/da2b4f07...cec25b45

Changes: https://git.openjdk.org/jdk/pull/23994/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23994&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301404
  Stats: 112 lines in 2 files changed: 28 ins; 43 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/23994.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23994/head:pull/23994

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

From gziemski at openjdk.org  Tue Mar 18 18:18:52 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 18 Mar 2025 18:18:52 GMT
Subject: RFR: 8301404: Replace os::malloc with os::realloc,
 so we only have 1 code path
In-Reply-To: <-wGc_naQpZeZA9rOjHoui1owsSOzdRmasEvq6xNkh8E=.60b7b9b2-f9ca-49a7-9136-b5a4062dfc34@github.com>
References: <-wGc_naQpZeZA9rOjHoui1owsSOzdRmasEvq6xNkh8E=.60b7b9b2-f9ca-49a7-9136-b5a4062dfc34@github.com>
Message-ID: <-uXmEYJQaj9UIyh1JIs7NMMMI9bYNUaX2bNS5DZH6Vo=.ba447066-4726-4257-a19a-374e5861b4a7@github.com>

On Tue, 11 Mar 2025 18:33:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from https://github.com/openjdk/jdk/pull/23786):
> 
> proposed:
> 
> 
> time:72,642,827[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> 
> 
> existing code:
> 
> 
> time:73,085,446[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> 
> 
> Note: the NMTBenchmark reports `realloc(nullptr)` as `mallocs()`, which is why both versions show the same count for `mallocs/reallocs`.
> 
> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
> 
> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
> 
> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

@tstuefe Thomas, I now have performance numbers, which seem to indicate no speed regression. What do you think? Is it worth it in your opinion?

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

PR Comment: https://git.openjdk.org/jdk/pull/23994#issuecomment-2725240376

From jiangli at openjdk.org  Tue Mar 18 19:02:18 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Mar 2025 19:02:18 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
Message-ID: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>

Please review this PR that adds `@requires !jdk.static` to tests, thanks.

- runtime/StackGap/TestStackGap.java
- runtime/StackGuardPages/TestStackGuardPages.java
- runtime/TLS/TestTLS.java
- runtime/jni/daemonDestroy/TestDaemonDestroy.java
- runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
- jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
- jdk/jni/nullCaller/NullCallerTest.java
- jdk/tools/launcher/JniInvocationTest.java

These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.

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

Commit messages:
 - Skip tests using native executable with libjvm.so/libjli.so dependencies on static JDK.

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

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

From lmesnik at openjdk.org  Tue Mar 18 19:24:07 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 18 Mar 2025 19:24:07 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
Message-ID: <kGaJKRN4KgqzPaDcdP4mqlcNPlCUuqwsPb9ke07loP4=.796a12b7-e54e-4fdf-b4ee-b79567b7e646@github.com>

On Sun, 16 Mar 2025 02:54:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR tries to cut down the use of `WhiteBox` in the HotSpot test cases. It modifies `VMProps` to save the set of VM properties into a file called "vm.properties" under Jtreg's work directory. The new API `jdk.test.lib.VMPropsGetter` loads the properties from this file to pass onto individual test cases.
> 
> See `getJtregWorkDir()` for the code that figures out the work directory. It assumes that `VMProps` and all test cases are always executed under
> 
> - `workDir/scratch/` ; or
> - `workDir/scratch/[0-9]+/` 
> 
> This is probably not the right thing to do. I would be better for Jtreg to pass the location of the work directory to the test cases, with a command-line options like `-Djtreg.work.dir=<dir>`.
> 
> To show the benefit of this PR, I modified a few test cases to remove their use of WhiteBox.

Changes requested by lmesnik (Reviewer).

test/lib/jdk/test/lib/VMPropsGetter.java line 53:

> 51:     }
> 52: 
> 53:     static Properties init() {

That is not going to work correctly  for any test that use specific option, saying 
@run main/othervm -XX:+UseCompactObjectHeader Test
will return true for 
`if ("true".equals(VMPropsGetter.get("vm.cds.sharing.enabled"))) {`
because CDS are enabled for VMProps but false for 
`if (wb.isSharingEnabled()) {`
because for this particular test the CDS is not supported.

Also, anything that is executed with ProcessTools is going to have wrong information.

I think it is not the best way. The fix proposed in the https://bugs.openjdk.org/browse/CODETOOLS-7903975
is going to have the same issue.

The VM specific properties should be read only from current VM directly.

I f you want to simplify WB usage, I propose better to rewrite WB APIto  internal JDK test module available for all tests.  
The WB might be implemented like
`module jdk.jfr/jdk.jfr.internal.test` with` jdk.jfr.internal.test.WhiteBox`
I think internal module jdk.internal.test could be implemented to support WB access to JDK.  Additionally it could be protected by VM flags to make it is more clear that shouldn't be used in production.

The another alternative is to add tag `@wbEnabled` to jtreg and teach it to run jtreg run tests with WB API enabled. I can't be added to the TEST.ROOT to whole hotspot tests.

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

PR Review: https://git.openjdk.org/jdk/pull/24071#pullrequestreview-2691487031
PR Review Comment: https://git.openjdk.org/jdk/pull/24071#discussion_r1999302346

From mdoerr at openjdk.org  Tue Mar 18 21:59:13 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Mar 2025 21:59:13 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
 <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>
Message-ID: <kQ_qsKI8vA9SEpo_CSw_ikBXX3lzzgtVhOSPmRoCwJc=.5185511e-9523-441b-8dd1-f350981d5d3f@github.com>

On Tue, 18 Mar 2025 17:57:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Yes, AIX implementation needs update (it does not support attach API v2 and streaming output). I was going to file RFE after the code is stabilized (AIX implementation is basically the same as posix implementation)

@alexmenkov: The test serviceability/attach/AttachAPIv2/StreamingOutputTest.java is failing, now. So we need to address that. Should we problem-list it or better implement it now?

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

PR Comment: https://git.openjdk.org/jdk/pull/24089#issuecomment-2734831417

From amenkov at openjdk.org  Tue Mar 18 22:22:21 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 22:22:21 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <kQ_qsKI8vA9SEpo_CSw_ikBXX3lzzgtVhOSPmRoCwJc=.5185511e-9523-441b-8dd1-f350981d5d3f@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
 <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>
 <kQ_qsKI8vA9SEpo_CSw_ikBXX3lzzgtVhOSPmRoCwJc=.5185511e-9523-441b-8dd1-f350981d5d3f@github.com>
Message-ID: <4eJoZRoVRJY_DoMzGO496dvrWmgkvatgbwMMV0L3AqI=.fb2c028d-bb13-4415-b372-6c63973f1a1d@github.com>

On Tue, 18 Mar 2025 21:56:43 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > Yes, AIX implementation needs update (it does not support attach API v2 and streaming output). I was going to file RFE after the code is stabilized (AIX implementation is basically the same as posix implementation)
> 
> @alexmenkov: The test serviceability/attach/AttachAPIv2/StreamingOutputTest.java is failing, now. So we need to address that. Should we problem-list it or better implement it now?

I think it's simpler to problem-list it on aix for now

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

PR Comment: https://git.openjdk.org/jdk/pull/24089#issuecomment-2734865489

From vlivanov at openjdk.org  Tue Mar 18 23:23:13 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 18 Mar 2025 23:23:13 GMT
Subject: RFR: 8351748: Add class init barrier to AOT-cached Method/Var
 Handles [v2]
In-Reply-To: <UpygeU7Cqcx9ebgfjyoKhTWTNKfOwWc6P6nO3Iyu5-w=.88eab0b0-8b12-45ad-be70-767dbf11bdca@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
 <UpygeU7Cqcx9ebgfjyoKhTWTNKfOwWc6P6nO3Iyu5-w=.88eab0b0-8b12-45ad-be70-767dbf11bdca@github.com>
Message-ID: <HTvxZ6bmwBjTWrQinrxO7TscXBomX92xD4NGWPyK5CY=.599d87ca-d3fb-47f6-be47-d0b1832846af@github.com>

On Tue, 18 Mar 2025 03:55:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Whenever we store a MethodHandle in the AOT cache, we need to make sure that the class of this method is aot-initialized. Otherwise, the JVM might execute a BSM without first initializing the class of this BSM.
>> 
>> Please see the bug report for detail analysis.
>> 
>> I also fixed a problem in related logging code.
>
> Ioi Lam 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:
> 
>  - clean up
>  - Merge branch 'master' into 8351748-classes-of-cached-method-handles-should-be-aot-inited
>  - Added CDS::needsClassInitBarrier() for adding init barriers to cached Method/Var Handles
>  - Merge branch 'master' into 8351748-classes-of-cached-method-handles-should-be-aot-inited
>  - Experiment: always include init barriers in cached MethodHandle/VarHandle
>  - 8351748: Classes of method handles in the AOT cache should be AOT-initialized

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24004#pullrequestreview-2696511107

From peter.kessler at os.amperecomputing.com  Tue Mar 18 23:58:39 2025
From: peter.kessler at os.amperecomputing.com (Peter Kessler OS)
Date: Tue, 18 Mar 2025 23:58:39 +0000
Subject: aarch64: Rationalize DEFAULT_PADDING_SIZE with ContendedPaddingWidth
Message-ID: <SJ0PR01MB74149503DFD2C77F2CE450C4D4DE2@SJ0PR01MB7414.prod.exchangelabs.com>

DEFAULT_PADDING_SIZE specifies the padding that should be put before a C++ field to avoid false sharing.  For aarch64 it is currently set to the size of a cache line.[1]  For aarch64 the size of a cache is defined to be 64 bytes.[2]

Similarly, ContendedPaddingWidth specifies the padding that should be put before a Java field to avoid false sharing.  For all platforms that is set to 128 bytes, but it can be changed from the java command line.[3]

aarch64 has the same potential interaction with pre-fetchers as described for the x86.[4]  That is, a pre-fetcher may fetch the _next cache line_ after a requested address.  If that next cache line contains the contended field, then the core that wants to atomically update the field needs to (re)negotiate for exclusive access to the cache line with the field.  Padding a contended field into _two_ cache lines avoids this false sharing.

I would like to rationalize the padding for aarch64 C++ fields with the padding for Java fields.  The change is easy: double the size of DEFAULT_PADDING_SIZE in globalDefinitions_aarch64.hpp.  But I am curious why the difference exists for aarch64 and not for x86, and if there implications that should be considered before submitting a pull request.  Increasing the padding will make C++ data structures with padded fields take more space, possibly causing more page faults, etc.   But avoiding false sharing may improve the performance of C++ atomic operations, lowering latency in places where it might be important.

I have built jdk-25+14 with DEFAULT_PADDING_SIZE defined as 128, and things work.[5]  I am unable to show significant performance changes.  Can someone recommend tests where false sharing of C++ fields in the JVM might a difference?  Or can I submit a pull request just because it seems silly to have different padding for C++ fields and Java fields on aarch64?

                                                ... peter

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L49
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L46
[3] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals.hpp#L813
[4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/globalDefinitions_x86.hpp#L46
[5] I also tried various other sizes of DEFAULT_PADDING_SIZE.  I can report that some uses of padded fields are prepared for DEFAULT_PADDING_SIZE to be 0, but some uses result in compilation errors because they do not use the lovely templates that protect against 0-length C++ arrays.[6]
[6] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/padded.hpp#L67
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250318/cb7c37a5/attachment-0001.htm>

From dholmes at openjdk.org  Wed Mar 19 00:32:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Mar 2025 00:32:06 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
References: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
Message-ID: <CeRmURQz27CabX8VQdUevmm6eht_Pwk2jSC--ke-nR4=.6ff8e073-543c-4bd4-addc-001cc97f41e8@github.com>

On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
> 
> - runtime/StackGap/TestStackGap.java
> - runtime/StackGuardPages/TestStackGuardPages.java
> - runtime/TLS/TestTLS.java
> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> - jdk/jni/nullCaller/NullCallerTest.java
> - jdk/tools/launcher/JniInvocationTest.java
> 
> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.

@jianglizhou  shouldn't these native executables be built differently to work with the static JDK? Otherwise how does a user create a native executable that launches the JVM?

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735014436

From jiangli at openjdk.org  Wed Mar 19 01:00:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Mar 2025 01:00:14 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: <CeRmURQz27CabX8VQdUevmm6eht_Pwk2jSC--ke-nR4=.6ff8e073-543c-4bd4-addc-001cc97f41e8@github.com>
References: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
 <CeRmURQz27CabX8VQdUevmm6eht_Pwk2jSC--ke-nR4=.6ff8e073-543c-4bd4-addc-001cc97f41e8@github.com>
Message-ID: <t4Y2b1goLKGRGhojF6v8YT0TriGWnOIf_SakKzGLc2k=.645b2223-0993-4b4f-a14c-4dfcf7081aa5@github.com>

On Wed, 19 Mar 2025 00:29:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @jianglizhou shouldn't these native executables be built differently to work with the static JDK? Otherwise how does a user create a native executable that launches the JVM?

I think it's the case of using customized launcher and we need to implement new tests to cover for the static support. The test needs to build native (testing launcher) executable by statically linking with the needed JDK and VM static libraries. We haven't discussed this topic in the hermetic Java meetings yet. I think some build system work is needed so the JDK/VM static libraries would also be built when creating the test native binaries. We probably want to add a new `test-static-image` for that purpose, so building the existing `test-image` target is not affected and does not require the static libraries. I'll create a new RFE for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735042103

From jiangli at openjdk.org  Wed Mar 19 02:05:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Mar 2025 02:05:09 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
References: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
Message-ID: <O2ZSdA_MILjviB5p75W90aTg4DO9eFLt0HmRyNGRbLM=.5f50a341-a122-410a-8a6e-bd764b6e06b2@github.com>

On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
> 
> - runtime/StackGap/TestStackGap.java
> - runtime/StackGuardPages/TestStackGuardPages.java
> - runtime/TLS/TestTLS.java
> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> - jdk/jni/nullCaller/NullCallerTest.java
> - jdk/tools/launcher/JniInvocationTest.java
> 
> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.

I filed https://bugs.openjdk.org/browse/JDK-8352305.

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735134347

From alanb at openjdk.org  Wed Mar 19 09:23:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 19 Mar 2025 09:23:06 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: <O2ZSdA_MILjviB5p75W90aTg4DO9eFLt0HmRyNGRbLM=.5f50a341-a122-410a-8a6e-bd764b6e06b2@github.com>
References: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
 <O2ZSdA_MILjviB5p75W90aTg4DO9eFLt0HmRyNGRbLM=.5f50a341-a122-410a-8a6e-bd764b6e06b2@github.com>
Message-ID: <-KF_r5JKVAoe-6WdwmLeDrCGtDhtUu6Na4jomJjmYQE=.64a71071-fbfa-450a-b8b3-34e5a1413faf@github.com>

On Wed, 19 Mar 2025 02:02:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
>> 
>> - runtime/StackGap/TestStackGap.java
>> - runtime/StackGuardPages/TestStackGuardPages.java
>> - runtime/TLS/TestTLS.java
>> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
>> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
>> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> - jdk/jni/nullCaller/NullCallerTest.java
>> - jdk/tools/launcher/JniInvocationTest.java
>> 
>> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.
>
> I filed https://bugs.openjdk.org/browse/JDK-8352305.

> @jianglizhou shouldn't these native executables be built differently to work with the static JDK? Otherwise how does a user create a native executable that launches the JVM?

Right now, jlink creating a modular run-time image, can generate a launch script in the image bin directory. If/when support for creating a static image comes then it will generate a native executable that runs the application. Configuration that is provided at launch time may need to be provided at link time. In that world then it's not clear if there is a real need for custom launcher code. As Jiangli says, we haven't discussed this yet, so can't rule anything in or out right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735857307

From mdoerr at openjdk.org  Wed Mar 19 10:03:14 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Mar 2025 10:03:14 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <4eJoZRoVRJY_DoMzGO496dvrWmgkvatgbwMMV0L3AqI=.fb2c028d-bb13-4415-b372-6c63973f1a1d@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
 <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>
 <kQ_qsKI8vA9SEpo_CSw_ikBXX3lzzgtVhOSPmRoCwJc=.5185511e-9523-441b-8dd1-f350981d5d3f@github.com>
 <4eJoZRoVRJY_DoMzGO496dvrWmgkvatgbwMMV0L3AqI=.fb2c028d-bb13-4415-b372-6c63973f1a1d@github.com>
Message-ID: <7-a_AEEfT6p2tMwKNsRDs2rslfuvuPqAa9yfB_d0Mb4=.51c8a1bf-353b-4673-92a1-3847d7dbcec1@github.com>

On Tue, 18 Mar 2025 22:19:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> > > Yes, AIX implementation needs update (it does not support attach API v2 and streaming output). I was going to file RFE after the code is stabilized (AIX implementation is basically the same as posix implementation)
> > 
> > 
> > @alexmenkov: The test serviceability/attach/AttachAPIv2/StreamingOutputTest.java is failing, now. So we need to address that. Should we problem-list it or better implement it now?
> 
> I think it's simpler to problem-list it on aix for now

Thanks! I've filed https://bugs.openjdk.org/browse/JDK-8352392 and a subtask for problem-listing. Feel free to update it or add information. Please let us know when we should start implementing it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24089#issuecomment-2736005354

From tschatzl at openjdk.org  Wed Mar 19 14:32:16 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Mar 2025 14:32:16 GMT
Subject: RFR: 8352178: Add precondition in VMThread::execute to prevent
 deadlock [v3]
In-Reply-To: <hNkwh4P3WaznOCE9m6f0nM53gW3XPOnX_ZSZjnex7Yg=.1e55b089-ba91-4e4c-89f8-454c687cce2a@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <hNkwh4P3WaznOCE9m6f0nM53gW3XPOnX_ZSZjnex7Yg=.1e55b089-ba91-4e4c-89f8-454c687cce2a@github.com>
Message-ID: <10_ptTYJkx1qeSElYBtqMy_3glPrGkAy55XqkwfdMV0=.244cee2c-5a26-4378-be45-64f1a5763b8c@github.com>

On Tue, 18 Mar 2025 14:55:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
>> All existing callsites satisfy this precondition already.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24088#pullrequestreview-2698710505

From tschatzl at openjdk.org  Wed Mar 19 14:35:09 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Mar 2025 14:35:09 GMT
Subject: RFR: 8352178: Add precondition in VMThread::execute to prevent
 deadlock [v2]
In-Reply-To: <3I9v-cKqH_9Vk_3sMqJOqUc-sdZxlaPGZbrhdsB84aI=.9a5924a4-c60c-422f-b07f-0aca795bec3f@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
 <3I9v-cKqH_9Vk_3sMqJOqUc-sdZxlaPGZbrhdsB84aI=.9a5924a4-c60c-422f-b07f-0aca795bec3f@github.com>
Message-ID: <1luumhFrhNuv7oUm9j5B5dppa-Un1rnkBpyEajnPlVs=.539df5dd-6d7e-4a71-91c7-cc52d2865ad5@github.com>

On Tue, 18 Mar 2025 09:12:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks reasonable. Have you caught the deadlock like this anywhere, e.g. in development for some feature?
> 

The deadlock can be reproduced if you e.g. remove one of the `SuspendibleThreadSetLeaver`s in the refinement process in PR#23739. But any other should have the same effect.

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

PR Comment: https://git.openjdk.org/jdk/pull/24088#issuecomment-2736864214

From shipilev at amazon.de  Wed Mar 19 15:58:36 2025
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Wed, 19 Mar 2025 16:58:36 +0100
Subject: aarch64: Rationalize DEFAULT_PADDING_SIZE with
 ContendedPaddingWidth
In-Reply-To: <SJ0PR01MB74149503DFD2C77F2CE450C4D4DE2@SJ0PR01MB7414.prod.exchangelabs.com>
References: <SJ0PR01MB74149503DFD2C77F2CE450C4D4DE2@SJ0PR01MB7414.prod.exchangelabs.com>
Message-ID: <9de497cb-6557-4365-b5e5-2284e8799da1@amazon.de>

Hi,

On 19.03.25 00:58, Peter Kessler OS wrote:
> Similarly, ContendedPaddingWidth specifies the padding that should be put before a Java field to 
> avoid false sharing.? For all platforms that is set to 128 bytes, but it can be changed from the 
> java command line.[3]

ContendedPaddingWidth is a conservative estimate.

Look for the uses of ContendedPaddingWidth, it is overriden by VM as well like this:

   if (FLAG_IS_DEFAULT(ContendedPaddingWidth) && (dcache_line > ContendedPaddingWidth)) {
     ContendedPaddingWidth = dcache_line;
   }

Arguably, we want to drop the `dcache_line > CPW` check and trust the dcache line size?

> I would like to rationalize the padding for aarch64 C++ fields with the padding for Java fields.  
> The change is easy: double the size of DEFAULT_PADDING_SIZE in globalDefinitions_aarch64.hpp.? But I 
> am curious why the difference exists for aarch64 and not for x86, and if there implications that 
> should be considered before submitting a pull request.

Last time we looked at this, we were actually suspecting we should go the other way around: drop 
double padding on x86: https://bugs.openjdk.org/browse/JDK-8321481. But this is arch-specific, so if 
known AArch64 arches are affected by this, it would be interesting to try and double it.

Thanks,
-Aleksey

From coleenp at openjdk.org  Wed Mar 19 18:51:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Mar 2025 18:51:11 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire()
In-Reply-To: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
Message-ID: <14KpMqAOYQIq0HQShaGbm2BJrzDzHc355AL2EQcMHOM=.6819eec4-a3b2-481a-9dd2-5f54ac7f4a85@github.com>

On Mon, 17 Mar 2025 13:11:58 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
> 
> It has passed tier1-tier8 tests.

This looks really good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24078#pullrequestreview-2699698452

From coleenp at openjdk.org  Wed Mar 19 18:53:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 19 Mar 2025 18:53:13 GMT
Subject: RFR: 8347734: Turning off PerfData logging doesn't work
In-Reply-To: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
References: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
Message-ID: <WF-XClhsjKRRWUitdcAgBAMeS5N0WZ6hdT6uWpLAc1Q=.194d9df5-fac6-424e-ac51-1ee0ba404f68@github.com>

On Thu, 13 Mar 2025 15:07:07 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> When PerfData is disabled, the corresponding perfdata variables remain uninitialized. However, under certain conditions, logging may attempt to access these variables, leading to a crash. The existing code turns off the relevant tags using `LogConfiguration::configure_stdout`, but this doesn't modify other outputs. For example, the test `runtime/logging/RedefineClasses.java` crashes with `-XX:-UsePerfData` because it uses an output that isn't stdout.
> 
> To fix this, I've added a new method `LogConfiguration::disable_tags`. Unlike `configure_stdout`, this function iterates over all outputs and disables the specified tags on each. This way, we correctly disable tags across all outputs and longer try and access the uninitialized perfdata variables.

This looks good! Thank you for fixing it.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24036#pullrequestreview-2699705591

From jiangli at openjdk.org  Wed Mar 19 21:24:06 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 19 Mar 2025 21:24:06 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: <-KF_r5JKVAoe-6WdwmLeDrCGtDhtUu6Na4jomJjmYQE=.64a71071-fbfa-450a-b8b3-34e5a1413faf@github.com>
References: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
 <O2ZSdA_MILjviB5p75W90aTg4DO9eFLt0HmRyNGRbLM=.5f50a341-a122-410a-8a6e-bd764b6e06b2@github.com>
 <-KF_r5JKVAoe-6WdwmLeDrCGtDhtUu6Na4jomJjmYQE=.64a71071-fbfa-450a-b8b3-34e5a1413faf@github.com>
Message-ID: <E5_rAaVypkWarBsU8PPi4BVnxmvSjpr3MUOiVoJ1-NA=.eb8b62bd-212f-4b3b-97d2-de8ddc942230@github.com>

On Wed, 19 Mar 2025 09:20:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> can't rule anything in or out right now

+1

@AlanBateman @dholmes-ora Does it look reasonable to not run these tests on static JDK for now?

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2738148828

From iklam at openjdk.org  Wed Mar 19 22:18:34 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Mar 2025 22:18:34 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging
Message-ID: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>

In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.

Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:

https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java

This PR adds a few new classes to simplify the test cases:

Example: build two modular JAR files into `modulePath`


CDSModulePackager modulePackager = new CDSModulePackager(SRC);
modulePath = modulePackager.getOutputDir().toString();

modulePackager.createModularJar("com.foos");
modulePackager.createModularJar("com.needsfoosaddexport",
                                "--add-exports",
                                "com.foos/com.foos.internal=com.needsfoosaddexport");


Example: use modules in training/assembly/production phases


SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
   .classpath(dummyJar)
   .modulepath(modulePath)
   .addVmArgs("--add-modules", "com.needsjdkaddexport",
              "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
   .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
   .setAssemblyChecker((OutputAnalyzer out) -> {
           out.shouldContain("Full module graph = enabled");
        })
    .setProductionChecker((OutputAnalyzer out) -> {
            out.shouldContain("use_full_module_graph = true; java.base");
        })
    .runStaticWorkflow()
    .runAOTWorkflow();

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

Commit messages:
 - added comments
 - Prototype: support --add-exports in CDS FMG

Changes: https://git.openjdk.org/jdk/pull/24122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352435
  Stats: 1130 lines in 7 files changed: 734 ins; 342 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/24122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24122/head:pull/24122

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

From pchilanomate at openjdk.org  Wed Mar 19 22:33:07 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 19 Mar 2025 22:33:07 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire()
In-Reply-To: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
Message-ID: <ztT_Z51EwsSSRjkj3f8fywkK_jGdec0nhoOZVh43eDA=.8f95d807-d28d-45b4-87bd-695b10849fef@github.com>

On Mon, 17 Mar 2025 13:11:58 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
> 
> It has passed tier1-tier8 tests.

Thanks for taking care of this follow up. Looks good to me, just minor comments.

src/hotspot/share/runtime/objectMonitor.cpp line 1265:

> 1263: // entry_list head after the entry_list was last converted into a
> 1264: // doubly linked list.
> 1265: void ObjectMonitor::entry_list_build_dll(JavaThread* current) {

We only call this from unlink_after_acquire() and exit() when we know the list is not empty, so why not assert that here and remove case 1?

src/hotspot/share/runtime/objectMonitor.cpp line 1284:

> 1282:     // We converted the entire entry_list from a singly linked list
> 1283:     // into a doubly linked list. Now we just need to set the tail
> 1284:     // pointer.

This could also be the empty list case so comment could be improved to separate those two cases. No need to change it if we assert list can?t be empty at the beginning.

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

PR Review: https://git.openjdk.org/jdk/pull/24078#pullrequestreview-2700420778
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2004401490
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2004406052

From iklam at openjdk.org  Wed Mar 19 23:03:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Mar 2025 23:03:51 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v2]
In-Reply-To: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
Message-ID: <gC2sHYWT3OwonissrywET7hat7IvvrrDSxQZbNcO2KU=.529bf399-5ad7-461a-aafd-f5375397d7d4@github.com>

> In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.
> 
> Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:
> 
> https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
> 
> This PR adds a few new classes to simplify the test cases:
> 
> Example: build two modular JAR files into `modulePath`
> 
> 
> CDSModulePackager modulePackager = new CDSModulePackager(SRC);
> modulePath = modulePackager.getOutputDir().toString();
> 
> modulePackager.createModularJar("com.foos");
> modulePackager.createModularJar("com.needsfoosaddexport",
>                                 "--add-exports",
>                                 "com.foos/com.foos.internal=com.needsfoosaddexport");
> 
> 
> Example: use modules in training/assembly/production phases
> 
> 
> SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
>    .classpath(dummyJar)
>    .modulepath(modulePath)
>    .addVmArgs("--add-modules", "com.needsjdkaddexport",
>               "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
>    .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
>    .setAssemblyChecker((OutputAnalyzer out) -> {
>            out.shouldContain("Full module graph = enabled");
>         })
>     .setProductionChecker((OutputAnalyzer out) -> {
>             out.shouldContain("use_full_module_graph = true; java.base");
>         })
>     .runStaticWorkflow()
>     .runAOTWorkflow();

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  added comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24122/files
  - new: https://git.openjdk.org/jdk/pull/24122/files/88b4bd58..6a95590b

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

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

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

From dholmes at openjdk.org  Thu Mar 20 02:23:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Mar 2025 02:23:10 GMT
Subject: RFR: 8348829: Remove ObjectMonitor perf counters [v3]
In-Reply-To: <fHJett6TXtqhUAmCCtE8Iv8Zlz0rFF0Xp5D1ObHYYVg=.e77fe610-4093-4452-a838-7a9d1b0b382b@github.com>
References: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
 <fHJett6TXtqhUAmCCtE8Iv8Zlz0rFF0Xp5D1ObHYYVg=.e77fe610-4093-4452-a838-7a9d1b0b382b@github.com>
Message-ID: <SWuOFc_Y0VDFEu6YVHIycvHvO35HS_WWh-QaYbLmUeI=.18c39102-5c82-4c1d-92a6-01cf02c495b1@github.com>

On Tue, 18 Mar 2025 10:52:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for more discussion. I believe these counters are useless and come with more trouble than their worth.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8348829-remove-om-counters
>  - Merge branch 'master' into JDK-8348829-remove-om-counters
>  - Counters removal

Still good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23326#pullrequestreview-2700941632

From sspitsyn at openjdk.org  Thu Mar 20 03:32:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Mar 2025 03:32:32 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v5]
In-Reply-To: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
Message-ID: <E3X7BuedZUri9ZUW6-3WfMAY-3jFtroXKHzoFKXVIKg=.435c85d6-6952-488d-8a79-a51a37b7eb3f@github.com>

> The `get_jvmti_thread_state()` function is called from `JvmtiExport::at_single_stepping_point()`.  It can block for virtual threads. Then the `SingleStep` events can be enabled at that point. The incorrect behavior is that the `SingleStep` events will be posted even though the virtual thread has been suspended with the JVMTI `SuspendThread`, `SuspendThreadList`, or `SuspendAllVirtualThreads`. The fix is to add a suspend point for virtual threads to the `get_jvmti_thread_state()` function.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Serguei Spitsyn 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
 - review: move suspend point from post_single_step() to get_jvmti_thread_state()
 - Merge
 - removed obsolete fragment that was not removed in last update
 - review: re-fixed the issue as initial fix was wrong
 - 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23490/files
  - new: https://git.openjdk.org/jdk/pull/23490/files/2e099aad..94cfbd5f

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

  Stats: 94601 lines in 1889 files changed: 45801 ins; 33402 del; 15398 mod
  Patch: https://git.openjdk.org/jdk/pull/23490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23490/head:pull/23490

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

From dholmes at openjdk.org  Thu Mar 20 05:57:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Mar 2025 05:57:08 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire()
In-Reply-To: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
Message-ID: <Jy8zD0chkshfaPdF1an24AyUltn2NfJmOfYMc7bIblw=.3ac5da38-fecf-449b-b6a5-05f86efef549@github.com>

On Mon, 17 Mar 2025 13:11:58 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
> 
> It has passed tier1-tier8 tests.

Generally okay but a few minor nits - plus Patricio's suggestion.

Thanks

src/hotspot/share/runtime/objectMonitor.cpp line 1256:

> 1254: // pointers and the entry_list_tail pointer. Within the entry_list the
> 1255: // next pointers always form a consistent singly linked list. The
> 1256: // entry_list can be in either of these forms:

Suggestion:

// entry_list can be in any of these forms:

"either" implies two choices

src/hotspot/share/runtime/objectMonitor.cpp line 1264:

> 1262: // Number four is because new threads has pushed themself to the
> 1263: // entry_list head after the entry_list was last converted into a
> 1264: // doubly linked list.

I suggest deleting this as we already know it from the description of how things work.

src/hotspot/share/runtime/objectMonitor.cpp line 1273:

> 1271:   while (w != nullptr) {
> 1272:     assert(w->TState == ObjectWaiter::TS_ENTER, "invariant");
> 1273:     assert(w->prev() == nullptr || w->prev() == prev, "should be");

Suggestion s/should be/invariant/ for all these assertions

src/hotspot/share/runtime/objectMonitor.cpp line 1297:

> 1295:     // and we don't have the tail pointer, something is broken.
> 1296:     assert(_entry_list_tail != nullptr, "should be");
> 1297: #ifdef ASSERT

I would move this `#ifdef ASSERT` to before the comment to make it clear the comment pertains to debug code.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24078#pullrequestreview-2701100435
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2004764666
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2004852415
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2004864581
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2004863120

From dholmes at openjdk.org  Thu Mar 20 05:57:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Mar 2025 05:57:09 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire()
In-Reply-To: <ztT_Z51EwsSSRjkj3f8fywkK_jGdec0nhoOZVh43eDA=.8f95d807-d28d-45b4-87bd-695b10849fef@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <ztT_Z51EwsSSRjkj3f8fywkK_jGdec0nhoOZVh43eDA=.8f95d807-d28d-45b4-87bd-695b10849fef@github.com>
Message-ID: <sh_WAinzNoAhveUaZBiU1u030vvC7oDixQxzAQVB7j8=.25d3724c-e738-4d07-8db8-04a2b05c374a@github.com>

On Wed, 19 Mar 2025 22:24:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
>> 
>> It has passed tier1-tier8 tests.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1265:
> 
>> 1263: // entry_list head after the entry_list was last converted into a
>> 1264: // doubly linked list.
>> 1265: void ObjectMonitor::entry_list_build_dll(JavaThread* current) {
> 
> We only call this from unlink_after_acquire() and exit() when we know the list is not empty, so why not assert that here and remove case 1?

I agree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2004867732

From dholmes at openjdk.org  Thu Mar 20 06:24:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Mar 2025 06:24:08 GMT
Subject: RFR: 8352178: Add precondition in VMThread::execute to prevent
 deadlock [v2]
In-Reply-To: <4pLJyRUOo1Yn2zbXkIFjk_CvULVqKebUi6Ao2aOVaRI=.7069a9d1-1f3e-4ddd-b94f-2269e13fd63e@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
 <7BZhsMLgKqPUkxaAuFfx3IbO_5mGMJZgTgmzJ5jgo6U=.4de59921-fa6c-4fad-a38f-88eb76d736b3@github.com>
 <4pLJyRUOo1Yn2zbXkIFjk_CvULVqKebUi6Ao2aOVaRI=.7069a9d1-1f3e-4ddd-b94f-2269e13fd63e@github.com>
Message-ID: <6ap5oEqwKDL5G5WVsvT_pllZUktibaDbmlmpSWgSkHI=.0a82a664-3070-41da-8eb8-aa2bedb6e9e0@github.com>

On Tue, 18 Mar 2025 14:50:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/runtime/handshake.cpp line 359:
>> 
>>> 357:   // deadlock.
>>> 358:   assert(!current_thread->is_suspendible_thread(), "precondition");
>>> 359:   assert(!current_thread->is_indirectly_suspendible_thread(), "precondition");
>> 
>> Why not move the asserts to VMThread::execute() to cover any operation, not just VM_HandshakeAllThreads?
>
> Moved to `VMThread::execute` and edited the title.

Aren't Handshakes a superset of VMoperations? `VMThread::execute` will only affect VM_Operations, not direct Handshakes with other threads. Is the problem limited to a STS thread trying to execute a safepoint VM operation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24088#discussion_r2004898247

From dholmes at openjdk.org  Thu Mar 20 06:44:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Mar 2025 06:44:10 GMT
Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event
 notification path
In-Reply-To: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
Message-ID: <avm3Eryk_oLRKwaT4i91PkQDfcjK8pDx4eq2q9f74sg=.6f198a8f-935a-4416-8192-1e5b2448a4c4@github.com>

On Tue, 18 Mar 2025 11:42:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

The use of the quick variants is to avoid the checks that could lead to throwing an exception, as they would require that the thread be _thread_in_vm not _thread_in_java.

That said it is not clear to me that posting the event doesn't violate the requirements that the quick version must maintain: no safepoints, no blocking, no state transitions. ??

src/hotspot/share/runtime/synchronizer.cpp line 372:

> 370:     if (mon->first_waiter() != nullptr) {
> 371:       // We have one or more waiters. Since this is an inflated monitor
> 372:       // that we own, we quickly notify it here and now, avoiding the slow-path.

Suggestion:

      // that we own, we quickly notify them here and now, avoiding the slow-path.

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

PR Review: https://git.openjdk.org/jdk/pull/24097#pullrequestreview-2701428216
PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2004904762

From dholmes at openjdk.org  Thu Mar 20 06:48:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Mar 2025 06:48:08 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
References: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
Message-ID: <69h0Dh_qDn-d5fWT-KZggMIgmwoUPS30fK7do9dTx9U=.9532956e-b0d5-46c6-b023-e2404f4b9438@github.com>

On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
> 
> - runtime/StackGap/TestStackGap.java
> - runtime/StackGuardPages/TestStackGuardPages.java
> - runtime/TLS/TestTLS.java
> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> - jdk/jni/nullCaller/NullCallerTest.java
> - jdk/tools/launcher/JniInvocationTest.java
> 
> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.

Okay - disabling these tests for now seems prudent. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24103#pullrequestreview-2701457909

From shade at openjdk.org  Thu Mar 20 08:42:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Mar 2025 08:42:44 GMT
Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event
 notification path [v2]
In-Reply-To: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
Message-ID: <6m-G3Mu3leXIiouOtiomohMr5pCLsZe0IRdP-4sLmgA=.d78dd015-3e93-4b35-b2bb-6fd6c979122e@github.com>

> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24097/files
  - new: https://git.openjdk.org/jdk/pull/24097/files/d82b3da2..144636f9

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

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

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

From shade at openjdk.org  Thu Mar 20 08:42:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 20 Mar 2025 08:42:45 GMT
Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event
 notification path [v2]
In-Reply-To: <avm3Eryk_oLRKwaT4i91PkQDfcjK8pDx4eq2q9f74sg=.6f198a8f-935a-4416-8192-1e5b2448a4c4@github.com>
References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
 <avm3Eryk_oLRKwaT4i91PkQDfcjK8pDx4eq2q9f74sg=.6f198a8f-935a-4416-8192-1e5b2448a4c4@github.com>
Message-ID: <HIhyzeUNfN7lZ_iC5UUSOLOJ-fxX91kRxzlVO5l54js=.142cdeef-744e-4cdf-b673-e9753c6b32fb@github.com>

On Thu, 20 Mar 2025 06:41:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That said it is not clear to me that posting the event doesn't violate the requirements that the quick version must maintain: no safepoints, no blocking, no state transitions. ??

Huh, that's a good question. There is a `NoSafepointVerifier` at the beginning `ObjectSynchronizer::quick_notify`, so at least the mechanical runtime checks did not fail. I'll run `all` tests with monitor notification event enabled.

I clicked through the JFR event commit code, and I don't think there are safepoints, indefinite blocking, or state transitions. Can we rely on this, @egahlin, @mgronlund?

> src/hotspot/share/runtime/synchronizer.cpp line 372:
> 
>> 370:     if (mon->first_waiter() != nullptr) {
>> 371:       // We have one or more waiters. Since this is an inflated monitor
>> 372:       // that we own, we quickly notify it here and now, avoiding the slow-path.
> 
> Suggestion:
> 
>       // that we own, we quickly notify them here and now, avoiding the slow-path.

Done!

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

PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2739596214
PR Review Comment: https://git.openjdk.org/jdk/pull/24097#discussion_r2005061558

From cnorrbin at openjdk.org  Thu Mar 20 10:50:15 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 20 Mar 2025 10:50:15 GMT
Subject: RFR: 8347734: Turning off PerfData logging doesn't work
In-Reply-To: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
References: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
Message-ID: <fb1mWIM_1G13BfL_aOchP1YpgETjQg2ptqKfVTZGsh8=.a156bb05-39c9-45f6-9e0f-20084898454d@github.com>

On Thu, 13 Mar 2025 15:07:07 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> When PerfData is disabled, the corresponding perfdata variables remain uninitialized. However, under certain conditions, logging may attempt to access these variables, leading to a crash. The existing code turns off the relevant tags using `LogConfiguration::configure_stdout`, but this doesn't modify other outputs. For example, the test `runtime/logging/RedefineClasses.java` crashes with `-XX:-UsePerfData` because it uses an output that isn't stdout.
> 
> To fix this, I've added a new method `LogConfiguration::disable_tags`. Unlike `configure_stdout`, this function iterates over all outputs and disables the specified tags on each. This way, we correctly disable tags across all outputs and longer try and access the uninitialized perfdata variables.

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24036#issuecomment-2739928030

From duke at openjdk.org  Thu Mar 20 10:50:16 2025
From: duke at openjdk.org (duke)
Date: Thu, 20 Mar 2025 10:50:16 GMT
Subject: RFR: 8347734: Turning off PerfData logging doesn't work
In-Reply-To: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
References: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
Message-ID: <q6BfLTBFtn5a-EaLfrv3lRh8hccvi8TYRVpkB2mP1wk=.c142b21b-472b-403c-8aaa-41476325c6f4@github.com>

On Thu, 13 Mar 2025 15:07:07 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> When PerfData is disabled, the corresponding perfdata variables remain uninitialized. However, under certain conditions, logging may attempt to access these variables, leading to a crash. The existing code turns off the relevant tags using `LogConfiguration::configure_stdout`, but this doesn't modify other outputs. For example, the test `runtime/logging/RedefineClasses.java` crashes with `-XX:-UsePerfData` because it uses an output that isn't stdout.
> 
> To fix this, I've added a new method `LogConfiguration::disable_tags`. Unlike `configure_stdout`, this function iterates over all outputs and disables the specified tags on each. This way, we correctly disable tags across all outputs and longer try and access the uninitialized perfdata variables.

@caspernorrbin 
Your change (at version ed4d479f21b763b19d538b87d157b50d3e1bc4f4) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24036#issuecomment-2739930491

From dholmes at openjdk.org  Thu Mar 20 12:28:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Mar 2025 12:28:32 GMT
Subject: RFR: 8347734: Turning off PerfData logging doesn't work
In-Reply-To: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
References: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
Message-ID: <A6izb9Scom-IF0P3Bdev2CxjKhMwYGKYJfBuZyO5eVU=.7df7a77c-74c4-4025-8362-0ade2492d355@github.com>

On Thu, 13 Mar 2025 15:07:07 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> When PerfData is disabled, the corresponding perfdata variables remain uninitialized. However, under certain conditions, logging may attempt to access these variables, leading to a crash. The existing code turns off the relevant tags using `LogConfiguration::configure_stdout`, but this doesn't modify other outputs. For example, the test `runtime/logging/RedefineClasses.java` crashes with `-XX:-UsePerfData` because it uses an output that isn't stdout.
> 
> To fix this, I've added a new method `LogConfiguration::disable_tags`. Unlike `configure_stdout`, this function iterates over all outputs and disables the specified tags on each. This way, we correctly disable tags across all outputs and longer try and access the uninitialized perfdata variables.

@caspernorrbin  please ensure to check the progress of your fix in the CI once it is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24036#issuecomment-2740289883

From cnorrbin at openjdk.org  Thu Mar 20 12:28:32 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 20 Mar 2025 12:28:32 GMT
Subject: Integrated: 8347734: Turning off PerfData logging doesn't work
In-Reply-To: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
References: <T8zS-Izu4XqAm148DHZVBVFv5VJcVju00aEOusTGQ7Y=.c8e1539b-fa53-43cd-b5b8-e112a99e0fc1@github.com>
Message-ID: <gJTswWkaS27flLJZxes-EZdAe3lOh7z0UYoRfZd63rY=.e65cf31b-2909-459f-8866-212ae5230f1a@github.com>

On Thu, 13 Mar 2025 15:07:07 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> When PerfData is disabled, the corresponding perfdata variables remain uninitialized. However, under certain conditions, logging may attempt to access these variables, leading to a crash. The existing code turns off the relevant tags using `LogConfiguration::configure_stdout`, but this doesn't modify other outputs. For example, the test `runtime/logging/RedefineClasses.java` crashes with `-XX:-UsePerfData` because it uses an output that isn't stdout.
> 
> To fix this, I've added a new method `LogConfiguration::disable_tags`. Unlike `configure_stdout`, this function iterates over all outputs and disables the specified tags on each. This way, we correctly disable tags across all outputs and longer try and access the uninitialized perfdata variables.

This pull request has now been integrated.

Changeset: 73177d9c
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73177d9c53ba02e9c358991774023619afe8379a
Stats:     64 lines in 4 files changed: 57 ins; 3 del; 4 mod

8347734: Turning off PerfData logging doesn't work

Reviewed-by: dholmes, coleenp

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

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

From jkern at openjdk.org  Thu Mar 20 14:30:58 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 20 Mar 2025 14:30:58 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  added needed include

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/6e76f114..200c36f4

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

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

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

From jkern at openjdk.org  Thu Mar 20 14:38:09 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 20 Mar 2025 14:38:09 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
Message-ID: <I7Xtl9mMYoDJyfVcmBklzoqmF3gM8ITZqVAKUSEqgjQ=.7219a63f-7069-48b1-8384-e1d0390856b4@github.com>

On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added needed include

I found the problem:
`include Execute.gmk`
was missing. Now in the same directory beside the three files e.g.

libjli.a
BUILD_LIBJLI_run_ar.cmdline
BUILD_LIBJLI_run_ar

I also get 

libjli.a.exp
_generate_export_list_libjli.a_exec.cmdline
_generate_export_list_libjli.a_exec

So I think point 3 of the PR description is solved, although I find the name `_generate_export_list_libjli.a_exec` a little bit to long.

The next point to work on is No. 2 of the PR description (3 `dladdr()` implementations spread over the code). Who can help me out with a review and a tip in which direction I should go?

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

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2740683211

From pchilanomate at openjdk.org  Thu Mar 20 14:53:08 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Mar 2025 14:53:08 GMT
Subject: RFR: 8352178: Add precondition in VMThread::execute to prevent
 deadlock [v2]
In-Reply-To: <6ap5oEqwKDL5G5WVsvT_pllZUktibaDbmlmpSWgSkHI=.0a82a664-3070-41da-8eb8-aa2bedb6e9e0@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
 <7BZhsMLgKqPUkxaAuFfx3IbO_5mGMJZgTgmzJ5jgo6U=.4de59921-fa6c-4fad-a38f-88eb76d736b3@github.com>
 <4pLJyRUOo1Yn2zbXkIFjk_CvULVqKebUi6Ao2aOVaRI=.7069a9d1-1f3e-4ddd-b94f-2269e13fd63e@github.com>
 <6ap5oEqwKDL5G5WVsvT_pllZUktibaDbmlmpSWgSkHI=.0a82a664-3070-41da-8eb8-aa2bedb6e9e0@github.com>
Message-ID: <bi-yacysGg8lyxmpw0Q9lwkMETht-ve1gFZlfgJtHMk=.2c2dc814-c6a1-4bbc-bd17-ac4b13336d2e@github.com>

On Thu, 20 Mar 2025 06:21:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Moved to `VMThread::execute` and edited the title.
>
> Aren't Handshakes a superset of VMoperations? `VMThread::execute` will only affect VM_Operations, not direct Handshakes with other threads. Is the problem limited to a STS thread trying to execute a safepoint VM operation?

There are two types of handshakes, the ones that target a single JavaThread and the ones that are executed on all JavaThreads. The latter one is a VM operation (VM_HandshakeAllThreads), i.e it?s executed by the VMThread. The original fix guarded against the deadlock scenario where the STS thread requested a VM_HandshakeAllThreads operation, but the same issue can happen by requesting any VM operation. As for direct handshakes, the original fix didn?t touch that code path, and I don?t think we need to because the handshaker can only be a JavaThread already, and AFAIK all these STS threads are not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24088#discussion_r2005825890

From fbredberg at openjdk.org  Thu Mar 20 14:56:27 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 20 Mar 2025 14:56:27 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
Message-ID: <aBYLLD2hAxOAR67XmrhPdP-DxCfsscIId-fZzt81uyg=.e6bbc22c-f3e1-4b28-acd2-fe4ace53bd74@github.com>

> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
> 
> It has passed tier1-tier8 tests.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  Update after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24078/files
  - new: https://git.openjdk.org/jdk/pull/24078/files/12581560..e6d1ed81

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

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

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

From fbredberg at openjdk.org  Thu Mar 20 14:56:28 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 20 Mar 2025 14:56:28 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <Jy8zD0chkshfaPdF1an24AyUltn2NfJmOfYMc7bIblw=.3ac5da38-fecf-449b-b6a5-05f86efef549@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <Jy8zD0chkshfaPdF1an24AyUltn2NfJmOfYMc7bIblw=.3ac5da38-fecf-449b-b6a5-05f86efef549@github.com>
Message-ID: <MlbXPwdmdTKIloSkWw9G_pQdw5qRiaXc2opX4dl326k=.e7e2de48-06c7-45e1-93f1-7aa99de2a45b@github.com>

On Thu, 20 Mar 2025 03:48:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1256:
> 
>> 1254: // pointers and the entry_list_tail pointer. Within the entry_list the
>> 1255: // next pointers always form a consistent singly linked list. The
>> 1256: // entry_list can be in either of these forms:
> 
> Suggestion:
> 
> // entry_list can be in any of these forms:
> 
> "either" implies two choices

Fixed

> src/hotspot/share/runtime/objectMonitor.cpp line 1273:
> 
>> 1271:   while (w != nullptr) {
>> 1272:     assert(w->TState == ObjectWaiter::TS_ENTER, "invariant");
>> 1273:     assert(w->prev() == nullptr || w->prev() == prev, "should be");
> 
> Suggestion s/should be/invariant/ for all these assertions

Fixed

> src/hotspot/share/runtime/objectMonitor.cpp line 1297:
> 
>> 1295:     // and we don't have the tail pointer, something is broken.
>> 1296:     assert(_entry_list_tail != nullptr, "should be");
>> 1297: #ifdef ASSERT
> 
> I would move this `#ifdef ASSERT` to before the comment to make it clear the comment pertains to debug code.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2005831461
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2005832339
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2005831909

From fbredberg at openjdk.org  Thu Mar 20 14:56:29 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 20 Mar 2025 14:56:29 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <sh_WAinzNoAhveUaZBiU1u030vvC7oDixQxzAQVB7j8=.25d3724c-e738-4d07-8db8-04a2b05c374a@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <ztT_Z51EwsSSRjkj3f8fywkK_jGdec0nhoOZVh43eDA=.8f95d807-d28d-45b4-87bd-695b10849fef@github.com>
 <sh_WAinzNoAhveUaZBiU1u030vvC7oDixQxzAQVB7j8=.25d3724c-e738-4d07-8db8-04a2b05c374a@github.com>
Message-ID: <6pSGLLAU3EcPKJe1YchSfPlOM_26cN-brPV1dSB71A0=.23283e1f-bfa2-478d-a4e8-131ac94416ca@github.com>

On Thu, 20 Mar 2025 05:54:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1265:
>> 
>>> 1263: // entry_list head after the entry_list was last converted into a
>>> 1264: // doubly linked list.
>>> 1265: void ObjectMonitor::entry_list_build_dll(JavaThread* current) {
>> 
>> We only call this from unlink_after_acquire() and exit() when we know the list is not empty, so why not assert that here and remove case 1?
>
> I agree.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2005826439

From fbredberg at openjdk.org  Thu Mar 20 14:56:30 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 20 Mar 2025 14:56:30 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <ztT_Z51EwsSSRjkj3f8fywkK_jGdec0nhoOZVh43eDA=.8f95d807-d28d-45b4-87bd-695b10849fef@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <ztT_Z51EwsSSRjkj3f8fywkK_jGdec0nhoOZVh43eDA=.8f95d807-d28d-45b4-87bd-695b10849fef@github.com>
Message-ID: <Jrt7kMwxmZ_5FDPy9TfT6tDSFDm2-o_fpdwioEPibjQ=.88e1c414-1224-4062-82c4-4ff9a464e2b5@github.com>

On Wed, 19 Mar 2025 22:28:46 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1284:
> 
>> 1282:     // We converted the entire entry_list from a singly linked list
>> 1283:     // into a doubly linked list. Now we just need to set the tail
>> 1284:     // pointer.
> 
> This could also be the empty list case so comment could be improved to separate those two cases. No need to change it if we assert list can?t be empty at the beginning.

No changed since I now assert that the list can?t be empty.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2005830972

From fbredberg at openjdk.org  Thu Mar 20 15:00:16 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 20 Mar 2025 15:00:16 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <Jy8zD0chkshfaPdF1an24AyUltn2NfJmOfYMc7bIblw=.3ac5da38-fecf-449b-b6a5-05f86efef549@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <Jy8zD0chkshfaPdF1an24AyUltn2NfJmOfYMc7bIblw=.3ac5da38-fecf-449b-b6a5-05f86efef549@github.com>
Message-ID: <h1olBYdJeHginpuvP8-tCTKU-9d_SpK9uySlg6XhdRk=.21f6345f-a6a8-4ef7-b0ed-b4f69cca0d4f@github.com>

On Thu, 20 Mar 2025 05:42:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1264:
> 
>> 1262: // Number four is because new threads has pushed themself to the
>> 1263: // entry_list head after the entry_list was last converted into a
>> 1264: // doubly linked list.
> 
> I suggest deleting this as we already know it from the description of how things work.

I like to add comments locally that helps the reader to understand things without having to seek out a "how things work" section. If you feel strongly that it should be removed, I'll do it, but if not I'd rather keep it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2005840894

From jiangli at openjdk.org  Thu Mar 20 15:12:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Mar 2025 15:12:16 GMT
Subject: RFR: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: <CeRmURQz27CabX8VQdUevmm6eht_Pwk2jSC--ke-nR4=.6ff8e073-543c-4bd4-addc-001cc97f41e8@github.com>
References: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
 <CeRmURQz27CabX8VQdUevmm6eht_Pwk2jSC--ke-nR4=.6ff8e073-543c-4bd4-addc-001cc97f41e8@github.com>
Message-ID: <96e0y1kerF2aDqoaN4W8Ppv3noArpfk9e0cyIbVm724=.738e062c-f7cd-4e2a-bca3-44b0a86cdfc9@github.com>

On Wed, 19 Mar 2025 00:29:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
>> 
>> - runtime/StackGap/TestStackGap.java
>> - runtime/StackGuardPages/TestStackGuardPages.java
>> - runtime/TLS/TestTLS.java
>> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
>> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
>> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> - jdk/jni/nullCaller/NullCallerTest.java
>> - jdk/tools/launcher/JniInvocationTest.java
>> 
>> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.
>
> @jianglizhou  shouldn't these native executables be built differently to work with the static JDK? Otherwise how does a user create a native executable that launches the JVM?

Thanks, @dholmes-ora!

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

PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2740792904

From jiangli at openjdk.org  Thu Mar 20 15:12:17 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 20 Mar 2025 15:12:17 GMT
Subject: Integrated: 8352276: Skip jtreg tests using native executable with
 libjvm.so/libjli.so dependencies on static JDK
In-Reply-To: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
References: <d0akbNQEdrJlfgAAQVnKYhPuWgEXsUlvdm3hE4ODaDI=.7cf341e8-d6c8-4191-b9fd-472c321b73b9@github.com>
Message-ID: <3za2jze9qGF7ZjQGEvH-tDHCJneOtVRZr56-S0WaJwQ=.571defc7-063f-421c-bee4-db77cba512b9@github.com>

On Tue, 18 Mar 2025 18:57:04 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
> 
> - runtime/StackGap/TestStackGap.java
> - runtime/StackGuardPages/TestStackGuardPages.java
> - runtime/TLS/TestTLS.java
> - runtime/jni/daemonDestroy/TestDaemonDestroy.java
> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> - jdk/jni/nullCaller/NullCallerTest.java
> - jdk/tools/launcher/JniInvocationTest.java
> 
> These tests use native executables that have dependencies on `libjvm.so`, `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared libraries, hence cannot support the specific testing mode.

This pull request has now been integrated.

Changeset: 91836e18
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91836e181a789ef16e8d70bfde4c040e6f5031db
Stats:     8 lines in 8 files changed: 8 ins; 0 del; 0 mod

8352276: Skip jtreg tests using native executable with libjvm.so/libjli.so dependencies on static JDK

Reviewed-by: dholmes

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

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

From pchilanomate at openjdk.org  Thu Mar 20 16:40:10 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 20 Mar 2025 16:40:10 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <aBYLLD2hAxOAR67XmrhPdP-DxCfsscIId-fZzt81uyg=.e6bbc22c-f3e1-4b28-acd2-fe4ace53bd74@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <aBYLLD2hAxOAR67XmrhPdP-DxCfsscIId-fZzt81uyg=.e6bbc22c-f3e1-4b28-acd2-fe4ace53bd74@github.com>
Message-ID: <08SI_ykCWkhhq8gwO9DsbPZ-S_CThbV8igevbq6H00g=.be697c81-84ba-41db-964d-cc424c82c8ba@github.com>

On Thu, 20 Mar 2025 14:56:27 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
>> 
>> It has passed tier1-tier8 tests.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

src/hotspot/share/runtime/objectMonitor.cpp line 1258:

> 1256: // entry_list can be in any of these forms:
> 1257: //   1. Only singly linked.
> 1258: //   2. Only doubly linked.

This case should also never happen. If the whole list is already fully doubly linked we would not call this.

src/hotspot/share/runtime/objectMonitor.cpp line 1287:

> 1285:     // into a doubly linked list. Now we just need to set the tail
> 1286:     // pointer.
> 1287:     assert(prev == nullptr || prev->next() == nullptr, "invariant");

Since empty list is not possible instead of `prev == nullptr ||` this should be `prev != nullptr &&`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2006040022
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2006043572

From iklam at openjdk.org  Thu Mar 20 16:53:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 20 Mar 2025 16:53:17 GMT
Subject: RFR: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <kGaJKRN4KgqzPaDcdP4mqlcNPlCUuqwsPb9ke07loP4=.796a12b7-e54e-4fdf-b4ee-b79567b7e646@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
 <kGaJKRN4KgqzPaDcdP4mqlcNPlCUuqwsPb9ke07loP4=.796a12b7-e54e-4fdf-b4ee-b79567b7e646@github.com>
Message-ID: <eYeLsVZXGSX0fkGJuFIFnW_p3l9yWLFmJRebsU58b_M=.03c3216a-6577-48d2-92c1-b38fc9846f61@github.com>

On Tue, 18 Mar 2025 19:21:11 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This PR tries to cut down the use of `WhiteBox` in the HotSpot test cases. It modifies `VMProps` to save the set of VM properties into a file called "vm.properties" under Jtreg's work directory. The new API `jdk.test.lib.VMPropsGetter` loads the properties from this file to pass onto individual test cases.
>> 
>> See `getJtregWorkDir()` for the code that figures out the work directory. It assumes that `VMProps` and all test cases are always executed under
>> 
>> - `workDir/scratch/` ; or
>> - `workDir/scratch/[0-9]+/` 
>> 
>> This is probably not the right thing to do. I would be better for Jtreg to pass the location of the work directory to the test cases, with a command-line options like `-Djtreg.work.dir=<dir>`.
>> 
>> To show the benefit of this PR, I modified a few test cases to remove their use of WhiteBox.
>
> Changes requested by lmesnik (Reviewer).

Per @lmesnik , this RFE will not work. Closing this PR as will-not-fix.

Alternative RFE: [JDK-8352528 - Move CDS WhiteBox APIs to jdk.internal.test.cds.WhiteBox](https://bugs.openjdk.org/browse/JDK-8352528)

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

PR Comment: https://git.openjdk.org/jdk/pull/24071#issuecomment-2741093037

From iklam at openjdk.org  Thu Mar 20 16:53:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 20 Mar 2025 16:53:17 GMT
Subject: Withdrawn: 8352107: Allow jtreg test cases to query test VM properties
In-Reply-To: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
References: <2UVSQ63GCoa9OysikhoP7ElkUoU0LaN3m8E9065kEpU=.5770b9dd-b0cd-4309-91f6-3569e79a3d46@github.com>
Message-ID: <dl67h8beN7scoXCFBgdayJPkVlM-YpDYIRmsZCICVKM=.c421d9df-714b-4889-ab59-86e7e0393ea6@github.com>

On Sun, 16 Mar 2025 02:54:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR tries to cut down the use of `WhiteBox` in the HotSpot test cases. It modifies `VMProps` to save the set of VM properties into a file called "vm.properties" under Jtreg's work directory. The new API `jdk.test.lib.VMPropsGetter` loads the properties from this file to pass onto individual test cases.
> 
> See `getJtregWorkDir()` for the code that figures out the work directory. It assumes that `VMProps` and all test cases are always executed under
> 
> - `workDir/scratch/` ; or
> - `workDir/scratch/[0-9]+/` 
> 
> This is probably not the right thing to do. I would be better for Jtreg to pass the location of the work directory to the test cases, with a command-line options like `-Djtreg.work.dir=<dir>`.
> 
> To show the benefit of this PR, I modified a few test cases to remove their use of WhiteBox.

This pull request has been closed without being integrated.

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

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

From gziemski at openjdk.org  Thu Mar 20 20:15:42 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 20 Mar 2025 20:15:42 GMT
Subject: RFR: 8341095: Possible overflow in os::Posix::print_uptime_info
Message-ID: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>

This is a trivial change that will quiet Xcode only visual warning in os_posix.cpp file.

There are 31,536,000 seconds in a year, so if int is 32bits, then we have MAX int value of 2,147,483,647 so it would overflow in 68 years - unlikely to affect anyone.

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

Commit messages:
 - use cast to quiet Xcode warning

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

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

From dholmes at openjdk.org  Fri Mar 21 03:08:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 03:08:31 GMT
Subject: RFR: 8341095: Possible overflow in os::Posix::print_uptime_info
In-Reply-To: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>
References: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>
Message-ID: <4Hit0zmsqYZPn5x9-9qATxN5fhuGJ5jrAdf4vDKkP88=.1a78c4d0-b30c-44c3-aafa-138220f16749@github.com>

On Thu, 20 Mar 2025 20:08:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> This is a trivial change that will quiet Xcode only visual warning in os_posix.cpp file.
> 
> There are 31,536,000 seconds in a year, so if int is 32bits, then we have MAX int value of 2,147,483,647 so it would overflow in 68 years - unlikely to affect anyone.

Okay and trivial.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24140#pullrequestreview-2704612696

From dholmes at openjdk.org  Fri Mar 21 05:53:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 05:53:10 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <h1olBYdJeHginpuvP8-tCTKU-9d_SpK9uySlg6XhdRk=.21f6345f-a6a8-4ef7-b0ed-b4f69cca0d4f@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <Jy8zD0chkshfaPdF1an24AyUltn2NfJmOfYMc7bIblw=.3ac5da38-fecf-449b-b6a5-05f86efef549@github.com>
 <h1olBYdJeHginpuvP8-tCTKU-9d_SpK9uySlg6XhdRk=.21f6345f-a6a8-4ef7-b0ed-b4f69cca0d4f@github.com>
Message-ID: <aiO99V5quKrMpeha9Dc-L7QWAsDh2C5Oq0bmgnHM-cs=.4db9a0bc-45c4-4e5e-b2e7-79bf83c50d0d@github.com>

On Thu, 20 Mar 2025 14:57:38 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1264:
>> 
>>> 1262: // Number four is because new threads has pushed themself to the
>>> 1263: // entry_list head after the entry_list was last converted into a
>>> 1264: // doubly linked list.
>> 
>> I suggest deleting this as we already know it from the description of how things work.
>
> I like to add comments locally that helps the reader to understand things without having to seek out a "how things work" section. If you feel strongly that it should be removed, I'll do it, but if not I'd rather keep it.

Local comments where the code is not obvious sure. But we have over 100 lines of commentary describing the operations of this list including that it can be singly or doubly linked, so I really don't think we need this level of detail again at this point in the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2006871558

From dholmes at openjdk.org  Fri Mar 21 05:53:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 05:53:08 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <aBYLLD2hAxOAR67XmrhPdP-DxCfsscIId-fZzt81uyg=.e6bbc22c-f3e1-4b28-acd2-fe4ace53bd74@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <aBYLLD2hAxOAR67XmrhPdP-DxCfsscIId-fZzt81uyg=.e6bbc22c-f3e1-4b28-acd2-fe4ace53bd74@github.com>
Message-ID: <PKWzm7ZTPezoReuYFwc3W-dIF5T2kshvEyovEq3J-qI=.41ab94e9-da37-4769-b7dd-98a1937fa31f@github.com>

On Thu, 20 Mar 2025 14:56:27 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
>> 
>> It has passed tier1-tier8 tests.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

A few more nits - plus I agree with Patricio's comments.

src/hotspot/share/runtime/objectMonitor.cpp line 1254:

> 1252: 
> 1253: // Convert entry_list into a doubly linked list by assigning the prev
> 1254: // pointers and the entry_list_tail pointer. Within the entry_list the

Suggestion:

// pointers and the entry_list_tail pointer (if needed). Within the entry_list the

If the bottom end of the list is already DL then the tail will already be set.

src/hotspot/share/runtime/objectMonitor.cpp line 1272:

> 1270:   // This function should only be called when we know that the
> 1271:   // entry_list is not empty.
> 1272:   assert(w != nullptr, "invariant");

Suggestion - no comments just:

assert(w != nullptr, "should only be called when entry list is not empty");

src/hotspot/share/runtime/objectMonitor.cpp line 1321:

> 1319:   entry_list_build_dll(current);
> 1320:   w = _entry_list_tail;
> 1321:   assert(w != nullptr, "should be");

Suggestion:

  assert(w != nullptr, "invariant");

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

PR Review: https://git.openjdk.org/jdk/pull/24078#pullrequestreview-2704734818
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2006850688
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2006882046
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2006864300

From dholmes at openjdk.org  Fri Mar 21 06:07:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 06:07:14 GMT
Subject: RFR: 8352178: Add precondition in VMThread::execute to prevent
 deadlock [v2]
In-Reply-To: <bi-yacysGg8lyxmpw0Q9lwkMETht-ve1gFZlfgJtHMk=.2c2dc814-c6a1-4bbc-bd17-ac4b13336d2e@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <uBQvmsoRz4SN5_-tJMUSM6V1fpa7mejH6_zaKVwfNN0=.9a4aa821-a365-4529-b587-d34f6691bd7c@github.com>
 <7BZhsMLgKqPUkxaAuFfx3IbO_5mGMJZgTgmzJ5jgo6U=.4de59921-fa6c-4fad-a38f-88eb76d736b3@github.com>
 <4pLJyRUOo1Yn2zbXkIFjk_CvULVqKebUi6Ao2aOVaRI=.7069a9d1-1f3e-4ddd-b94f-2269e13fd63e@github.com>
 <6ap5oEqwKDL5G5WVsvT_pllZUktibaDbmlmpSWgSkHI=.0a82a664-3070-41da-8eb8-aa2bedb6e9e0@github.com>
 <bi-yacysGg8lyxmpw0Q9lwkMETht-ve1gFZlfgJtHMk=.2c2dc814-c6a1-4bbc-bd17-ac4b13336d2e@github.com>
Message-ID: <krgJUCqH34bD6f-y3vD2nwpQ8sZzpVihbtXIgvz9wO0=.29594d7e-36b6-452d-9078-092fbeda086a@github.com>

On Thu, 20 Mar 2025 14:50:34 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Aren't Handshakes a superset of VMoperations? `VMThread::execute` will only affect VM_Operations, not direct Handshakes with other threads. Is the problem limited to a STS thread trying to execute a safepoint VM operation?
>
> There are two types of handshakes, the ones that target a single JavaThread and the ones that are executed on all JavaThreads. The latter one is a VM operation (VM_HandshakeAllThreads), i.e it?s executed by the VMThread. The original fix guarded against the deadlock scenario where the STS thread requested a VM_HandshakeAllThreads operation, but the same issue can happen by requesting any VM operation. As for direct handshakes, the original fix didn?t touch that code path, and I don?t think we need to because the handshaker can only be a JavaThread already, and AFAIK all these STS threads are not.

Thanks Patricio. I had things inverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24088#discussion_r2006904269

From ktakakuri at openjdk.org  Fri Mar 21 07:44:09 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Fri, 21 Mar 2025 07:44:09 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v2]
In-Reply-To: <Em_-v3GPZk-3ydYC0ZaIj2jklgu0IgCcJ-cVaOBXGVE=.881af30f-47ff-407f-8a73-4356aca5e1a1@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <VY8wZOwMgOaNgfKYlYWeb9b2XupI_8oZ8_hmy4i2syY=.86058d22-2c1f-4758-94e3-0a8fb938ced9@github.com>
 <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com>
 <zRILbqqqfapzSSqehYXi0aByi7vKRgSmmdZna5jx7Vg=.0bf97ac0-1406-4379-afa8-03b22115fe20@github.com>
 <dQlSzANca3fgrran6u4v4NJL4wmUjzo7SppQLzDLFX4=.2b541d09-96e2-49eb-a97b-0f4b33752e46@github.com>
 <bXiWo1gfSuKU7FpQZyfIi9f4HHIoMvTdur3Lh3-mA7g=.3301a575-da75-448c-8b27-e938fcd37f4c@github.com>
 <Em_-v3GPZk-3ydYC0ZaIj2jklgu0IgCcJ-cVaOBXGVE=.881af30f-47ff-407f-8a73-4356aca5e1a1@github.com>
Message-ID: <LKuyGZAMtL_wCCxVhV8Eu_29v8mYDq8achjsfvRzbD0=.87d947ca-3b08-4ac0-9392-c4deead18a7a@github.com>

On Mon, 17 Mar 2025 05:50:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think tools/jpackage/helpers/jdk/jpackage/test/Executor.java is not run in GHA.
>
> Correct. That is a tier2 test and IIUC GHA only runs tier1.
> 
> But I'm not sure why you're asking. I was pointing out that the jpackage test uses chcp in a simpler way than you have used, so I was suggesting you simplify your code and see if it still works.

Running TestAvailableProcessors.java in GHA without adding the PATH failed. Additional processing is required to pass GHA.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2007020072

From fbredberg at openjdk.org  Fri Mar 21 09:23:36 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 21 Mar 2025 09:23:36 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <PKWzm7ZTPezoReuYFwc3W-dIF5T2kshvEyovEq3J-qI=.41ab94e9-da37-4769-b7dd-98a1937fa31f@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <aBYLLD2hAxOAR67XmrhPdP-DxCfsscIId-fZzt81uyg=.e6bbc22c-f3e1-4b28-acd2-fe4ace53bd74@github.com>
 <PKWzm7ZTPezoReuYFwc3W-dIF5T2kshvEyovEq3J-qI=.41ab94e9-da37-4769-b7dd-98a1937fa31f@github.com>
Message-ID: <24hrlunC1DN_kCtn0385dhySvjZmhkLcT6JiQVX_jgA=.a8995d3d-d3ef-4807-9637-70df986f2bf7@github.com>

On Fri, 21 Mar 2025 04:54:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1254:
> 
>> 1252: 
>> 1253: // Convert entry_list into a doubly linked list by assigning the prev
>> 1254: // pointers and the entry_list_tail pointer. Within the entry_list the
> 
> Suggestion:
> 
> // pointers and the entry_list_tail pointer (if needed). Within the entry_list the
> 
> If the bottom end of the list is already DL then the tail will already be set.

Fixed

> src/hotspot/share/runtime/objectMonitor.cpp line 1272:
> 
>> 1270:   // This function should only be called when we know that the
>> 1271:   // entry_list is not empty.
>> 1272:   assert(w != nullptr, "invariant");
> 
> Suggestion - no comments just:
> 
> assert(w != nullptr, "should only be called when entry list is not empty");

Fixed

> src/hotspot/share/runtime/objectMonitor.cpp line 1321:
> 
>> 1319:   entry_list_build_dll(current);
>> 1320:   w = _entry_list_tail;
>> 1321:   assert(w != nullptr, "should be");
> 
> Suggestion:
> 
>   assert(w != nullptr, "invariant");

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2007162344
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2007159670
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2007161789

From fbredberg at openjdk.org  Fri Mar 21 09:23:35 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 21 Mar 2025 09:23:35 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v3]
In-Reply-To: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
Message-ID: <Vcn7Qcj0eVb0FNrGgM-fzyM2-GLNu2L_mzJWCNu0wSE=.f7ed2f60-e71b-4a5c-b560-6cd9791be3a5@github.com>

> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
> 
> It has passed tier1-tier8 tests.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  Second update after review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24078/files
  - new: https://git.openjdk.org/jdk/pull/24078/files/e6d1ed81..ccf1e7e0

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

  Stats: 15 lines in 1 file changed: 0 ins; 7 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24078/head:pull/24078

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

From fbredberg at openjdk.org  Fri Mar 21 09:23:36 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 21 Mar 2025 09:23:36 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v2]
In-Reply-To: <08SI_ykCWkhhq8gwO9DsbPZ-S_CThbV8igevbq6H00g=.be697c81-84ba-41db-964d-cc424c82c8ba@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <aBYLLD2hAxOAR67XmrhPdP-DxCfsscIId-fZzt81uyg=.e6bbc22c-f3e1-4b28-acd2-fe4ace53bd74@github.com>
 <08SI_ykCWkhhq8gwO9DsbPZ-S_CThbV8igevbq6H00g=.be697c81-84ba-41db-964d-cc424c82c8ba@github.com>
Message-ID: <N3L5hpKJQ3m_KStjo010pRI_1UbvDHqFnrmFjJ3-qGA=.6eb0e855-da4c-4190-8928-c066140e8132@github.com>

On Thu, 20 Mar 2025 16:34:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1258:
> 
>> 1256: // entry_list can be in any of these forms:
>> 1257: //   1. Only singly linked.
>> 1258: //   2. Only doubly linked.
> 
> This case should also never happen. If the whole list is already fully doubly linked we would not call this.

Rewrote the comment.

> src/hotspot/share/runtime/objectMonitor.cpp line 1287:
> 
>> 1285:     // into a doubly linked list. Now we just need to set the tail
>> 1286:     // pointer.
>> 1287:     assert(prev == nullptr || prev->next() == nullptr, "invariant");
> 
> Since empty list is not possible instead of `prev == nullptr ||` this should be `prev != nullptr &&`.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2007164136
PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2007163432

From fbredberg at openjdk.org  Fri Mar 21 09:28:08 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 21 Mar 2025 09:28:08 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v3]
In-Reply-To: <aiO99V5quKrMpeha9Dc-L7QWAsDh2C5Oq0bmgnHM-cs=.4db9a0bc-45c4-4e5e-b2e7-79bf83c50d0d@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <Jy8zD0chkshfaPdF1an24AyUltn2NfJmOfYMc7bIblw=.3ac5da38-fecf-449b-b6a5-05f86efef549@github.com>
 <h1olBYdJeHginpuvP8-tCTKU-9d_SpK9uySlg6XhdRk=.21f6345f-a6a8-4ef7-b0ed-b4f69cca0d4f@github.com>
 <aiO99V5quKrMpeha9Dc-L7QWAsDh2C5Oq0bmgnHM-cs=.4db9a0bc-45c4-4e5e-b2e7-79bf83c50d0d@github.com>
Message-ID: <AaDirI11szsoxfEz8dApQFq8AfnaMQHDMgCFfoW87ek=.6936f5ad-755b-4881-ac0a-69e0f927ec03@github.com>

On Fri, 21 Mar 2025 05:25:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I like to add comments locally that helps the reader to understand things without having to seek out a "how things work" section. If you feel strongly that it should be removed, I'll do it, but if not I'd rather keep it.
>
> Local comments where the code is not obvious sure. But we have over 100 lines of commentary describing the operations of this list including that it can be singly or doubly linked, so I really don't think we need this level of detail again at this point in the code.

Ok, no problem, I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24078#discussion_r2007170264

From jkern at openjdk.org  Fri Mar 21 09:48:12 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 21 Mar 2025 09:48:12 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java makes no sense for aix and musl
In-Reply-To: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
Message-ID: <6undOp1rlfdP2qboIGHRVGlEJdsghqktutGduFP9HMM=.9a0bcab8-42ad-40af-9b39-ad0316c09b05@github.com>

On Fri, 14 Mar 2025 11:47:44 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. So we skip this sub test for aix and musl.

@vidmik @axel7born Can please someone take a look at this PR, because I want to change something you implemented 5 years ago. Maybe @dholmes-ora @alanb @erikj who did the review may also take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/24055#issuecomment-2742845831

From clanger at openjdk.org  Fri Mar 21 09:57:16 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 21 Mar 2025 09:57:16 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java makes no sense for aix and musl
In-Reply-To: <6undOp1rlfdP2qboIGHRVGlEJdsghqktutGduFP9HMM=.9a0bcab8-42ad-40af-9b39-ad0316c09b05@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <6undOp1rlfdP2qboIGHRVGlEJdsghqktutGduFP9HMM=.9a0bcab8-42ad-40af-9b39-ad0316c09b05@github.com>
Message-ID: <Calhb-qif6Ili5SVlKeSNu9s0Ck7UHekyhzy8EeTEFE=.08a42cbd-298c-4b78-8a68-b5a2e1cd307e@github.com>

On Fri, 21 Mar 2025 09:46:02 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. So we skip this sub test for aix and musl.
>
> @vidmik @axel7born Can please someone take a look at this PR, because I want to change something you implemented 5 years ago. Maybe @dholmes-ora @alanb @erikj who did the review may also take a look.

Hi @JoKern65, I just checked this PR but first of all I'm missing the motivation here. What exactly is failing now and why, given that the test has worked without error for years on all platforms?

E.g. is the assumption that in case of a pre-set LD_LIBRARY_PATH, the result should be:
`String libPath = LD_LIBRARY_PATH + "=" + System.getenv(LD_LIBRARY_PATH) + System.getProperty("path.separator") + LD_LIBRARY_PATH_VALUE;` not holding any more?

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

PR Comment: https://git.openjdk.org/jdk/pull/24055#issuecomment-2742867252

From ihse at openjdk.org  Fri Mar 21 10:31:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Mar 2025 10:31:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
Message-ID: <KLjkCfVhBiKob8pC0mgS4DvpOyaWTE7w-S0hFG88ptI=.4ce459f3-78cc-48a4-8ac6-ce0e3a47a059@github.com>

On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added needed include

Regaring point 2: the current solution works, and is acceptable, I think. The two excluded files only contain the dladdr() implementation, and this is implemented in hotspot, so no functionality is lost. Compacting this into just a single implementation is a separate issue, and need not be resolved now.

Regarding the name of `_generate_export_list_libjli.a_exec`: this is generated from the name of the SetupExecute rule, `generate_export_list_$(lib)`. I don't mind the name, it is clear. I don't see any particular point in keeping the name short, but if it bothers you, shorten the name of the rule. Try keeping it clear what it does, though.

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

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2742949097

From ihse at openjdk.org  Fri Mar 21 10:36:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Mar 2025 10:36:16 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
Message-ID: <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com>

On Thu, 20 Mar 2025 14:30:58 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added needed include

make/StaticLibs.gmk line 117:

> 115:       OUTPUT_FILE := $(lib).exp, \
> 116:       COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \
> 117:     )) \

To better align with how we store the targets of Setup calls, can you please change this to:

Suggestion:

  STATIC_LIBS := -Wl,-bexpfull $(STATIC_LIB_FILES) $(addprefix -Wl$(COMMA)-bE:, $(STATIC_LIB_EXPORT_FILES))
  $(foreach lib, $(STATIC_LIB_FILES), \
    $(eval $(call SetupExecute, generate_export_list_$(notdir $(lib)), \
      INFO := Generating export list for $(notdir $(lib)), \
      DEPS :=  $(lib), \
      OUTPUT_FILE := $(lib).exp, \
      COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \
    )) \
    $(eval   STATIC_LIB_EXPORT_FILES += $(lib).exp) \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007298830

From ayang at openjdk.org  Fri Mar 21 10:38:26 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 21 Mar 2025 10:38:26 GMT
Subject: RFR: 8352178: Add precondition in VMThread::execute to prevent
 deadlock [v3]
In-Reply-To: <hNkwh4P3WaznOCE9m6f0nM53gW3XPOnX_ZSZjnex7Yg=.1e55b089-ba91-4e4c-89f8-454c687cce2a@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
 <hNkwh4P3WaznOCE9m6f0nM53gW3XPOnX_ZSZjnex7Yg=.1e55b089-ba91-4e4c-89f8-454c687cce2a@github.com>
Message-ID: <zftCOMjx4nOErd1pp7tWC0p3TDCb2Yx2ReyjjRj4SsI=.86371610-2826-415e-810f-6605d198c5b5@github.com>

On Tue, 18 Mar 2025 14:55:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
>> All existing callsites satisfy this precondition already.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Rerunning tier1-5 pass. Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/24088#issuecomment-2742966532

From ayang at openjdk.org  Fri Mar 21 10:38:26 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 21 Mar 2025 10:38:26 GMT
Subject: Integrated: 8352178: Add precondition in VMThread::execute to prevent
 deadlock
In-Reply-To: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
References: <foS88Gcndz-7rjzcLHkkWowjHM-3kHho8elugr24nL8=.b1fda13c-0f35-4fb9-9ce9-d248deffec66@github.com>
Message-ID: <FE9pnFginI5ZyldMvanaba90Xxte2q5OYLyxm9NfmB4=.d5bf6f84-191f-4ac1-9b8a-9c25217fbd95@github.com>

On Mon, 17 Mar 2025 19:57:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple patch of adding `SuspendibleThreadSet` related precondition to `Handshake::execute` in order to prevent deadlock.
> All existing callsites satisfy this precondition already.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: b32be18b
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b32be18bf940eb6eb9805390fd72e0de175c912a
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

8352178: Add precondition in VMThread::execute to prevent deadlock

Reviewed-by: pchilanomate, tschatzl, dholmes, shade

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

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

From clanger at openjdk.org  Fri Mar 21 11:43:11 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 21 Mar 2025 11:43:11 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java makes no sense for aix and musl
In-Reply-To: <6undOp1rlfdP2qboIGHRVGlEJdsghqktutGduFP9HMM=.9a0bcab8-42ad-40af-9b39-ad0316c09b05@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <6undOp1rlfdP2qboIGHRVGlEJdsghqktutGduFP9HMM=.9a0bcab8-42ad-40af-9b39-ad0316c09b05@github.com>
Message-ID: <dECjUHRG6FIGKR-tXXnsGGX7MsQ4hJIdUpsGC8bN1qY=.ba430dd5-5d48-48cd-b11e-7c6e5f18872e@github.com>

On Fri, 21 Mar 2025 09:46:02 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
>> 
>> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
>> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
>> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
>> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
>> 
>> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
>> So my proposal is to skip this sub test for aix and musl.
>
> @vidmik @axel7born Can please someone take a look at this PR, because I want to change something you implemented 5 years ago. Maybe @dholmes-ora @alanb @erikj who did the review may also take a look.

Thanks for enhancing the PR description @JoKern65. So, the problem appears because in our test scenario we now pass a certain LD_LIBRARY_PATH option, which we didn't do before.

So, I agree that the test for AIX and MUSL could be skipped because the assumption of a pristine LD_LIBRARY_PATH doesn't hold there since the launcher sets an LD_LIBRARY_PATH on purpose. However, can't we construct exactly this path in the test with the information that we have, e.g. the java.home system property?

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

PR Comment: https://git.openjdk.org/jdk/pull/24055#issuecomment-2743116596

From jkern at openjdk.org  Fri Mar 21 11:44:49 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 21 Mar 2025 11:44:49 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v4]
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  follow Magnus

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/200c36f4..9b92eea7

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

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

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

From jkern at openjdk.org  Fri Mar 21 11:44:49 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 21 Mar 2025 11:44:49 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v3]
In-Reply-To: <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <NoXWkBNL5FH-aa0imCTSytxsNe_AY-eG4aw5nUTKsPg=.fa03e069-b6ec-4cd6-b3d7-11a62b418194@github.com>
 <_zSryyYezjaQlCMpDSE3GqEgT6L56L5-J3jOqNxJRKE=.2b68d7d4-2ce4-4230-9ae3-f2cb38bffbf4@github.com>
Message-ID: <o3NyR7DRawHRyef7RnEs4ybyxzET0YH6iHt3bbXaIMI=.d3ba022a-92e9-4d42-8984-335cfd1d75b9@github.com>

On Fri, 21 Mar 2025 10:33:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added needed include
>
> make/StaticLibs.gmk line 117:
> 
>> 115:       OUTPUT_FILE := $(lib).exp, \
>> 116:       COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^\.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \
>> 117:     )) \
> 
> To better align with how we store the targets of Setup calls, can you please change this to:
> 
> Suggestion:
> 
>   STATIC_LIBS := -Wl,-bexpfull $(STATIC_LIB_FILES) $(addprefix -Wl$(COMMA)-bE:, $(STATIC_LIB_EXPORT_FILES))
>   $(foreach lib, $(STATIC_LIB_FILES), \
>     $(eval $(call SetupExecute, generate_export_list_$(notdir $(lib)), \
>       INFO := Generating export list for $(notdir $(lib)), \
>       DEPS :=  $(lib), \
>       OUTPUT_FILE := $(lib).exp, \
>       COMMAND := ( $(AR) $(ARFLAGS) -w $(lib) | $(GREP) -v '^.' | $(AWK) '{print $$1}' | $(SORT) -u > $(lib).exp ), \
>     )) \
>     $(eval   STATIC_LIB_EXPORT_FILES += $(lib).exp) \

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007406147

From jsjolen at openjdk.org  Fri Mar 21 11:49:22 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 21 Mar 2025 11:49:22 GMT
Subject: Withdrawn: 8351875: Remove chunk pools from arena
In-Reply-To: <p7oCIjVnH0cjikZMdtIUjjZSkEW0Q7pisAHpqYGRvyM=.08f776ec-d52c-4462-9a73-17fd15257f48@github.com>
References: <p7oCIjVnH0cjikZMdtIUjjZSkEW0Q7pisAHpqYGRvyM=.08f776ec-d52c-4462-9a73-17fd15257f48@github.com>
Message-ID: <2EV5JE3HRSnputiMKb9dQ5TKRcjgpDewoaXGxcB6Fco=.e002e00b-a479-4845-b102-d9a2c9292a64@github.com>

On Wed, 12 Mar 2025 16:55:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> As per https://bugs.openjdk.org/browse/JDK-8333151 , we can remove the chunk pools without any severe adverse effects. Therefore, I propose that we get rid of them.

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Fri Mar 21 12:04:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 12:04:15 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v3]
In-Reply-To: <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com>
Message-ID: <CUkiqVo3cfoIl-rdisycOEe47-DoXwF4s3eCv1hS2gI=.dd6d0078-079f-4844-822e-4951892fb8d6@github.com>

On Wed, 26 Feb 2025 07:07:38 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23536#pullrequestreview-2705705913

From dholmes at openjdk.org  Fri Mar 21 12:04:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 12:04:17 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v2]
In-Reply-To: <LKuyGZAMtL_wCCxVhV8Eu_29v8mYDq8achjsfvRzbD0=.87d947ca-3b08-4ac0-9392-c4deead18a7a@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <VY8wZOwMgOaNgfKYlYWeb9b2XupI_8oZ8_hmy4i2syY=.86058d22-2c1f-4758-94e3-0a8fb938ced9@github.com>
 <3UP3Nt7_2X9wM8HvHMZDGlMbJmhT2y-_ny4YLnRVQdw=.fd9546d6-14c8-4ee9-a6b4-011d935bd9eb@github.com>
 <zRILbqqqfapzSSqehYXi0aByi7vKRgSmmdZna5jx7Vg=.0bf97ac0-1406-4379-afa8-03b22115fe20@github.com>
 <dQlSzANca3fgrran6u4v4NJL4wmUjzo7SppQLzDLFX4=.2b541d09-96e2-49eb-a97b-0f4b33752e46@github.com>
 <bXiWo1gfSuKU7FpQZyfIi9f4HHIoMvTdur3Lh3-mA7g=.3301a575-da75-448c-8b27-e938fcd37f4c@github.com>
 <Em_-v3GPZk-3ydYC0ZaIj2jklgu0IgCcJ-cVaOBXGVE=.881af30f-47ff-407f-8a73-4356aca5e1a1@github.com>
 <LKuyGZAMtL_wCCxVhV8Eu_29v8mYDq8achjsfvRzbD0=.87d947ca-3b08-4ac0-9392-c4deead18a7a@github.com>
Message-ID: <nC2eIN-bStIQ_EJfcsxl3qvNwlyacIKOulTNb5jJCIY=.5456c847-7972-4e56-b346-e3dea683d762@github.com>

On Fri, 21 Mar 2025 07:41:01 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> Correct. That is a tier2 test and IIUC GHA only runs tier1.
>> 
>> But I'm not sure why you're asking. I was pointing out that the jpackage test uses chcp in a simpler way than you have used, so I was suggesting you simplify your code and see if it still works.
>
> Running TestAvailableProcessors.java in GHA without adding the PATH failed. Additional processing is required to pass GHA.
> Since the jpackage tests are not run in GHA, there is no need to add PATH.

Hmmm .... okay. This is ony a test so if things go wrong we can re-adjust the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2007447250

From dholmes at openjdk.org  Fri Mar 21 12:06:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 12:06:14 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v3]
In-Reply-To: <Vcn7Qcj0eVb0FNrGgM-fzyM2-GLNu2L_mzJWCNu0wSE=.f7ed2f60-e71b-4a5c-b560-6cd9791be3a5@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <Vcn7Qcj0eVb0FNrGgM-fzyM2-GLNu2L_mzJWCNu0wSE=.f7ed2f60-e71b-4a5c-b560-6cd9791be3a5@github.com>
Message-ID: <38TsNdyJdlGSSv_s_dmAzupG9ZFkTSK74fYAjGnnm6M=.56485873-9bf1-4ed8-b88d-23b84f819787@github.com>

On Fri, 21 Mar 2025 09:23:35 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
>> 
>> It has passed tier1-tier8 tests.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second update after review

Nothing further from me. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24078#pullrequestreview-2705712178

From ihse at openjdk.org  Fri Mar 21 12:44:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Mar 2025 12:44:07 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v4]
In-Reply-To: <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>
Message-ID: <9rfZiM27z9h-LAwYXUYSX7nD0dp1oejodRIUT-S8z94=.d5206ba4-18fe-4a88-ad0a-aa3029f2b834@github.com>

On Fri, 21 Mar 2025 11:44:49 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Magnus

The build changes look good to me now. You need to have someone review the hotspot AIX changes as well.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2705808054

From azafari at openjdk.org  Fri Mar 21 13:51:13 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 21 Mar 2025 13:51:13 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v4]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <Yu3gds9e9UGhx_pD72Es5wiibqzO_ZeZlgHMfMSWpQI=.3ab5d5c4-a53b-4c6c-879b-a4369a5b8421@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  separation of commit and reserve wrt stack-index

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24028/files
  - new: https://git.openjdk.org/jdk/pull/24028/files/9415f9c1..cc58a04b

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

  Stats: 142 lines in 3 files changed: 77 ins; 21 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/24028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028

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

From pchilanomate at openjdk.org  Fri Mar 21 14:12:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 21 Mar 2025 14:12:11 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v3]
In-Reply-To: <Vcn7Qcj0eVb0FNrGgM-fzyM2-GLNu2L_mzJWCNu0wSE=.f7ed2f60-e71b-4a5c-b560-6cd9791be3a5@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <Vcn7Qcj0eVb0FNrGgM-fzyM2-GLNu2L_mzJWCNu0wSE=.f7ed2f60-e71b-4a5c-b560-6cd9791be3a5@github.com>
Message-ID: <ih4vjKccBalVOnQKztsyhC9UyP0lwxbScnIUTmDdSXw=.e8d3e282-8045-42e7-bf1e-86f2d9fce992@github.com>

On Fri, 21 Mar 2025 09:23:35 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
>> 
>> It has passed tier1-tier8 tests.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second update after review

Thanks, looks good to me.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24078#pullrequestreview-2706101947

From gziemski at openjdk.org  Fri Mar 21 14:26:07 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 21 Mar 2025 14:26:07 GMT
Subject: RFR: 8341095: Possible overflow in os::Posix::print_uptime_info
In-Reply-To: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>
References: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>
Message-ID: <pCABqjtoZeKEvHWSPlGcwn-XNgcVuz3nvaod0DMxhDI=.fc444fac-b5af-4126-9c2b-7c07eb04108a@github.com>

On Thu, 20 Mar 2025 20:08:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> This is a trivial change that will quiet Xcode only visual warning in os_posix.cpp file.
> 
> There are 31,536,000 seconds in a year, so if int is 32bits, then we have MAX int value of 2,147,483,647 so it would overflow in 68 years - unlikely to affect anyone.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/24140#issuecomment-2743524327

From fbredberg at openjdk.org  Fri Mar 21 14:41:09 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 21 Mar 2025 14:41:09 GMT
Subject: RFR: 8351655: Optimize ObjectMonitor::unlink_after_acquire() [v3]
In-Reply-To: <Vcn7Qcj0eVb0FNrGgM-fzyM2-GLNu2L_mzJWCNu0wSE=.f7ed2f60-e71b-4a5c-b560-6cd9791be3a5@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
 <Vcn7Qcj0eVb0FNrGgM-fzyM2-GLNu2L_mzJWCNu0wSE=.f7ed2f60-e71b-4a5c-b560-6cd9791be3a5@github.com>
Message-ID: <bQ0CtWoet-dzfFDwn3rkw42TM0pIVNRbc2IznPhi8ek=.7dc11879-b1a4-4729-92e6-38b682205ca3@github.com>

On Fri, 21 Mar 2025 09:23:35 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
>> 
>> It has passed tier1-tier8 tests.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second update after review

Thanks for the reviews. I'll integrate after the weekend.

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

PR Comment: https://git.openjdk.org/jdk/pull/24078#issuecomment-2743561750

From mdoerr at openjdk.org  Fri Mar 21 16:02:17 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Mar 2025 16:02:17 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v4]
In-Reply-To: <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <XfUmhEGyZiYqdfEgwSFf0QumAIUEmNc06-hhU6BjDuE=.e41265b0-9054-4fc1-8825-508bf9b7d63d@github.com>
Message-ID: <P-9BgoaWKrfLoPrYt0OZ8sVZ0VQvJ1z61Uzg4Es9GAA=.edcb3b6c-0842-4f74-9b32-4b3cbf0b0989@github.com>

On Fri, 21 Mar 2025 11:44:49 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Magnus

I'm not really familiar with it, but I have some code style requests.

src/hotspot/os/aix/loadlib_aix.cpp line 218:

> 216:     procentry64 PInfo;
> 217:     PInfo.pi_pid = ::getpid();
> 218:     if ( 0 == ::getargs(&PInfo, sizeof(PInfo), (char*)pgmpath,PATH_MAX) && *pgmpath ) {

Coding style: spaces after `(` and before `)` are uncommon, but we should have one before `PATH_MAX`.
I think hotspot style guide compliant would be:
`if (0 == ::getargs(&PInfo, sizeof(PInfo), (char*)pgmpath, PATH_MAX) && *pgmpath != 0)`

src/hotspot/os/aix/loadlib_aix.cpp line 221:

> 219:       pgmpath[PATH_MAX] = '\0';
> 220:       pgmbase = strrchr(pgmpath, '/');
> 221:       if (pgmbase) {

Better: `if (pgmbase != nullptr)`

src/hotspot/os/aix/loadlib_aix.cpp line 222:

> 220:       pgmbase = strrchr(pgmpath, '/');
> 221:       if (pgmbase) {
> 222:         pgmbase +=1;

Maybe add a space: "+= 1"?

src/hotspot/os/aix/loadlib_aix.cpp line 245:

> 243:     lm->data_len = ldi->ldinfo_datasize;
> 244: 
> 245:     if (pgmbase && 0 == strcmp(pgmbase, ldi->ldinfo_filename)) {

`pmgbase != nullptr`

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

PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2706439265
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007864471
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007869385
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007866684
PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2007870732

From jkern at openjdk.org  Fri Mar 21 16:19:38 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 21 Mar 2025 16:19:38 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  follow Martin

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24062/files
  - new: https://git.openjdk.org/jdk/pull/24062/files/9b92eea7..3d9fcafc

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

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

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

From mdoerr at openjdk.org  Fri Mar 21 16:59:14 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Mar 2025 16:59:14 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <w5eKGTMLmT1RmTsu8p2q9pMZzvmBivan_Q1YZq7hzB4=.403f459e-cfd3-46b4-bf51-6fa64c62d081@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

LGTM. Maybe @MBaesken wants to take a look at the AIX code, too?

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2706624142

From jiangli at openjdk.org  Sat Mar 22 03:52:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 22 Mar 2025 03:52:02 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK
Message-ID: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>

Please review following changes, thanks.

- Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:


$ static-jdk/bin/java -version
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)

$ jdk/bin/java -version
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)


Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).

- Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
- Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
- Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.

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

Commit messages:
 - Update copyright year for TestMutuallyExclusivePlatformPredicates.java.
 - Fix jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java failure in GHA https://github.com/jianglizhou/jdk/actions/runs/14003602440#user-content-jdk_test_lib_testmutuallyexclusiveplatformpredicates
 - - Add 'static' to the vm_info string for static JDK.

Changes: https://git.openjdk.org/jdk/pull/24171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24171&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352184
  Stats: 45 lines in 5 files changed: 20 ins; 1 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/24171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24171/head:pull/24171

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

From iklam at openjdk.org  Sat Mar 22 04:58:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 22 Mar 2025 04:58:49 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
Message-ID: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>

Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.

The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.

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

Commit messages:
 - 8352092: -XX:AOTMode=record crashes with InstanceKlass in allocated state

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

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

From varadam at openjdk.org  Sun Mar 23 15:54:44 2025
From: varadam at openjdk.org (Varada M)
Date: Sun, 23 Mar 2025 15:54:44 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
Message-ID: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>

AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes

tier1, tier2 and tier3 testing is successful with fastdebug level

JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

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

Commit messages:
 - AIX: implement attach API v2 and streaming output
 - AIX: implement attach API v2 and streaming output
 - AIX: implement attach API v2 and streaming output
 - AIX: Problem list serviceability/attach/AttachAPIv2/StreamingOutputTest.java

Changes: https://git.openjdk.org/jdk/pull/24177/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352392
  Stats: 279 lines in 2 files changed: 63 ins; 201 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24177/head:pull/24177

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

From liach at openjdk.org  Mon Mar 24 03:32:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Mar 2025 03:32:13 GMT
Subject: RFR: 8351748: Add class init barrier to AOT-cached Method/Var
 Handles [v2]
In-Reply-To: <UpygeU7Cqcx9ebgfjyoKhTWTNKfOwWc6P6nO3Iyu5-w=.88eab0b0-8b12-45ad-be70-767dbf11bdca@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
 <UpygeU7Cqcx9ebgfjyoKhTWTNKfOwWc6P6nO3Iyu5-w=.88eab0b0-8b12-45ad-be70-767dbf11bdca@github.com>
Message-ID: <w2-gG0P-X4Tq09iHOqGVsnDghN8h4R5AsY6SxhQlt18=.d8bf948a-91cc-4a34-a8d7-6e49cc6580e7@github.com>

On Tue, 18 Mar 2025 03:55:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Whenever we store a MethodHandle in the AOT cache, we need to make sure that the class of this method is aot-initialized. Otherwise, the JVM might execute a BSM without first initializing the class of this BSM.
>> 
>> Please see the bug report for detail analysis.
>> 
>> I also fixed a problem in related logging code.
>
> Ioi Lam 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:
> 
>  - clean up
>  - Merge branch 'master' into 8351748-classes-of-cached-method-handles-should-be-aot-inited
>  - Added CDS::needsClassInitBarrier() for adding init barriers to cached Method/Var Handles
>  - Merge branch 'master' into 8351748-classes-of-cached-method-handles-should-be-aot-inited
>  - Experiment: always include init barriers in cached MethodHandle/VarHandle
>  - 8351748: Classes of method handles in the AOT cache should be AOT-initialized

The explicit core-libs barriers should be sufficient to ensure MemberName instances all have ResolvedMethodName that refers to initialized classes.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24004#pullrequestreview-2709027757

From iklam at openjdk.org  Mon Mar 24 06:45:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 24 Mar 2025 06:45:14 GMT
Subject: RFR: 8351748: Add class init barrier to AOT-cached Method/Var
 Handles
In-Reply-To: <uzl4WFzLCg7zeft4ReCaDo1t6bU6tltF_lAbZuNwKqc=.42c7bcb6-2b32-4987-a06e-959f871a0b5c@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
 <FwKw8opuRkyezr91r0Js-alkd45s-agiHOjNep5s0yU=.c567796f-b4c7-4b65-940d-3b44b3a82c42@github.com>
 <LXfsmbgnSaiP4-UMtsLhCyIWMgykL5Sq87PI641FEZ4=.1c610b7b-f2f8-4316-8c5f-97a20271663e@github.com>
 <uzl4WFzLCg7zeft4ReCaDo1t6bU6tltF_lAbZuNwKqc=.42c7bcb6-2b32-4987-a06e-959f871a0b5c@github.com>
Message-ID: <YFDoWfVXVFOsPqL6oI6OE-jkqNs8PuwpxSZ15E1UyU4=.5e81110a-039f-45c8-80eb-620afee8cc50@github.com>

On Thu, 13 Mar 2025 16:51:36 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> IMO a safer alternative is to unconditionally keep all clinit barriers during assembly phase (irrespective of whether relevant class is initialized or not).
>> 
>> Could you elaborate how this can be done?
>
>> Could you elaborate how this can be done?
> 
> For `MethodHandle`s `DirectMethodHandle.shouldBeInitialized(Class)` determines whether a barrier is needed or not. It can be tweaked to behave conservatively during assembly phase and report `true` irrespective of whether the target class is initialized or not. (And it can take AOT-inited classes into account as well.) 
> 
> (`VarHandle`s use `Unsafe.shouldBeInitialized(Class)` directly.)

Thanks @iwanowww @liach for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/24004#issuecomment-2747045729

From iklam at openjdk.org  Mon Mar 24 06:45:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 24 Mar 2025 06:45:15 GMT
Subject: Integrated: 8351748: Add class init barrier to AOT-cached Method/Var
 Handles
In-Reply-To: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
References: <A8pq-Oxua6IEfHrH8uuXljUnNkO3xNMMYZqat0l5iF0=.19840b66-5f80-4a46-84de-2d0961a8c752@github.com>
Message-ID: <z_sDjv8y1x0LXBtAiTa3PgJTCwGCFtudI9HgfTOSgZU=.445df8b3-e0a7-4feb-8ec8-20e9da3e1c80@github.com>

On Wed, 12 Mar 2025 04:09:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Whenever we store a MethodHandle in the AOT cache, we need to make sure that the class of this method is aot-initialized. Otherwise, the JVM might execute a BSM without first initializing the class of this BSM.
> 
> Please see the bug report for detail analysis.
> 
> I also fixed a problem in related logging code.

This pull request has now been integrated.

Changeset: adfb1206
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/adfb1206498987f43a4cf0cd6ba0cb6a5bb8e479
Stats:     402 lines in 14 files changed: 380 ins; 5 del; 17 mod

8351748: Add class init barrier to AOT-cached Method/Var Handles

Reviewed-by: vlivanov, liach

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

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

From dholmes at openjdk.org  Mon Mar 24 06:53:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Mar 2025 06:53:07 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
Message-ID: <2CC-bji6jxt9m83WbtfB5AU_5pldkXJMe9brC5BoMo0=.75976be4-b0e5-4f28-a4a6-923ea3b48043@github.com>

On Sat, 22 Mar 2025 04:39:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
> 
> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.

I can't convince myself this is the right place to fix this.

If we attempt to use `DefineClass` for a class in an illegal package, it will fail won't it? In which case how do we end up with any `instanceKlass` object to archive? Shouldn't it be  deleted, assuming it ever got created? And if it was created do we really want to archive classes that are not even loaded?

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

PR Review: https://git.openjdk.org/jdk/pull/24172#pullrequestreview-2709280437

From dholmes at openjdk.org  Mon Mar 24 07:05:13 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Mar 2025 07:05:13 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK
In-Reply-To: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
Message-ID: <kIRnI3h867XxJOk1InvQ3-bcM2_zJKJE4gxnWHA83wE=.2de7e07c-ed8e-424b-a39d-b8760e4235f6@github.com>

On Sat, 22 Mar 2025 03:46:38 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review following changes, thanks.
> 
> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
> 
> 
> $ static-jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
> 
> $ jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
> 
> 
> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
> 
> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.

The way we construct the VM info string is rather clunky and does not scale when you want to add more information like this. Short of rewriting it to dynamically create the final string from its constituent parts, couldn't this change more simply replace the return statements with an assignment to a local and then append static if needed i.e something like:

char* ret;
...
ret = CDSConfig::is_using_archive() ? "interpreted mode, sharing" : "interpreted mode";
...
// If static then append static
if (is_vm_statically_linked() {
  const char* static_str = ", static";
  const char* buf = malloc(strlen(ret) + strlen(static_str);
  strcpy(buf, ret);
  strcat(buf, static_str);
}

??

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

PR Review: https://git.openjdk.org/jdk/pull/24171#pullrequestreview-2709300484

From iklam at openjdk.org  Mon Mar 24 07:08:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 24 Mar 2025 07:08:17 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <2CC-bji6jxt9m83WbtfB5AU_5pldkXJMe9brC5BoMo0=.75976be4-b0e5-4f28-a4a6-923ea3b48043@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <2CC-bji6jxt9m83WbtfB5AU_5pldkXJMe9brC5BoMo0=.75976be4-b0e5-4f28-a4a6-923ea3b48043@github.com>
Message-ID: <HQpEBCu7VWia-TFdfOqXrpHBkpcRM2DNgMr9djEhSoU=.399c7ab6-1a92-4c72-b573-c6cf554cb212@github.com>

On Mon, 24 Mar 2025 06:50:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I can't convince myself this is the right place to fix this.
> 
> If we attempt to use `DefineClass` for a class in an illegal package, it will fail won't it? In which case how do we end up with any `instanceKlass` object to archive? Shouldn't it be deleted, assuming it ever got created? And if it was created do we really want to archive classes that are not even loaded?

The affected code in this PR is not choosing what classes to be archived. Instead, it's just going through all live classes and tries to eagerly link them.

Classes that are not in the `loaded` state are filtered out from the archive by this code:

https://github.com/openjdk/jdk/blob/adfb1206498987f43a4cf0cd6ba0cb6a5bb8e479/src/hotspot/share/classfile/systemDictionaryShared.cpp#L289-L291

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

PR Comment: https://git.openjdk.org/jdk/pull/24172#issuecomment-2747085114

From dholmes at openjdk.org  Mon Mar 24 07:24:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Mar 2025 07:24:16 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <HQpEBCu7VWia-TFdfOqXrpHBkpcRM2DNgMr9djEhSoU=.399c7ab6-1a92-4c72-b573-c6cf554cb212@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <2CC-bji6jxt9m83WbtfB5AU_5pldkXJMe9brC5BoMo0=.75976be4-b0e5-4f28-a4a6-923ea3b48043@github.com>
 <HQpEBCu7VWia-TFdfOqXrpHBkpcRM2DNgMr9djEhSoU=.399c7ab6-1a92-4c72-b573-c6cf554cb212@github.com>
Message-ID: <MKaQLWvwOa2-vgbPSVT_WX-aUEdrphhJC5n_L8pyg1E=.09661a98-d1fd-47c9-9d3e-f894cbf0367f@github.com>

On Mon, 24 Mar 2025 07:05:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > I can't convince myself this is the right place to fix this.
> > If we attempt to use `DefineClass` for a class in an illegal package, it will fail won't it? In which case how do we end up with any `instanceKlass` object to archive? Shouldn't it be deleted, assuming it ever got created? And if it was created do we really want to archive classes that are not even loaded?
> 
> The affected code in this PR is not choosing what classes to be archived. Instead, it's just going through all live classes and tries to eagerly link them.
> 
> Classes that are not in the `loaded` state are filtered out from the archive by this code:
> 
> https://github.com/openjdk/jdk/blob/adfb1206498987f43a4cf0cd6ba0cb6a5bb8e479/src/hotspot/share/classfile/systemDictionaryShared.cpp#L289-L291

Sorry then I don't understand how we get into the state that this PR is trying to fix. ???

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

PR Comment: https://git.openjdk.org/jdk/pull/24172#issuecomment-2747116173

From dzhang at openjdk.org  Mon Mar 24 07:43:09 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 24 Mar 2025 07:43:09 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
Message-ID: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>

Hi all,
After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:

log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");


Testing on QEMU before this PR:

$ uname -a
Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux

$ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
     bool UseRVV = false {ARCH diagnostic} {default}
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)

$ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
     bool UseRVV = false {ARCH diagnostic} {command line}
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)

$ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
[0.024s][info][os] Use of CLOCK_MONOTONIC is supported
[0.026s][info][os] Use of pthread_condattr_setclock is supported
[0.026s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
[0.027s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
[0.027s][info][os] Glibc stack size guard page adjustment is not needed
[0.029s][info][os] SafePoint Polling address, bad (protected) page:0x00007ff8a7349000, good (unprotected) page:0x00007ff8a734a000
[0.044s][info][os] attempting shared library load of /home/ubuntu/jdk-rvv-before/lib/libjava.so
[0.047s][info][os] shared library load of /home/ubuntu/jdk-rvv-before/lib/libjava.so was successful
[0.052s][info][os] Linux kernels before 6.8.5 (current 6.8.0) have a known bug when using Vector and signals.
[0.052s][info][os] Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.
OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
[0.748s][info][os] Initialized VM with process ID 33279
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)


Testing on QEMU after this PR:

$ uname -a
Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux

$ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
     bool UseRVV                                   = false                             {ARCH diagnostic} {default}
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)

$ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
     bool UseRVV                                   = true                              {ARCH diagnostic} {command line}
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)


In addition, manual tested 6.11 as expected.

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

Commit messages:
 - 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV

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

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

From duke at openjdk.org  Mon Mar 24 07:45:19 2025
From: duke at openjdk.org (duke)
Date: Mon, 24 Mar 2025 07:45:19 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v3]
In-Reply-To: <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com>
Message-ID: <rWD3ufFTQb4g3J0UvQBDPC9ehGoTKxArOiR1sBOVYlU=.323c8603-074f-4408-ac77-85343b8c9696@github.com>

On Wed, 26 Feb 2025 07:07:38 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

@ktakakuri 
Your change (at version 890f01350e106d0533e178e7d1c9f83b7d918ea9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2747175988

From azafari at openjdk.org  Mon Mar 24 08:58:54 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 24 Mar 2025 08:58:54 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v5]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <cyB6mNmb1WFVRFcb0dJ8v52fgyc7V0nUAWhsp-WlYXI=.6904fcfb-09ef-4084-98b6-68fd28f2f760@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  more fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24028/files
  - new: https://git.openjdk.org/jdk/pull/24028/files/cc58a04b..599eaa04

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

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

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

From rehn at openjdk.org  Mon Mar 24 09:16:06 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 24 Mar 2025 09:16:06 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
In-Reply-To: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
Message-ID: <GEEU9w3Vs6qNgZCWHGODe9p5vYkoN_H0u6ZDHKI6zIM=.f46ed2c2-b052-4bf1-97bc-680489abac44@github.com>

On Mon, 24 Mar 2025 07:37:06 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
> 
> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
> 
> 
> Testing on QEMU before this PR:
> 
> $ uname -a
> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
> [0.022s][info][os] Use of pthread_condattr_setclock is supported
> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe67000
> [0.040s][info][os] attempting shared library load of /home/ubuntu/jdk-rvv...

Thanks for finding!

The code your patching is only suppose not to enable it via hwprobe, which it do.
If you want to allow RVV even do the kernel do not support I think it's better to change this code:

  if (UseRVV) {
    if (!ext_V.enabled()) {
      warning("RVV is not supported on this CPU");
      FLAG_SET_DEFAULT(UseRVV, false);

Which is the actual code that turns off RVV.

E.g. there is no issue turning on -XX:+UseZbb even of ext_Zbb is false.

Maybe the Linux version check is placed wrong, and should not be in hwprobe?

Note: I also think you need a FLAG_IS_DEFAULT, as we only want to turn it on if it is set by user.

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

PR Comment: https://git.openjdk.org/jdk/pull/24182#issuecomment-2747394215

From gziemski at openjdk.org  Mon Mar 24 10:11:20 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 24 Mar 2025 10:11:20 GMT
Subject: Withdrawn: 8301404: Replace os::malloc with os::realloc,
 so we only have 1 code path
In-Reply-To: <-wGc_naQpZeZA9rOjHoui1owsSOzdRmasEvq6xNkh8E=.60b7b9b2-f9ca-49a7-9136-b5a4062dfc34@github.com>
References: <-wGc_naQpZeZA9rOjHoui1owsSOzdRmasEvq6xNkh8E=.60b7b9b2-f9ca-49a7-9136-b5a4062dfc34@github.com>
Message-ID: <NpP1YjoaQ-bhdZxRNjkuFY-dSs4TFJOzjXEzdLanxQk=.33106c53-4acd-4327-81a2-6784267f54fb@github.com>

On Tue, 11 Mar 2025 18:33:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from https://github.com/openjdk/jdk/pull/23786):
> 
> proposed:
> 
> 
> time:72,642,827[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> 
> 
> existing code:
> 
> 
> time:73,085,446[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> 
> 
> Note: the NMTBenchmark reports `realloc(nullptr)` as `mallocs()`, which is why both versions show the same count for `mallocs/reallocs`.
> 
> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
> 
> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
> 
> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

This pull request has been closed without being integrated.

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

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

From rkennke at openjdk.org  Mon Mar 24 11:18:54 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 24 Mar 2025 11:18:54 GMT
Subject: RFR: 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable
Message-ID: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>

- When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
- When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
- In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
- Some small code shufflings.

I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
without-OMT: 773.3 ms
with-OMT: 797.28 ms

That is still a regression of ~3%

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

Commit messages:
 - Use read_monitor(mark)
 - Remove _hit variable
 - 8339114: DaCapo xalan performance with -XX:+UseObjectMonitorTable

Changes: https://git.openjdk.org/jdk/pull/24098/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339114
  Stats: 52 lines in 6 files changed: 31 ins; 6 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24098/head:pull/24098

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

From coleenp at openjdk.org  Mon Mar 24 11:18:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Mar 2025 11:18:54 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable
In-Reply-To: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
Message-ID: <KjsQAmJcI5GvU2oRkvyGJx_a-RRmN3n3nf77szTtjaI=.6e092298-c5b2-4b10-9e4c-b05ef840bc6e@github.com>

On Tue, 18 Mar 2025 12:41:44 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
> - Some small code shufflings.
> 
> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
> without-OMT: 773.3 ms
> with-OMT: 797.28 ms
> 
> That is still a regression of ~3%

I had a couple of comments but it's similar to what I have.  I didn't use the BasicLock though for quick_enter and this hit variable is a bit confusing why it's there.  I'm going to ask Eric to run our benchmarks on my similar version.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 759:

> 757:     }
> 758:   } else {
> 759:     monitor = ObjectSynchronizer::read_monitor(current, object, mark);

This can just be read_monitor(mark).

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1236:

> 1234: 
> 1235:     if (UseObjectMonitorTable) {
> 1236:       lock->set_object_monitor_cache(monitor);

I hit a bug where this was a deflating monitor so I don't think we can do this.

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

PR Review: https://git.openjdk.org/jdk/pull/24098#pullrequestreview-2694424229
PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2000986680
PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2000989920

From rkennke at openjdk.org  Mon Mar 24 11:18:55 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 24 Mar 2025 11:18:55 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable
In-Reply-To: <HZ2DrySldFuiBRb88TYV23NSa5NlCzN1qpYog2CdFP4=.f6d9e803-ab98-4073-a6f8-d15def7e8452@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <KjsQAmJcI5GvU2oRkvyGJx_a-RRmN3n3nf77szTtjaI=.6e092298-c5b2-4b10-9e4c-b05ef840bc6e@github.com>
 <HZ2DrySldFuiBRb88TYV23NSa5NlCzN1qpYog2CdFP4=.f6d9e803-ab98-4073-a6f8-d15def7e8452@github.com>
Message-ID: <bYOO0TbWMbxz5uswJuf2ou5EPIvmZ3cX8d1uuRQ4yi0=.bee7fc37-92f3-438d-9cf0-e328235c89be@github.com>

On Tue, 18 Mar 2025 13:05:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1236:
>> 
>>> 1234: 
>>> 1235:     if (UseObjectMonitorTable) {
>>> 1236:       lock->set_object_monitor_cache(monitor);
>> 
>> I hit a bug where this was a deflating monitor so I don't think we can do this.
>
> runtime/Monitor/UseObjectMonitorTableTest.java#ExtremeDeflation
> This test failed when I updated the monitor via CacheSetter when we don't succeed to get the lock.

I am not sure if I understand the problem. Why can't we do that? We successfully looked up the monitor from the OMCache, why can't we stick it in the BasicLock cache, to avoid having to look it up in the OMCache again? Whatever code would pull it out of the BasicLock and observe a deflating monitor might also pull it out of the OMCache and observe a deflating monitor, or is that not correct? I know that OMCache::get_monitor() filters deflating monitors, but that is not a guarantee that a monitor would not flip to deflating after that check? So ... the user of the monitor would always have to deal with deflation after it has pulled a monitor from any of the caches anyway?

If it is our contract that only successfully locked monitors go into the BasicLock cache, then we can't do that optimization, I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2002563114

From coleenp at openjdk.org  Mon Mar 24 11:18:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Mar 2025 11:18:55 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable
In-Reply-To: <KjsQAmJcI5GvU2oRkvyGJx_a-RRmN3n3nf77szTtjaI=.6e092298-c5b2-4b10-9e4c-b05ef840bc6e@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <KjsQAmJcI5GvU2oRkvyGJx_a-RRmN3n3nf77szTtjaI=.6e092298-c5b2-4b10-9e4c-b05ef840bc6e@github.com>
Message-ID: <HZ2DrySldFuiBRb88TYV23NSa5NlCzN1qpYog2CdFP4=.f6d9e803-ab98-4073-a6f8-d15def7e8452@github.com>

On Tue, 18 Mar 2025 12:58:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
>> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
>> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
>> - Some small code shufflings.
>> 
>> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
>> without-OMT: 773.3 ms
>> with-OMT: 797.28 ms
>> 
>> That is still a regression of ~3%
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1236:
> 
>> 1234: 
>> 1235:     if (UseObjectMonitorTable) {
>> 1236:       lock->set_object_monitor_cache(monitor);
> 
> I hit a bug where this was a deflating monitor so I don't think we can do this.

runtime/Monitor/UseObjectMonitorTableTest.java#ExtremeDeflation
This test failed when I updated the monitor via CacheSetter when we don't succeed to get the lock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2001001683

From coleenp at openjdk.org  Mon Mar 24 11:18:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Mar 2025 11:18:55 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable
In-Reply-To: <bYOO0TbWMbxz5uswJuf2ou5EPIvmZ3cX8d1uuRQ4yi0=.bee7fc37-92f3-438d-9cf0-e328235c89be@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <KjsQAmJcI5GvU2oRkvyGJx_a-RRmN3n3nf77szTtjaI=.6e092298-c5b2-4b10-9e4c-b05ef840bc6e@github.com>
 <HZ2DrySldFuiBRb88TYV23NSa5NlCzN1qpYog2CdFP4=.f6d9e803-ab98-4073-a6f8-d15def7e8452@github.com>
 <bYOO0TbWMbxz5uswJuf2ou5EPIvmZ3cX8d1uuRQ4yi0=.bee7fc37-92f3-438d-9cf0-e328235c89be@github.com>
Message-ID: <HE0ufRqFtSHREnSydlbsJiEMp4GteCYlef1X8FhId84=.2eb23060-825f-47ca-8fd0-7f0d9248c513@github.com>

On Wed, 19 Mar 2025 07:05:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> runtime/Monitor/UseObjectMonitorTableTest.java#ExtremeDeflation
>> This test failed when I updated the monitor via CacheSetter when we don't succeed to get the lock.
>
> I am not sure if I understand the problem. Why can't we do that? We successfully looked up the monitor from the OMCache, why can't we stick it in the BasicLock cache, to avoid having to look it up in the OMCache again? Whatever code would pull it out of the BasicLock and observe a deflating monitor might also pull it out of the OMCache and observe a deflating monitor, or is that not correct? I know that OMCache::get_monitor() filters deflating monitors, but that is not a guarantee that a monitor would not flip to deflating after that check? So ... the user of the monitor would always have to deal with deflation after it has pulled a monitor from any of the caches anyway?
> 
> If it is our contract that only successfully locked monitors go into the BasicLock cache, then we can't do that optimization, I think.

Maybe this is okay.  My change that ran afoul of this test found the monitor in the first 32 entries of the ObjectSynchronizer::_in_use_list and filtered for deflating monitors also.  Then put the monitor it found in the OMCache. Since it didn't help performance, I backed this out of my change. It may be safer to put the monitor in the BasicLock field because it's cleared.  All this to say, I don't really know if this is right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2003116787

From jkern at openjdk.org  Mon Mar 24 13:56:06 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 24 Mar 2025 13:56:06 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <9b9bUZ6_i0Mcb9N-zZXblDBTXKjGo8cbZnzIANaFVzk=.5823939c-56fc-4066-9b30-c162e4ae6929@github.com>

On Sun, 23 Mar 2025 14:33:36 GMT, Varada M <varadam at openjdk.org> wrote:

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

Hi Varada, it looks to me that with your change you've brought the AIX code closer to the POSIX implementation, but not completely. Could you please explain your changes in detail so I can review the PR? I'm not that familiar with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2748211872

From dzhang at openjdk.org  Mon Mar 24 14:00:34 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 24 Mar 2025 14:00:34 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
 [v2]
In-Reply-To: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
Message-ID: <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>

> Hi all,
> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
> 
> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
> 
> 
> Testing on QEMU before this PR:
> 
> $ uname -a
> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
> [0.022s][info][os] Use of pthread_condattr_setclock is supported
> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe67000
> [0.040s][info][os] attempting shared library load of /home/ubuntu/jdk-rvv...

Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:

  Fix the issue in vm_version_riscv.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24182/files
  - new: https://git.openjdk.org/jdk/pull/24182/files/c8b1739c..5c01052c

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

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

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

From dzhang at openjdk.org  Mon Mar 24 14:00:34 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Mon, 24 Mar 2025 14:00:34 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
In-Reply-To: <GEEU9w3Vs6qNgZCWHGODe9p5vYkoN_H0u6ZDHKI6zIM=.f46ed2c2-b052-4bf1-97bc-680489abac44@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
 <GEEU9w3Vs6qNgZCWHGODe9p5vYkoN_H0u6ZDHKI6zIM=.f46ed2c2-b052-4bf1-97bc-680489abac44@github.com>
Message-ID: <DPXC_08igvDQyfC7dn5eTB1zkI8nzNEciCfKiYYHzPU=.2c97bf44-debc-4f52-b58d-f2d3bfcb6fd1@github.com>

On Mon, 24 Mar 2025 09:11:48 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi all,
>> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
>> 
>> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
>> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
>> 
>> 
>> Testing on QEMU before this PR:
>> 
>> $ uname -a
>> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
>> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
>> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
>> [0.022s][info][os] Use of pthread_condattr_setclock is supported
>> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
>> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
>> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
>> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe670...
>
> Thanks for finding!
> 
> The code your patching is only suppose not to enable it via hwprobe, which it do.
> If you want to allow RVV even do the kernel do not support I think it's better to change this code:
> 
>   if (UseRVV) {
>     if (!ext_V.enabled()) {
>       warning("RVV is not supported on this CPU");
>       FLAG_SET_DEFAULT(UseRVV, false);
> 
> Which is the actual code that turns off RVV.
> 
> E.g. there is no issue turning on -XX:+UseZbb even of ext_Zbb is false.
> 
> Maybe the Linux version check is placed wrong, and should not be in hwprobe?
> 
> Note: I also think you need a FLAG_IS_DEFAULT, as we only want to turn it on if it is set by user.

Hi @robehn 
Thank you for your response! I have updated the code.
When the kernel version is greater than 6.6, the test results are the same as [here](https://github.com/openjdk/jdk/pull/24182#issue-2942299437). 
However, when the kernel version is less than 6.6, the test results are as follows:

$ uname -a
Linux ubuntu 5.19.0-1012-generic #13~22.04.1-Ubuntu SMP Thu Jan 12 15:34:31 UTC 2023 riscv64 riscv64 riscv64 GNU/Linux

$ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
     bool UseRVV                                   = false                             {ARCH diagnostic} {default}
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)

$ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x00007fff8dea1d50, pid=5090, tid=5091
#
# JRE version:  (25.0) (build )
# Java VM: OpenJDK 64-Bit Server VM (25-internal-adhoc.zhangdingli.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-riscv64)
# Problematic frame:
# V  [libjvm.so+0xca1d50]  VM_Version::cpu_vector_length()+0x6
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/ubuntu/jdk-enable-rvv/bin/core.5090)
#
# An error report file with more information is saved as:
# /home/ubuntu/jdk-enable-rvv/bin/hs_err_pid5090.log
#
#
Aborted (core dumped)

$ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
     bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
openjdk version "25-internal" 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)


If more extensive changes and a better approach are needed, I'll be happy to close this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24182#issuecomment-2748219275

From duke at openjdk.org  Mon Mar 24 14:15:27 2025
From: duke at openjdk.org (Zihao Lin)
Date: Mon, 24 Mar 2025 14:15:27 GMT
Subject: RFR: 8350429: runtime/NMT/CheckForProperDetailStackTrace.java should
 only run for debug JVM
Message-ID: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>

runtime/NMT/CheckForProperDetailStackTrace.java should only run for debug JVM

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

Commit messages:
 - 8350429: runtime/NMT/CheckForProperDetailStackTrace.java should only run for debug JVM

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

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

From mbaesken at openjdk.org  Mon Mar 24 14:33:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 14:33:16 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

Regarding BitmapToYXBandedRectangles  from splashscreen, couldn't we just rename it to avoid clashes/issues with the other one from awt with the same name but other signature?
But this can be done in another issue/PR not here.

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

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748329252

From stuefe at openjdk.org  Mon Mar 24 14:39:07 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 24 Mar 2025 14:39:07 GMT
Subject: RFR: 8350429: runtime/NMT/CheckForProperDetailStackTrace.java
 should only run for debug JVM
In-Reply-To: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>
References: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>
Message-ID: <5prsL_DEMotGa1YYIKvmcPKaxZ525zYYM3wFLxC7N70=.5d98b268-637a-4518-803b-40aed41d03e9@github.com>

On Mon, 24 Mar 2025 14:10:21 GMT, Zihao Lin <duke at openjdk.org> wrote:

> runtime/NMT/CheckForProperDetailStackTrace.java should only run for debug JVM

Good.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24198#pullrequestreview-2710622565

From jsjolen at openjdk.org  Mon Mar 24 14:39:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 24 Mar 2025 14:39:07 GMT
Subject: RFR: 8350429: runtime/NMT/CheckForProperDetailStackTrace.java
 should only run for debug JVM
In-Reply-To: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>
References: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>
Message-ID: <OoNIFEm5rwY-Ag0ZB6G6xSa7m9ocr7UbaqShWFmQpyI=.d07e7936-d12b-47d5-8c51-cfc12f091c8f@github.com>

On Mon, 24 Mar 2025 14:10:21 GMT, Zihao Lin <duke at openjdk.org> wrote:

> runtime/NMT/CheckForProperDetailStackTrace.java should only run for debug JVM

LGTM

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24198#pullrequestreview-2710624008

From mbaesken at openjdk.org  Mon Mar 24 14:40:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 14:40:15 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <KypvNQV9tJHTctzcvnrlJUzQ-M2Zt66UJI0aO2cnsuw=.55911462-d051-4853-950a-20c374ee52e8@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

src/hotspot/os/aix/loadlib_aix.cpp line 245:

> 243:     lm->data_len = ldi->ldinfo_datasize;
> 244: 
> 245:     if (pgmbase != nullptr && 0 == strcmp(pgmbase, ldi->ldinfo_filename)) {

Maybe better `strcmp(...) == 0 ` this is what we use almost everywhere in the HS codebase .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24062#discussion_r2010314259

From duke at openjdk.org  Mon Mar 24 14:44:06 2025
From: duke at openjdk.org (duke)
Date: Mon, 24 Mar 2025 14:44:06 GMT
Subject: RFR: 8350429: runtime/NMT/CheckForProperDetailStackTrace.java
 should only run for debug JVM
In-Reply-To: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>
References: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>
Message-ID: <G4yg-ivtj8KNtA6bNZWRX0uaJc9oFH2SXV7DMubhZws=.be3f10b6-a629-4458-9c5d-2ea249356658@github.com>

On Mon, 24 Mar 2025 14:10:21 GMT, Zihao Lin <duke at openjdk.org> wrote:

> runtime/NMT/CheckForProperDetailStackTrace.java should only run for debug JVM

@linzihao1999 
Your change (at version d21925e132cef083333c1cfee6765544903b66c3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24198#issuecomment-2748368714

From mbaesken at openjdk.org  Mon Mar 24 14:47:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 14:47:16 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <8TwaUDdIMp-LNCl2y4Yujed7OooXrKcCAw80VMVQVKc=.fe956a84-6f75-4273-86fd-cde786fce017@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

Looks okay, small nit inside. I would prefer more self explaining variable names like program_full_path , program_base_name  but up to you!

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24062#pullrequestreview-2710649870

From rehn at openjdk.org  Mon Mar 24 15:08:07 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 24 Mar 2025 15:08:07 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
 [v2]
In-Reply-To: <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
 <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
Message-ID: <3ek8KH_XK1F22XGNhOxUe_ZR1Lf4C-QqQCD75F34zlk=.58d61f18-0254-4c75-88dc-c783a703e3f2@github.com>

On Mon, 24 Mar 2025 14:00:34 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi all,
>> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
>> 
>> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
>> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
>> 
>> 
>> Testing on QEMU before this PR:
>> 
>> $ uname -a
>> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
>> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
>> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
>> [0.022s][info][os] Use of pthread_condattr_setclock is supported
>> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
>> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
>> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
>> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe670...
>
> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the issue in vm_version_riscv.cpp

Ok, sure, thanks! Let's go with this!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24182#pullrequestreview-2710722621

From shade at openjdk.org  Mon Mar 24 15:26:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Mar 2025 15:26:09 GMT
Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event
 notification path [v2]
In-Reply-To: <HIhyzeUNfN7lZ_iC5UUSOLOJ-fxX91kRxzlVO5l54js=.142cdeef-744e-4cdf-b673-e9753c6b32fb@github.com>
References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
 <avm3Eryk_oLRKwaT4i91PkQDfcjK8pDx4eq2q9f74sg=.6f198a8f-935a-4416-8192-1e5b2448a4c4@github.com>
 <HIhyzeUNfN7lZ_iC5UUSOLOJ-fxX91kRxzlVO5l54js=.142cdeef-744e-4cdf-b673-e9753c6b32fb@github.com>
Message-ID: <d7wr-YyGUplzrvsnCjaXDC1ViOIaMBZMFOlLZO0Qr14=.3cea3650-6235-4101-99a6-211af2be5689@github.com>

On Thu, 20 Mar 2025 08:39:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>  I'll run all tests with monitor notification event enabled.

I see no new failures. There are some pre-existing bugs with JFR enabled, but nothing new. So with that, and another sweep through the code, I think we are fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/24097#issuecomment-2748515753

From ihse at openjdk.org  Mon Mar 24 15:30:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Mar 2025 15:30:17 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
 <6XwigpjytKtcjl2Zr1Nm1l8d64AiQaE-o1s_VUh0U4Q=.5dc704e1-3eae-4ed0-8b4f-811554fd680c@github.com>
Message-ID: <QeXUxCvo2u-8k_Yo6ERC2FBX3ZwWyAb1m4eSSRSVKkU=.60d05c16-f0bb-4d07-82bd-a029a8e30d29@github.com>

On Mon, 24 Mar 2025 14:30:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Regarding BitmapToYXBandedRectangles from splashscreen, couldn't we just rename it to avoid clashes/issues with the other one from awt with the same name but other signature?
But this can be done in another issue/PR not here.

Indeed we could. Note that the same issue apply to all unix platforms. It's sort of a hack -- the core problem is that we cannot hide non-exported symbols in static libraries. Solving that is the long-term goal, but it is tricky on several platforms.

It could make sense to try to unify the two versions of BitmapToYXBandedRectangles as well; they are similar but not identical (but I can't really tell why).

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

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748527590

From iklam at openjdk.org  Mon Mar 24 15:40:07 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 24 Mar 2025 15:40:07 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <MKaQLWvwOa2-vgbPSVT_WX-aUEdrphhJC5n_L8pyg1E=.09661a98-d1fd-47c9-9d3e-f894cbf0367f@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <2CC-bji6jxt9m83WbtfB5AU_5pldkXJMe9brC5BoMo0=.75976be4-b0e5-4f28-a4a6-923ea3b48043@github.com>
 <HQpEBCu7VWia-TFdfOqXrpHBkpcRM2DNgMr9djEhSoU=.399c7ab6-1a92-4c72-b573-c6cf554cb212@github.com>
 <MKaQLWvwOa2-vgbPSVT_WX-aUEdrphhJC5n_L8pyg1E=.09661a98-d1fd-47c9-9d3e-f894cbf0367f@github.com>
Message-ID: <T3mCEKocybeiEe-1IuPZO5unwjJIrp6Yv9tgfz-iIkU=.1b5a7090-e36a-4aad-a52c-f17531d32dea@github.com>

On Mon, 24 Mar 2025 07:21:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry then I don't understand how we get into the state that this PR is trying to fix. ???

When ClassFileParser is parsing a class with the name `"java/foo/ABC"` for  the application class loader, we first come to this line that adds the class into the ClassLoaderData of the app loader:

https://github.com/openjdk/jdk/blob/5709f79cf86d532b38133a7fc11e6388af573723/src/hotspot/share/classfile/classFileParser.cpp#L5017

Later, we find out that the package is prohibited:

https://github.com/openjdk/jdk/blob/5709f79cf86d532b38133a7fc11e6388af573723/src/hotspot/share/classfile/classFileParser.cpp#L5104

The class loading process stops there with an exception, but the failed class remains in the ClassLoaderData.

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

PR Comment: https://git.openjdk.org/jdk/pull/24172#issuecomment-2748559174

From mbaesken at openjdk.org  Mon Mar 24 15:49:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Mar 2025 15:49:20 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
Message-ID: <GU2PXj5ZoTpNwQDZP2GwAe5ks6cuzZ4nrlUwLWh3lPk=.395b8864-3a91-4c1b-a77f-932a5b87abd4@github.com>

On Fri, 21 Mar 2025 16:19:38 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
>> 
>> Now with this change we can enable the statically linked launcher target again.
>> There are 3 things to do.
>> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
>> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
>> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   follow Martin

Seems we use already a bit of functionality from common/awt in the splashscreen lib

140 ifeq ($(ENABLE_HEADLESS_ONLY), false)
141   LIBSPLASHSCREEN_EXTRA_SRC := \
142       common/awt/systemscale \
143       #
144 
145   LIBSPLASHSCREEN_HEADER_DIRS := \
146       common/awt/utility \

maybe it would make sense to centralize the BitmapToYXBandedRectangles   there and reuse it from there?

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

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748584904

From jkern at openjdk.org  Mon Mar 24 16:18:15 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 24 Mar 2025 16:18:15 GMT
Subject: Integrated: 8352064: AIX: now also able to build static-jdk image with
 a statically linked launcher
In-Reply-To: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
Message-ID: <Sclu8dIThAHf2ZLAEMrVPsQY-NEdij5ILJBGmhjwHLE=.8de68110-57f0-4308-80cf-5037f039bf38@github.com>

On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> After "JDK-8339480: Build static-jdk image with a statically linked launcher" AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make all' fails after JDK-8339480" the new target was disabled again.
> 
> Now with this change we can enable the statically linked launcher target again.
> There are 3 things to do.
> 1.	Modify `dladdr()`. Because this API does not exist on AIX it is implemented based on the `loadquery()` API. Unfortunately, this API does only return the name of the executable, but not its path. Beforehand this was no problem, because we asked for a loaded library, for which the API provides the path. But now we are asking for the executable itself.
> 2.	`dladdr()` is differently implemented three times in the openjdk code. In the static case I supressed now the usage of the additional modules containing version two and three. I know this shouldn't be the final version. Magnus mentioned that they have discussed from time to time to have a "basic JDK utility lib" that can be shared between hotspot and the JDK libraries. I think this is a good idea for the future, but far beyond the scope of this PR. The second best thing Magnus proposed is to only have the `dladdr()` functionality in Hotspot and then export it. Let's see how the community decides.
> 3.	Because we lack a linker flag like `whole-archive`, I had to force the export of all symbols by creating export files containing all symbols of the static libs. I introduced the new rule for the export file generation as "raw" make recipes. Magnus claimed to use the `SetupExecute`. Unfortunately I was not able to make it function. So I still have my "raw" solution in place, but my last try with `SetupExecute` as comment beneath. Help is welcome.

This pull request has now been integrated.

Changeset: d8c2f59a
Author:    Joachim Kern <jkern at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8c2f59a1b28521ab9969fdf71c52726026d2a85
Stats:     68 lines in 5 files changed: 63 ins; 3 del; 2 mod

8352064: AIX: now also able to build static-jdk image with a statically linked launcher

Reviewed-by: mdoerr, mbaesken, ihse

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

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

From ihse at openjdk.org  Mon Mar 24 17:07:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Mar 2025 17:07:17 GMT
Subject: RFR: 8352064: AIX: now also able to build static-jdk image with a
 statically linked launcher [v5]
In-Reply-To: <GU2PXj5ZoTpNwQDZP2GwAe5ks6cuzZ4nrlUwLWh3lPk=.395b8864-3a91-4c1b-a77f-932a5b87abd4@github.com>
References: <RmTZHoLh7lPutYoQoylFh6KBxYQRm2v9YwfRdugpGzo=.4d91e3dd-4a9a-4dc7-9da0-176868915aaf@github.com>
 <93CQ9wGGSU6KyvHgKzxcAhiGIs3OWAQJnAiYgCBRuMY=.5807a209-6257-4df9-a53b-353f50c8a38a@github.com>
 <GU2PXj5ZoTpNwQDZP2GwAe5ks6cuzZ4nrlUwLWh3lPk=.395b8864-3a91-4c1b-a77f-932a5b87abd4@github.com>
Message-ID: <3hZLvynYqp2oIj5l7-fC764K5KCM08ooRvWq3woHYlI=.85ae9e1d-bf14-4b73-be13-6729f2add58a@github.com>

On Mon, 24 Mar 2025 15:46:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Seems we use already a bit of functionality from common/awt in the splashscreen lib

Maybe. The client team has traditionally been very conservative about doing clean-up changes like that, so you might be entering an uphill battle if you want to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/24062#issuecomment-2748828065

From jiangli at openjdk.org  Mon Mar 24 20:22:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 24 Mar 2025 20:22:55 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v2]
In-Reply-To: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
Message-ID: <E3vQEa89DINYSryJ7VtWQaVLs7s2A0j3LxM7rMweMbk=.93677b32-522f-4c33-9a87-29e80dd151e4@github.com>

> Please review following changes, thanks.
> 
> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
> 
> 
> $ static-jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
> 
> $ jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
> 
> 
> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
> 
> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Allocate memory for vm_info string using NEW_C_HEAP_ARRAY.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24171/files
  - new: https://git.openjdk.org/jdk/pull/24171/files/43500ce6..4c17c5ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24171&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24171&range=00-01

  Stats: 38 lines in 1 file changed: 11 ins; 17 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24171/head:pull/24171

PR: https://git.openjdk.org/jdk/pull/24171

From jiangli at openjdk.org  Mon Mar 24 20:28:07 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 24 Mar 2025 20:28:07 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v2]
In-Reply-To: <kIRnI3h867XxJOk1InvQ3-bcM2_zJKJE4gxnWHA83wE=.2de7e07c-ed8e-424b-a39d-b8760e4235f6@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <kIRnI3h867XxJOk1InvQ3-bcM2_zJKJE4gxnWHA83wE=.2de7e07c-ed8e-424b-a39d-b8760e4235f6@github.com>
Message-ID: <wOUKxKAV8DuYCJo-tq37HXs2cUnNwHL-BSagCHHmYOI=.c9a49166-1bee-41f1-bdfd-c27e5bd975f5@github.com>

On Mon, 24 Mar 2025 07:02:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The way we construct the VM info string is rather clunky and does not scale when you want to add more information like this. 

Agree.

> Short of rewriting it to dynamically create the final string from its constituent parts, couldn't this change more simply replace the return statements with an assignment to a local and then append static if needed i.e something like:
> 
> ```
> char* ret;
> ...
> ret = CDSConfig::is_using_archive() ? "interpreted mode, sharing" : "interpreted mode";
> ...
> // If static then append static
> if (is_vm_statically_linked() {
>   const char* static_str = ", static";
>   const char* buf = malloc(strlen(ret) + strlen(static_str);
>   strcpy(buf, ret);
>   strcat(buf, static_str);
> }
> ```
> 
> ??

If we allocate memory dynamically for vm_info string in the static case, how about we further simplify the code to handle the CDS case as well? I updated the change, please let me know if that looks cleaner to you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24171#issuecomment-2749312616

From dholmes at openjdk.org  Mon Mar 24 20:44:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Mar 2025 20:44:12 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <T3mCEKocybeiEe-1IuPZO5unwjJIrp6Yv9tgfz-iIkU=.1b5a7090-e36a-4aad-a52c-f17531d32dea@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <2CC-bji6jxt9m83WbtfB5AU_5pldkXJMe9brC5BoMo0=.75976be4-b0e5-4f28-a4a6-923ea3b48043@github.com>
 <HQpEBCu7VWia-TFdfOqXrpHBkpcRM2DNgMr9djEhSoU=.399c7ab6-1a92-4c72-b573-c6cf554cb212@github.com>
 <MKaQLWvwOa2-vgbPSVT_WX-aUEdrphhJC5n_L8pyg1E=.09661a98-d1fd-47c9-9d3e-f894cbf0367f@github.com>
 <T3mCEKocybeiEe-1IuPZO5unwjJIrp6Yv9tgfz-iIkU=.1b5a7090-e36a-4aad-a52c-f17531d32dea@github.com>
Message-ID: <zBUkjq5KCJwVhLhljMFkw7YIjCet4FE56xs7V9hHr0Q=.d8de79e8-3b61-4670-ad8d-cc9dae13b0ef@github.com>

On Mon, 24 Mar 2025 15:37:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The class loading process stops there with an exception, but the failed class remains in the ClassLoaderData.

That seems wrong. And IIUC only happens for the JNI case - Java code would have rejected the name before creating the class and associating it with the CLD.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24172#issuecomment-2749343812

From dholmes at openjdk.org  Tue Mar 25 01:32:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Mar 2025 01:32:11 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v3]
In-Reply-To: <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com>
Message-ID: <G8MqAcyF3Jg8S4vkTjymGC1LOvJdR3wcnDdYBjbh3X0=.a731e4f0-273a-4d7a-881d-06b4db2d3d4d@github.com>

On Wed, 26 Feb 2025 07:07:38 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

@ktakakuri hotspot changes require two reviews. I will try to drum up another reviewer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2749805102

From duke at openjdk.org  Tue Mar 25 01:37:13 2025
From: duke at openjdk.org (Zihao Lin)
Date: Tue, 25 Mar 2025 01:37:13 GMT
Subject: Integrated: 8350429: runtime/NMT/CheckForProperDetailStackTrace.java
 should only run for debug JVM
In-Reply-To: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>
References: <FZXxc46AvYbYCuVAFVbyv1nhmO7maibcMS6hU9NnwxU=.8f1fcb30-3ad6-4371-8979-d9a971481493@github.com>
Message-ID: <qaP6gmbCrW8f6lztoSJCcKlMA3L0TUPSZZ3dM-Y5qqs=.7f0c180d-72fc-46e8-8f35-2b654e76462e@github.com>

On Mon, 24 Mar 2025 14:10:21 GMT, Zihao Lin <duke at openjdk.org> wrote:

> runtime/NMT/CheckForProperDetailStackTrace.java should only run for debug JVM

This pull request has now been integrated.

Changeset: 5625b43f
Author:    Zihao Lin <linzihao1999 at outlook.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5625b43ff4fa77843260d152d618ae1083ec04b8
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8350429: runtime/NMT/CheckForProperDetailStackTrace.java should only run for debug JVM

Reviewed-by: stuefe, jsjolen

-------------

PR: https://git.openjdk.org/jdk/pull/24198

From fyang at openjdk.org  Tue Mar 25 02:33:09 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 25 Mar 2025 02:33:09 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
 [v2]
In-Reply-To: <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
 <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
Message-ID: <rwQ2LE4ifVlwtIrr9D543oM7UvTj95J3FoybES7dcqk=.090163f2-81db-4572-a4fd-4e4f8f2c1fa6@github.com>

On Mon, 24 Mar 2025 14:00:34 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi all,
>> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
>> 
>> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
>> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
>> 
>> 
>> Testing on QEMU before this PR:
>> 
>> $ uname -a
>> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
>> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
>> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
>> [0.022s][info][os] Use of pthread_condattr_setclock is supported
>> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
>> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
>> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
>> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe670...
>
> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the issue in vm_version_riscv.cpp

Looks good.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24182#pullrequestreview-2712131613

From dholmes at openjdk.org  Tue Mar 25 03:22:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Mar 2025 03:22:06 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
Message-ID: <hGbs1wc30upUn_Lsks_gHFempcvoJ76lKcWZVctHK2w=.b5c75084-0d2a-4628-a9f2-c3bb8a8d7f08@github.com>

On Sat, 22 Mar 2025 04:39:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
> 
> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.

Marked as reviewed by dholmes (Reviewer).

tl;dr  Okay the presented fix is acceptable.

I went through the JVMS to try and determine exactly when a prohibited package name should be detected and cause the class to be rejected. Unfortunately this is not clearly stated anywhere. JVMS 5.3.5 gives the process whereby a purported class representation is used to derive a class, and the checking of the package name does not occur there. That section ends with:

> If no exception is thrown in steps 1-4, then derivation of the class or interface C
succeeds. The Java Virtual Machine marks C to have L as its defining loader, records
that L is an initiating loader of C (?5.3.4), and creates C in the method area (?2.5.4).

which is what the classfile parsing code has done. JVMS 5.3.6 defines module and layers and it is there that we have the rule that packages can not be split and thus a user-defined classloader cannot "load" (successfully) a class in the java.base module (and by implication the `java.*` package tree). But there is no direction on exactly when this package  check is to be performed - or even the error to throw in such a case. The JVMS effectively delegates the semantics to `ModuleLayer.defineModules` but that also does not address this issue. In fact the only places it is stated explicitly that attempts to define a class in the `java.*` namespace will throw a `SecurityException`  is in `ClassLoader.defineClass` and JNI `DefineClass`. The former performs the package check upfront. The latter allows the JVM to do the package check "somewhere".

I think a case can be made that JNI `DefineClass` should eagerly check the package name, as the Java code does., and thus avoid leaving a "partially formed" class defined in the `classLoaderData`. However, there are practical problems with actually trying to do such a check in the JNI code - the name may not be available until classfile parsing has identified it. Additionally, although this seems quite reasonable behaviour for something that is an error case, it is a change in behaviour that would have to be scrutinized. As such it seems out-of-scope to suggest such a  change in this PR.

FWIW I think the JNI spec for `DefineClass` should have been expressed to act as-if the `defineClass` method of the supplied loader were invoked. The JVMS could then expect that any purported class representation has already been approved by the associated classloader and the VM would not need to do any package checks. (Though again the fact the name of the class may only be available inside the presented bytes makes this awkward, as some parsing is needed to get to it.)

That all said, my analysis leaves me a bit puzzled about the proposed fix of checking `is_loaded()`' because from my reading of 5.3.5 the class is actually loaded. So it seems the `instanceKlass` definition of `is_loaded` does not exactly align with JVMS. But again this is not something for this PR to try and rectify.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24172#pullrequestreview-2712212063
PR Comment: https://git.openjdk.org/jdk/pull/24172#issuecomment-2749954137

From dholmes at openjdk.org  Tue Mar 25 05:20:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Mar 2025 05:20:07 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v2]
In-Reply-To: <E3vQEa89DINYSryJ7VtWQaVLs7s2A0j3LxM7rMweMbk=.93677b32-522f-4c33-9a87-29e80dd151e4@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <E3vQEa89DINYSryJ7VtWQaVLs7s2A0j3LxM7rMweMbk=.93677b32-522f-4c33-9a87-29e80dd151e4@github.com>
Message-ID: <WypOW6Rlthgh39BdYeHOXuOLuwMxU9YgQ5APBjAhP4I=.2fcb5fbf-1e66-4bc4-9127-b8faaaac7259@github.com>

On Mon, 24 Mar 2025 20:22:55 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review following changes, thanks.
>> 
>> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
>> 
>> 
>> $ static-jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
>> 
>> $ jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
>> 
>> 
>> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
>> 
>> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
>> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
>> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allocate memory for vm_info string using NEW_C_HEAP_ARRAY.

I was only going to handle the static part as a special case but you are right that also handling sharing this way makes a lot of sense and cleans up the code.

src/hotspot/share/runtime/abstract_vm_version.cpp line 169:

> 167:   jio_snprintf(vm_info, len, "%s%s%s", mode,
> 168:                is_vm_statically_linked() ? ", static" : "",
> 169:                CDSConfig::is_using_archive() ? ", sharing" : "");

I would prefer to see these parts defined as `const char * static_str = ", static"` so we can use `strlen` above rather than having magic numbers.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24171#pullrequestreview-2712401528
PR Review Comment: https://git.openjdk.org/jdk/pull/24171#discussion_r2011325318

From shade at openjdk.org  Tue Mar 25 09:05:20 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Mar 2025 09:05:20 GMT
Subject: RFR: 8348829: Remove ObjectMonitor perf counters [v3]
In-Reply-To: <fHJett6TXtqhUAmCCtE8Iv8Zlz0rFF0Xp5D1ObHYYVg=.e77fe610-4093-4452-a838-7a9d1b0b382b@github.com>
References: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
 <fHJett6TXtqhUAmCCtE8Iv8Zlz0rFF0Xp5D1ObHYYVg=.e77fe610-4093-4452-a838-7a9d1b0b382b@github.com>
Message-ID: <nH23lIm6VpSqGLURVoU5-fiIzr_MlAf6W8Hrrhydr78=.5a210d44-9570-4207-b4cc-9f4059970084@github.com>

On Tue, 18 Mar 2025 10:52:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for more discussion. I believe these counters are useless and come with more trouble than their worth.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8348829-remove-om-counters
>  - Merge branch 'master' into JDK-8348829-remove-om-counters
>  - Counters removal

I am integrating this one, and will re-merge [JDK-8352256](https://bugs.openjdk.org/browse/JDK-8352256) after it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23326#issuecomment-2750554828

From shade at openjdk.org  Tue Mar 25 09:05:20 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Mar 2025 09:05:20 GMT
Subject: Integrated: 8348829: Remove ObjectMonitor perf counters
In-Reply-To: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
References: <80bqZVjeWJ0_vKxnsiK5NTGKRQTothQxg0fkbKFOF6s=.20083f01-f4b6-4cd9-b726-0e652b4f12f3@github.com>
Message-ID: <L81H0jsiukkgxziVzMqdZ4j-GvdkcNoqy806lNMe93A=.62dc65f0-835f-4ada-b646-fa1ac38a8331@github.com>

On Tue, 28 Jan 2025 09:57:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for more discussion. I believe these counters are useless and come with more trouble than their worth.

This pull request has now been integrated.

Changeset: aee4d691
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aee4d6910ba15f8b8946f36968fc8b8599d9e50d
Stats:     116 lines in 4 files changed: 0 ins; 116 del; 0 mod

8348829: Remove ObjectMonitor perf counters

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/23326

From shade at openjdk.org  Tue Mar 25 09:15:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Mar 2025 09:15:38 GMT
Subject: RFR: 8352256: ObjectSynchronizer::quick_notify misses JFR event
 notification path [v3]
In-Reply-To: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
References: <3BVVxMoMb7bZTCkmzan7ZdkI7d2qb4hVt2KFJcYMQU4=.3ba8acc8-c795-4853-814a-2978bacebfe9@github.com>
Message-ID: <OX3_bs-ZtuBcE72R90JPLLmYOtzx612Vf3fy72_WChM=.cfead802-d9fb-4255-afe9-738e9f9bc1d9@github.com>

> Noticed this while removing OM counters. When doing [JDK-8351187](https://bugs.openjdk.org/browse/JDK-8351187), I apparently forgot to cover a path from `ObjectSynchronizer::quick_notify`, probably due to concurrent renames. I think we can cover this gap while still simplifying the code: let `ObjectMonitor` handle all events, DTrace, JFR, OM stats.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `jdk_jfr`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8352256-quick-notify-jfr
 - Review comment
 - Fix

-------------

Changes: https://git.openjdk.org/jdk/pull/24097/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24097&range=02
  Stats: 23 lines in 3 files changed: 16 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24097/head:pull/24097

PR: https://git.openjdk.org/jdk/pull/24097

From jsjolen at openjdk.org  Tue Mar 25 10:42:10 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 25 Mar 2025 10:42:10 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v5]
In-Reply-To: <cyB6mNmb1WFVRFcb0dJ8v52fgyc7V0nUAWhsp-WlYXI=.6904fcfb-09ef-4084-98b6-68fd28f2f760@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <cyB6mNmb1WFVRFcb0dJ8v52fgyc7V0nUAWhsp-WlYXI=.6904fcfb-09ef-4084-98b6-68fd28f2f760@github.com>
Message-ID: <ajvJk3VaxGwXhbP6ni3mPeGBqJoFRJWYfuPX-ZETFxg=.03129014-3cd0-40ae-969a-8be8dd45aff6@github.com>

On Mon, 24 Mar 2025 08:58:54 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more fixes.

Some more comments.

Can we have the example cases I presented as test cases in the code? I think that those show the behavior of this code.

test/hotspot/gtest/nmt/test_vmatree.cpp line 764:

> 762:   auto expected =  [&](Tree& tree, int p, SIndex reserve_stack, SIndex commit_stack, int line_no = __LINE__) {
> 763:     VMATree::VMATreap::Range r = tree.tree().find_enclosing_range(p);
> 764:     const bool check_end_node = true;

Dead code

test/hotspot/gtest/nmt/test_vmatree.cpp line 782:

> 780:   };
> 781: 
> 782:   {

I think that each test case should at least have a small comment summarizing the supposed goal of the test. Below is an example of what the could look like for the first test case. 


// Check committing into a reserved region inherits the call stacks

test/hotspot/gtest/nmt/test_vmatree.cpp line 787:

> 785:     expected(tree,  0, si_1,   -1, __LINE__);
> 786: 
> 787:     tree.commit_mapping(25, 25, call_stack_2, true); // commit at the middle of the region

We have something like `[0, 25), [25, 50), [50, 100)` here, can we check the last region also?

test/hotspot/gtest/nmt/test_vmatree.cpp line 807:

> 805: 
> 806:     tree.commit_mapping(10, 20, call_stack_1); // commit with overlap
> 807:     expected(tree, 10, si_1, si_1, __LINE__);

Introduce a third call stack for this case. We want to see that the reserved stack is placed correctly, it also clarifies what the test does a bit for readers.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2713205086
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2011789146
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2011801428
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2011794964
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2011804909

From jkern at openjdk.org  Tue Mar 25 10:48:49 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 25 Mar 2025 10:48:49 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v2]
In-Reply-To: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
Message-ID: <pUBX1_YCStKbFHDFGhxchgO7HOoSFGVdsl2hwMRqtZI=.f18198b7-4155-4e29-8cbf-67ab9f7fd885@github.com>

> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
> 
> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
> 
> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
> So my proposal is to skip this sub test for aix and musl.

Joachim Kern has updated the pull request incrementally with two additional commits since the last revision:

 - rm jtreg_test_output
 - reactivate test with self generated compare path

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24055/files
  - new: https://git.openjdk.org/jdk/pull/24055/files/2226d7f9..ea56e279

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=00-01

  Stats: 35 lines in 1 file changed: 16 ins; 7 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/24055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24055/head:pull/24055

PR: https://git.openjdk.org/jdk/pull/24055

From tpushkin at openjdk.org  Tue Mar 25 11:14:10 2025
From: tpushkin at openjdk.org (Timofei Pushkin)
Date: Tue, 25 Mar 2025 11:14:10 GMT
Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist
 to create CDS archive
Message-ID: <AdBmCAbqhjQEP05JBlXhp21hKuxn7SAb7h0Y3Wvollk=.21c0e6fe-097e-41e4-afa3-45b108112a28@github.com>

If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app.

This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible.

Implementation note: `URLClassLoader` does not allow selecting a specific URL to load a specific class ? I used reflection to override a private part of `URLClassLoader` responsible for URL selection while being able to use the rest of its implementation.

-------------

Commit messages:
 - Add regression test
 - Use a single UnregisteredClassLoader

Changes: https://git.openjdk.org/jdk/pull/24223/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315130
  Stats: 448 lines in 11 files changed: 276 ins; 98 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/24223.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223

PR: https://git.openjdk.org/jdk/pull/24223

From azafari at openjdk.org  Tue Mar 25 13:03:35 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 25 Mar 2025 13:03:35 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v6]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <yMckoHbKcqajG3ITakgw5ZTVOp_Aue3hmvr8SKgIJY0=.aa5d0d83-8787-4d8e-b52f-952718ac75b0@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24028/files
  - new: https://git.openjdk.org/jdk/pull/24028/files/599eaa04..416bda5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=04-05

  Stats: 38 lines in 1 file changed: 29 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028

PR: https://git.openjdk.org/jdk/pull/24028

From azafari at openjdk.org  Tue Mar 25 13:12:23 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 25 Mar 2025 13:12:23 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v5]
In-Reply-To: <ajvJk3VaxGwXhbP6ni3mPeGBqJoFRJWYfuPX-ZETFxg=.03129014-3cd0-40ae-969a-8be8dd45aff6@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <cyB6mNmb1WFVRFcb0dJ8v52fgyc7V0nUAWhsp-WlYXI=.6904fcfb-09ef-4084-98b6-68fd28f2f760@github.com>
 <ajvJk3VaxGwXhbP6ni3mPeGBqJoFRJWYfuPX-ZETFxg=.03129014-3cd0-40ae-969a-8be8dd45aff6@github.com>
Message-ID: <SVuks1Nr7VKKoUAs9EXatKy_QJMC9Lll2lbyJGbrTPQ=.33cb432a-5f3c-4055-8fbc-139b59dd486c@github.com>

On Tue, 25 Mar 2025 10:39:52 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Some more comments.
> 
> Can we have the example cases I presented as test cases in the code? I think that those show the behavior of this code.

Done.

> test/hotspot/gtest/nmt/test_vmatree.cpp line 764:
> 
>> 762:   auto expected =  [&](Tree& tree, int p, SIndex reserve_stack, SIndex commit_stack, int line_no = __LINE__) {
>> 763:     VMATree::VMATreap::Range r = tree.tree().find_enclosing_range(p);
>> 764:     const bool check_end_node = true;
> 
> Dead code

Removed.

> test/hotspot/gtest/nmt/test_vmatree.cpp line 782:
> 
>> 780:   };
>> 781: 
>> 782:   {
> 
> I think that each test case should at least have a small comment summarizing the supposed goal of the test. Below is an example of what the could look like for the first test case. 
> 
> 
> // Check committing into a reserved region inherits the call stacks

Done.

> test/hotspot/gtest/nmt/test_vmatree.cpp line 787:
> 
>> 785:     expected(tree,  0, si_1,   -1, __LINE__);
>> 786: 
>> 787:     tree.commit_mapping(25, 25, call_stack_2, true); // commit at the middle of the region
> 
> We have something like `[0, 25), [25, 50), [50, 100)` here, can we check the last region also?

Done.

> test/hotspot/gtest/nmt/test_vmatree.cpp line 807:
> 
>> 805: 
>> 806:     tree.commit_mapping(10, 20, call_stack_1); // commit with overlap
>> 807:     expected(tree, 10, si_1, si_1, __LINE__);
> 
> Introduce a third call stack for this case. We want to see that the reserved stack is placed correctly, it also clarifies what the test does a bit for readers.

Done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2751213108
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2012058829
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2012060453
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2012059726
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2012060806

From jsikstro at openjdk.org  Tue Mar 25 14:06:46 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 25 Mar 2025 14:06:46 GMT
Subject: RFR: 8352762: Use EXACTFMT instead of expanded version where
 applicable
Message-ID: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>

[JDK-8310233](https://bugs.openjdk.org/browse/JDK-8310233) introduced the EXACTFMT macro, which is a shorthand for printing exact values using methods defined in globalDefinitions.hpp. There are currently 20 places in HotSpot which uses the expanded version of the macro, along with the "trace_page_size_params" macro that is defined and used in os.cpp.

I have replaced places that use the expanded macro(s) with EXACTFMT + EXACTFMTARGS, and also removed trace_page_size_params from os.cpp, which was essentially a redefnition of EXACTFMTARGS.

Testing: GHA, tiers 1-4

-------------

Commit messages:
 - 8352762: Use EXACTFMT instead of expanded version where applicable

Changes: https://git.openjdk.org/jdk/pull/24228/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24228&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352762
  Stats: 70 lines in 8 files changed: 0 ins; 20 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/24228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24228/head:pull/24228

PR: https://git.openjdk.org/jdk/pull/24228

From azafari at openjdk.org  Tue Mar 25 14:57:04 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 25 Mar 2025 14:57:04 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v7]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <zbJUb5iseGf6BA_NVOmgf81Ucza5NeRPUgfHZvzsb7g=.6e5a7c0f-b20e-497e-87f4-c5414fa5858d@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  fix the GHA failures.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24028/files
  - new: https://git.openjdk.org/jdk/pull/24028/files/416bda5f..9874c56f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028

PR: https://git.openjdk.org/jdk/pull/24028

From jiangli at openjdk.org  Tue Mar 25 15:25:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 25 Mar 2025 15:25:56 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v3]
In-Reply-To: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
Message-ID: <35G0hqgMGHVzjo6j8oj3UqySFKkiGlFjkSrXorCbe4g=.7790d883-0261-47dc-a731-1b9f98840633@github.com>

> Please review following changes, thanks.
> 
> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
> 
> 
> $ static-jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
> 
> $ jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
> 
> 
> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
> 
> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Address @dholmes-ora's comment: Use `strlen` to get the length for ", static" and ", sharing".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24171/files
  - new: https://git.openjdk.org/jdk/pull/24171/files/4c17c5ed..bfaa6e48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24171&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24171&range=01-02

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24171/head:pull/24171

PR: https://git.openjdk.org/jdk/pull/24171

From jiangli at openjdk.org  Tue Mar 25 15:25:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 25 Mar 2025 15:25:56 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v2]
In-Reply-To: <WypOW6Rlthgh39BdYeHOXuOLuwMxU9YgQ5APBjAhP4I=.2fcb5fbf-1e66-4bc4-9127-b8faaaac7259@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <E3vQEa89DINYSryJ7VtWQaVLs7s2A0j3LxM7rMweMbk=.93677b32-522f-4c33-9a87-29e80dd151e4@github.com>
 <WypOW6Rlthgh39BdYeHOXuOLuwMxU9YgQ5APBjAhP4I=.2fcb5fbf-1e66-4bc4-9127-b8faaaac7259@github.com>
Message-ID: <pJTevw86mjD2rqavlGcBKGaAFUhB2woMEIL7Ch5isxI=.9819e2e8-9651-4460-8a3e-3d17547ff23e@github.com>

On Tue, 25 Mar 2025 05:16:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allocate memory for vm_info string using NEW_C_HEAP_ARRAY.
>
> src/hotspot/share/runtime/abstract_vm_version.cpp line 169:
> 
>> 167:   jio_snprintf(vm_info, len, "%s%s%s", mode,
>> 168:                is_vm_statically_linked() ? ", static" : "",
>> 169:                CDSConfig::is_using_archive() ? ", sharing" : "");
> 
> I would prefer to see these parts defined as `const char * static_str = ", static"` so we can use `strlen` above rather than having magic numbers.

Done. Thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24171#discussion_r2012360877

From syan at openjdk.org  Tue Mar 25 16:15:22 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 25 Mar 2025 16:15:22 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
 [v2]
In-Reply-To: <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
 <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
Message-ID: <Uod5tdA4UcMLXX-8MH_saDMZ6YClr00hh0GqrlEVJCc=.e285775f-7325-4708-86a0-39e53db57368@github.com>

On Mon, 24 Mar 2025 14:00:34 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi all,
>> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
>> 
>> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
>> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
>> 
>> 
>> Testing on QEMU before this PR:
>> 
>> $ uname -a
>> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
>> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
>> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
>> [0.022s][info][os] Use of pthread_condattr_setclock is supported
>> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
>> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
>> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
>> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe670...
>
> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the issue in vm_version_riscv.cpp

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24182#pullrequestreview-2714375021

From coleenp at openjdk.org  Tue Mar 25 18:40:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Mar 2025 18:40:10 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable
In-Reply-To: <HE0ufRqFtSHREnSydlbsJiEMp4GteCYlef1X8FhId84=.2eb23060-825f-47ca-8fd0-7f0d9248c513@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <KjsQAmJcI5GvU2oRkvyGJx_a-RRmN3n3nf77szTtjaI=.6e092298-c5b2-4b10-9e4c-b05ef840bc6e@github.com>
 <HZ2DrySldFuiBRb88TYV23NSa5NlCzN1qpYog2CdFP4=.f6d9e803-ab98-4073-a6f8-d15def7e8452@github.com>
 <bYOO0TbWMbxz5uswJuf2ou5EPIvmZ3cX8d1uuRQ4yi0=.bee7fc37-92f3-438d-9cf0-e328235c89be@github.com>
 <HE0ufRqFtSHREnSydlbsJiEMp4GteCYlef1X8FhId84=.2eb23060-825f-47ca-8fd0-7f0d9248c513@github.com>
Message-ID: <PltYmB_nicNxvm_HxKaOV0LtVWLdNSVtapG2g2S_wEo=.2acc1d42-1164-4588-9f78-e49261907fbf@github.com>

On Wed, 19 Mar 2025 11:31:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I am not sure if I understand the problem. Why can't we do that? We successfully looked up the monitor from the OMCache, why can't we stick it in the BasicLock cache, to avoid having to look it up in the OMCache again? Whatever code would pull it out of the BasicLock and observe a deflating monitor might also pull it out of the OMCache and observe a deflating monitor, or is that not correct? I know that OMCache::get_monitor() filters deflating monitors, but that is not a guarantee that a monitor would not flip to deflating after that check? So ... the user of the monitor would always have to deal with deflation after it has pulled a monitor from any of the caches anyway?
>> 
>> If it is our contract that only successfully locked monitors go into the BasicLock cache, then we can't do that optimization, I think.
>
> Maybe this is okay.  My change that ran afoul of this test found the monitor in the first 32 entries of the ObjectSynchronizer::_in_use_list and filtered for deflating monitors also.  Then put the monitor it found in the OMCache. Since it didn't help performance, I backed this out of my change. It may be safer to put the monitor in the BasicLock field because it's cleared.  All this to say, I don't really know if this is right.

Looks like from GHA, this also fails the same test.  I think you should remove this optimization since I don't think it helps any.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2012732648

From shade at openjdk.org  Tue Mar 25 18:54:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Mar 2025 18:54:16 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v2]
In-Reply-To: <gC2sHYWT3OwonissrywET7hat7IvvrrDSxQZbNcO2KU=.529bf399-5ad7-461a-aafd-f5375397d7d4@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
 <gC2sHYWT3OwonissrywET7hat7IvvrrDSxQZbNcO2KU=.529bf399-5ad7-461a-aafd-f5375397d7d4@github.com>
Message-ID: <QDzCp9sYJcsIy69MreT16zRLkLGACWWLiJGJU-2pIUM=.9da43d3f-98c0-4f05-b26c-b65d7e766c57@github.com>

On Wed, 19 Mar 2025 23:03:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.
>> 
>> Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:
>> 
>> https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
>> 
>> This PR adds a few new classes to simplify the test cases:
>> 
>> Example: build two modular JAR files into `modulePath`
>> 
>> 
>> CDSModulePackager modulePackager = new CDSModulePackager(SRC);
>> modulePath = modulePackager.getOutputDir().toString();
>> 
>> modulePackager.createModularJar("com.foos");
>> modulePackager.createModularJar("com.needsfoosaddexport",
>>                                 "--add-exports",
>>                                 "com.foos/com.foos.internal=com.needsfoosaddexport");
>> 
>> 
>> Example: use modules in training/assembly/production phases
>> 
>> 
>> SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
>>    .classpath(dummyJar)
>>    .modulepath(modulePath)
>>    .addVmArgs("--add-modules", "com.needsjdkaddexport",
>>               "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
>>    .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
>>    .setAssemblyChecker((OutputAnalyzer out) -> {
>>            out.shouldContain("Full module graph = enabled");
>>         })
>>     .setProductionChecker((OutputAnalyzer out) -> {
>>             out.shouldContain("use_full_module_graph = true; java.base");
>>         })
>>     .runStaticWorkflow()
>>     .runAOTWorkflow();
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments

Looks good to me, although this is the first time I look into this code :)

test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java line 111:

> 109:         String MAIN_CLASS = "com.foos.Test";
> 110: 
> 111:         String appClasses[] = {MAIN_CLASS};

Suggestion:

        String[] appClasses = {MAIN_CLASS};

test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java line 99:

> 97:         OutputAnalyzer output = TestCommon.createArchive(
> 98:                                         appJar1.toString(), appClasses,
> 99:                                         "--module-path", moduleDir2.toString(),

Is this correct to use `appJar1` but `moduleDir2`?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24122#pullrequestreview-2714686244
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2012644405
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2012680026

From vpetko at openjdk.org  Tue Mar 25 19:05:21 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 25 Mar 2025 19:05:21 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after JDK-8350106
Message-ID: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>

Add missing header to resolve the compilation failure.

Testing:
 - built openjdk in PPC qemu vm.

-------------

Commit messages:
 - 8352800: [PPC] OpenJDK fails to build on PPC after JDK-8350106

Changes: https://git.openjdk.org/jdk/pull/24216/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24216&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352800
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24216.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24216/head:pull/24216

PR: https://git.openjdk.org/jdk/pull/24216

From shade at openjdk.org  Tue Mar 25 19:19:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Mar 2025 19:19:14 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106
In-Reply-To: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
Message-ID: <RkseLuSBhV6Ci8mqVMPcyxHqOU0xdZAbRT1S2fc7ry8=.4f3a3c93-24dd-4ddd-8649-d638710912e9@github.com>

On Tue, 25 Mar 2025 08:12:37 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> Add missing header to resolve the compilation failure.
> 
> Testing:
>  - built openjdk in PPC qemu vm.

src/hotspot/os_cpu/linux_ppc/javaThread_linux_ppc.cpp line 27:

> 25: 
> 26: #include "memory/metaspace.hpp"
> 27: #include "os_linux_ppc.inline.hpp"

So you need to reach `os::Linux::ucontext_get_sp`, right? Then the header that contains it, is a generic `os_linux.hpp`. You get it transitively by including `os_linux_ppc.inline.hpp`, but there is no need to rely on this transitivity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24216#discussion_r2012790322

From shade at openjdk.org  Tue Mar 25 19:19:25 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Mar 2025 19:19:25 GMT
Subject: RFR: 8350106: [PPC] Avoid ticks_unknown_not_Java
 AsyncGetCallTrace() if JavaFrameAnchor::_last_Java_pc not set [v2]
In-Reply-To: <Wm1fuLYTcgBk8epsfua_re1Q9xUPh61queLKPeqebuM=.4cf97c8b-9026-49db-a325-bb2834d0794f@github.com>
References: <fG3cfS2iVP5NMb35AvZ0XJ76bDWckrZtDHB1FK7Ez98=.df7b5652-1b62-4201-8609-e2d03ba54f2e@github.com>
 <Wm1fuLYTcgBk8epsfua_re1Q9xUPh61queLKPeqebuM=.4cf97c8b-9026-49db-a325-bb2834d0794f@github.com>
Message-ID: <MhribZpT8QYvylz0IqUiQTb8-BF7LgHq82HiO2Ky21U=.d57b8a6a-5181-48c8-b408-200fab0e047f@github.com>

On Mon, 10 Mar 2025 15:19:41 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This pr changes `JavaThread::pd_get_top_frame_for_profiling` to better address situations where
>> 
>> 1. `JavaThread::last_Java_sp()` returns != null
>> 2. `JavaThread::last_Java_pc()` returns null
>> 
>> If the runtime needs to walk the stack of a java thread in that state, e.g. for gc purposes, it finds the last java pc relative to the last java sp (see [frame::setup()](https://github.com/openjdk/jdk/blob/3f0c1370269db978072814c2170fc3987efade85/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L40)).
>> 
>> This relies on the runtime method being called to store the return pc to its caller's abi which it will do when pushing a new frame for calling another method.
>> 
>> For an asynchronous interrupt to sample the stack this means: if there isn't at least one frame between the last java frame and the frame where the interrupt occurred then we can't be sure that the return pc was already saved and `pd_get_top_frame_for_profiling()` needs to return false indicating failure.
>> 
>> Otherwise we can and should proceed constructing a frame even though `JavaThread::last_Java_pc()` returned null.
>> 
>> Testing:
>> 
>> * DaCapo Tomcat with async-profiler on a fastdebug build.
>> * Tier 1-4 of hotspot and jdk on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master'
>  - Better handle _last_Java_pc == null

Apparently causes https://github.com/openjdk/jdk/pull/24216, take a look?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23640#issuecomment-2752290880

From shade at openjdk.org  Tue Mar 25 19:38:27 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Mar 2025 19:38:27 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log
In-Reply-To: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
Message-ID: <xCBXaORe0jcNod3su9nEctPzUAZtzrYPiiSmD-K-xtY=.dbe5fcaa-fbe8-48cf-bb48-ad09f7d3954a@github.com>

On Tue, 4 Mar 2025 00:44:55 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Always include the ArchiveRelocationMode in the CDS info log. Before this fix, ArchiveRelocationMode is not in the log if it is set to 0.
> The ArchiveRelocationMode default value was set to 1 about 2 years ago. Some tests need to be updated accordingly.
> 
> Testing:
> 
> - ran the modified tests manually on linux-x64
> - tier1

Looks okay to me, with a nit:

src/hotspot/share/cds/metaspaceShared.cpp line 1169:

> 1167:     dynamic_mapinfo = open_dynamic_archive();
> 1168: 
> 1169:     log_info(cds)("ArchiveRelocationMode = %d", ArchiveRelocationMode);

Looks like the style in adjacent output is `Archive relocation mode: %d`. How does the `-Xlog:cds` look with this change?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23878#pullrequestreview-2714900275
PR Review Comment: https://git.openjdk.org/jdk/pull/23878#discussion_r2012772074

From vpetko at openjdk.org  Tue Mar 25 20:19:30 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 25 Mar 2025 20:19:30 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106 [v2]
In-Reply-To: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
Message-ID: <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>

> Add missing header to resolve the compilation failure.
> 
> Testing:
>  - built openjdk in PPC qemu vm.

Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:

  fix: use generic os_linux.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24216/files
  - new: https://git.openjdk.org/jdk/pull/24216/files/0254b85b..2a641152

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24216&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24216&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24216.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24216/head:pull/24216

PR: https://git.openjdk.org/jdk/pull/24216

From ccheung at openjdk.org  Tue Mar 25 22:58:07 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 25 Mar 2025 22:58:07 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log
In-Reply-To: <xCBXaORe0jcNod3su9nEctPzUAZtzrYPiiSmD-K-xtY=.dbe5fcaa-fbe8-48cf-bb48-ad09f7d3954a@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
 <xCBXaORe0jcNod3su9nEctPzUAZtzrYPiiSmD-K-xtY=.dbe5fcaa-fbe8-48cf-bb48-ad09f7d3954a@github.com>
Message-ID: <sZv0FzRRLRSLo8R_Iq2OG7hZktGpFMvHdRGAVOhMOiA=.26b0e4e8-51ff-4e24-8dd0-f05ba2c0f93d@github.com>

On Tue, 25 Mar 2025 19:06:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Always include the ArchiveRelocationMode in the CDS info log. Before this fix, ArchiveRelocationMode is not in the log if it is set to 0.
>> The ArchiveRelocationMode default value was set to 1 about 2 years ago. Some tests need to be updated accordingly.
>> 
>> Testing:
>> 
>> - ran the modified tests manually on linux-x64
>> - tier1
>
> src/hotspot/share/cds/metaspaceShared.cpp line 1169:
> 
>> 1167:     dynamic_mapinfo = open_dynamic_archive();
>> 1168: 
>> 1169:     log_info(cds)("ArchiveRelocationMode = %d", ArchiveRelocationMode);
> 
> Looks like the style in adjacent output is `Archive relocation mode: %d`. How does the `-Xlog:cds` look with this change?

With ArchiveRelocationMode = 0

[0.042s][info][cds] ArchiveRelocationMode = 0
[0.042s][info][cds] Reserved archive_space_rs [0x0000000800000000 - 0x0000000801000000] (16777216) bytes
[0.042s][info][cds] Reserved class_space_rs   [0x0000000801000000 - 0x0000000841000000] (1073741824) bytes
[0.042s][info][cds] Mapped static  region #0 at base 0x0000000800000000 top 0x000000080055d000 (ReadWrite)
[0.042s][info][cds] Mapped static  region #1 at base 0x000000080055d000 top 0x0000000800e05000 (ReadOnly)
[0.042s][info][cds] _archived_main_module_name (null)
[0.042s][info][cds] jdk.module.main (null)
[0.042s][info][cds] optimized module handling: enabled
[0.042s][info][cds] full module graph: enabled
[0.042s][info][cds] jdk.module.addmods (null)
[0.042s][info][cds] optimized module handling: enabled
[0.042s][info][cds] full module graph: enabled
[0.042s][info][cds] jdk.module.enable.native.access (null)
[0.042s][info][cds] optimized module handling: enabled
[0.042s][info][cds] full module graph: enabled


With ArchiveRelocationMode = 1

[0.042s][info][cds] ArchiveRelocationMode = 1
[0.042s][info][cds] Reserved archive_space_rs [0x0000000800000000 - 0x0000000801000000] (16777216) bytes
[0.042s][info][cds] Reserved class_space_rs   [0x0000000801000000 - 0x0000000841000000] (1073741824) bytes
[0.042s][info][cds] Mapped static  region #0 at base 0x0000000800000000 top 0x000000080055d000 (ReadWrite)
[0.042s][info][cds] Mapped static  region #1 at base 0x000000080055d000 top 0x0000000800e05000 (ReadOnly)
[0.042s][info][cds] _archived_main_module_name (null)
[0.042s][info][cds] jdk.module.main (null)
[0.042s][info][cds] optimized module handling: enabled
[0.042s][info][cds] full module graph: enabled
[0.042s][info][cds] jdk.module.addmods (null)
[0.042s][info][cds] optimized module handling: enabled
[0.042s][info][cds] full module graph: enabled
[0.042s][info][cds] jdk.module.enable.native.access (null)
[0.042s][info][cds] optimized module handling: enabled
[0.042s][info][cds] full module graph: enabled
[0.042s][info][cds] ArchiveRelocationMode == 1: always map archive(s) at an alternative address

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23878#discussion_r2013042908

From duke at openjdk.org  Wed Mar 26 01:52:13 2025
From: duke at openjdk.org (duke)
Date: Wed, 26 Mar 2025 01:52:13 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
 [v2]
In-Reply-To: <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
 <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
Message-ID: <LoIS52pI6x-5-Lm0AiWz1aKOSTH6_UxhH_dfCugM3ig=.fcaa5634-860b-4f2e-bbb1-e0ada64dba79@github.com>

On Mon, 24 Mar 2025 14:00:34 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi all,
>> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
>> 
>> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
>> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
>> 
>> 
>> Testing on QEMU before this PR:
>> 
>> $ uname -a
>> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
>> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
>> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
>> [0.022s][info][os] Use of pthread_condattr_setclock is supported
>> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
>> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
>> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
>> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe670...
>
> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the issue in vm_version_riscv.cpp

@DingliZhang 
Your change (at version 5c01052c34dc2d515fa9d6925a851724299bfc4e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24182#issuecomment-2753039305

From dzhang at openjdk.org  Wed Mar 26 01:52:13 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 26 Mar 2025 01:52:13 GMT
Subject: RFR: 8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV
 [v2]
In-Reply-To: <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
 <bQbNNOCgharb41U6ajrm984pq61gltixf0YVXJGwE8o=.8b1c245e-fcf4-4975-8582-779a75800b5c@github.com>
Message-ID: <BwNRBWIpEcI475VPqm3jFmZLFKhaO7Mx6o-2eVytOAM=.b3d609d8-ff1f-495d-be10-63b68a3327e1@github.com>

On Mon, 24 Mar 2025 14:00:34 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

>> Hi all,
>> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
>> 
>> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
>> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
>> 
>> 
>> Testing on QEMU before this PR:
>> 
>> $ uname -a
>> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
>> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
>> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
>> 
>> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
>> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
>> [0.022s][info][os] Use of pthread_condattr_setclock is supported
>> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
>> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
>> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
>> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe670...
>
> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the issue in vm_version_riscv.cpp

Thanks all for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24182#issuecomment-2753038241

From dzhang at openjdk.org  Wed Mar 26 02:01:33 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Wed, 26 Mar 2025 02:01:33 GMT
Subject: Integrated: 8352673: RISC-V: Vector can't be turned on with
 -XX:+UseRVV
In-Reply-To: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
References: <E9eLby-PpR-0SbrYuy5TWjM1kW6GNIE4bmfCdJG2G_0=.75ab3887-e06c-4ace-bcb1-834f4c1ffb7f@github.com>
Message-ID: <J51smzQ-Toojo-TPyuphTdNhp1bFl9uS8lb28JDSJxQ=.cdd061a4-3a3f-4834-8468-dd9d6ecc7f17@github.com>

On Mon, 24 Mar 2025 07:37:06 GMT, Dingli Zhang <dzhang at openjdk.org> wrote:

> Hi all,
> After [JDK-8348384](https://bugs.openjdk.org/browse/JDK-8348384), Vector can't be turned on with -XX:+UseRVV when Linux kernels before 6.8.5, which does not match the printed log:
> 
> log.info("Linux kernels before 6.8.5 (current %ld.%ld.%ld) have a known bug when using Vector and signals.", major, minor, patch);
> log.info("Vector not enabled automatically via hwprobe, but can be turned on with -XX:+UseRVV.");
> 
> 
> Testing on QEMU before this PR:
> 
> $ uname -a
> Linux ubuntu 6.8.0-52-generic #53.1-Ubuntu SMP PREEMPT_DYNAMIC Sun Jan 26 04:38:25 UTC 2025 riscv64 riscv64 riscv64 GNU/Linux
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep UseRVV
>      bool UseRVV                                   = false                             {ARCH diagnostic} {default}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep UseRVV
> OpenJDK 64-Bit Server VM warning: RVV is not supported on this CPU
>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep UseRVV
>      bool UseRVV                                   = false                             {ARCH diagnostic} {command line}
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (build 25-internal-adhoc.zhangdingli.jdk)
> OpenJDK 64-Bit Server VM (build 25-internal-adhoc.zhangdingli.jdk, mixed mode)
> 
> $ ./java -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -Xlog:os=info -version
> [0.021s][info][os] Use of CLOCK_MONOTONIC is supported
> [0.022s][info][os] Use of pthread_condattr_setclock is supported
> [0.022s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC
> [0.022s][info][os] HotSpot is running with glibc 2.39, NPTL 2.39
> [0.022s][info][os] Glibc stack size guard page adjustment is not needed
> [0.024s][info][os] SafePoint Polling address, bad (protected) page:0x00007fff7fe66000, good (unprotected) page:0x00007fff7fe67000
> [0.040s][info][os] attempting shared library load of /home/ubuntu/jdk-rvv...

This pull request has now been integrated.

Changeset: a81250c5
Author:    Dingli Zhang <dzhang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a81250c55312dfdeb4d65970cff683e6f0783ca7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8352673: RISC-V: Vector can't be turned on with -XX:+UseRVV

Reviewed-by: rehn, fyang, syan

-------------

PR: https://git.openjdk.org/jdk/pull/24182

From dholmes at openjdk.org  Wed Mar 26 02:40:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Mar 2025 02:40:14 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable
In-Reply-To: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
Message-ID: <bME3pQf6QhDy_ehPjZizPyB5go98H18vpiIYVd64UOY=.ae39340b-95c6-430f-a3a2-080116e47aba@github.com>

On Tue, 18 Mar 2025 12:41:44 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
> - Some small code shufflings.
> 
> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
> without-OMT: 773.3 ms
> with-OMT: 797.28 ms
> 
> That is still a regression of ~3%

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 749:

> 747:     monitor = lock->object_monitor_cache();
> 748:     if (monitor == nullptr) {
> 749:       monitor = JavaThread::cast(current)->om_get_from_monitor_cache(object);

`current` is already a `JavaThread`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2013297789

From dholmes at openjdk.org  Wed Mar 26 06:05:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Mar 2025 06:05:07 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v3]
In-Reply-To: <35G0hqgMGHVzjo6j8oj3UqySFKkiGlFjkSrXorCbe4g=.7790d883-0261-47dc-a731-1b9f98840633@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <35G0hqgMGHVzjo6j8oj3UqySFKkiGlFjkSrXorCbe4g=.7790d883-0261-47dc-a731-1b9f98840633@github.com>
Message-ID: <y_YNwL-qOHh9RO9rBQVhuj_pHtiwZ4GHzlfrpaI1_qw=.0820bac4-5ec7-4460-8aa6-20f320181e1e@github.com>

On Tue, 25 Mar 2025 15:25:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review following changes, thanks.
>> 
>> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
>> 
>> 
>> $ static-jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
>> 
>> $ jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
>> 
>> 
>> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
>> 
>> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
>> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
>> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @dholmes-ora's comment: Use `strlen` to get the length for ", static" and ", sharing".

Thanks for the updates. That seems okay to me.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24171#pullrequestreview-2715986346

From rrich at openjdk.org  Wed Mar 26 07:23:07 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 26 Mar 2025 07:23:07 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106 [v2]
In-Reply-To: <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
 <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
Message-ID: <BwgAHVDBEUkLHcm_imKuRnHg37csXjPlBvK3xVq_KAw=.b12c0340-cb90-45f4-a97b-a160cfb50007@github.com>

On Tue, 25 Mar 2025 20:19:30 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> Add missing header to resolve the compilation failure.
>> 
>> Testing:
>>  - built openjdk in PPC qemu vm.
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix: use generic os_linux.hpp

Thanks for taking care of the issue!

src/hotspot/os_cpu/linux_ppc/javaThread_linux_ppc.cpp line 27:

> 25: 
> 26: #include "memory/metaspace.hpp"
> 27: #include "os_linux.hpp"

I think you should include `os_linux.inline.hpp` (according to the [style-guide](https://github.com/openjdk/jdk/blob/2e4d7d1846d846fd98201b9b3abeb7b91239a40d/doc/hotspot-style.md?plain=1#L163)).

-------------

Changes requested by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24216#pullrequestreview-2716115534
PR Review Comment: https://git.openjdk.org/jdk/pull/24216#discussion_r2013522699

From rkennke at openjdk.org  Wed Mar 26 07:24:50 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 26 Mar 2025 07:24:50 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable [v2]
In-Reply-To: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
Message-ID: <SUssUssV1-StFgvW1lTAeUM9_V_cfGQtsmeB28wm-3w=.ba69b103-a8f9-4578-b121-d2669b8db187@github.com>

> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
> - Some small code shufflings.
> 
> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
> without-OMT: 773.3 ms
> with-OMT: 797.28 ms
> 
> That is still a regression of ~3%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Clear BasicLock OM cache when monitor is being deflated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24098/files
  - new: https://git.openjdk.org/jdk/pull/24098/files/6407833c..15a54aa0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24098&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24098&range=00-01

  Stats: 12 lines in 4 files changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24098/head:pull/24098

PR: https://git.openjdk.org/jdk/pull/24098

From rkennke at openjdk.org  Wed Mar 26 07:29:06 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 26 Mar 2025 07:29:06 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable [v2]
In-Reply-To: <PltYmB_nicNxvm_HxKaOV0LtVWLdNSVtapG2g2S_wEo=.2acc1d42-1164-4588-9f78-e49261907fbf@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <KjsQAmJcI5GvU2oRkvyGJx_a-RRmN3n3nf77szTtjaI=.6e092298-c5b2-4b10-9e4c-b05ef840bc6e@github.com>
 <HZ2DrySldFuiBRb88TYV23NSa5NlCzN1qpYog2CdFP4=.f6d9e803-ab98-4073-a6f8-d15def7e8452@github.com>
 <bYOO0TbWMbxz5uswJuf2ou5EPIvmZ3cX8d1uuRQ4yi0=.bee7fc37-92f3-438d-9cf0-e328235c89be@github.com>
 <HE0ufRqFtSHREnSydlbsJiEMp4GteCYlef1X8FhId84=.2eb23060-825f-47ca-8fd0-7f0d9248c513@github.com>
 <PltYmB_nicNxvm_HxKaOV0LtVWLdNSVtapG2g2S_wEo=.2acc1d42-1164-4588-9f78-e49261907fbf@github.com>
Message-ID: <S5_o1xVLEBvewGcmlnHEd2Jf85SAFDH0-7a8y69g4wU=.eb2b7ea1-62e6-42cc-a839-6c3eecdcfc94@github.com>

On Tue, 25 Mar 2025 18:37:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maybe this is okay.  My change that ran afoul of this test found the monitor in the first 32 entries of the ObjectSynchronizer::_in_use_list and filtered for deflating monitors also.  Then put the monitor it found in the OMCache. Since it didn't help performance, I backed this out of my change. It may be safer to put the monitor in the BasicLock field because it's cleared.  All this to say, I don't really know if this is right.
>
> Looks like from GHA, this also fails the same test.  I think you should remove this optimization since I don't think it helps any.

'it does not help any' is not correct. The point of this PR is to put the OM in the BasicLock cache early, even if it does not succeed to enter, so that slower paths can pick it up from there. Also, simply removing this particular line would not change anything, because we put the OM in the BasicLock cache in the C2 fast-path in the same way.

I think the BasicLock OM cache should be treated the same way as the thread's OMCache. The BasicLock cache is basically the L1 cache, while the OMCache is the L2 cache. And just like the OMCache lookup, we should clear the BasicLock cache when we observe a deflating monitor. This fixes the failing test.
@xmas92 should also look at this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2013529352

From fbredberg at openjdk.org  Wed Mar 26 07:33:18 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 26 Mar 2025 07:33:18 GMT
Subject: Integrated: 8351655: Optimize ObjectMonitor::unlink_after_acquire()
In-Reply-To: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
References: <a564wd7Ha3_6TxS6TWXH5YA-JJfhGvLs1h6k7iu9uyQ=.f3ae114e-5ea5-41a4-be6e-2acc9c2b6dd0@github.com>
Message-ID: <saontcmjsUpq6e9ju7qVHcVYN7_50RXOPne0QPokdbg=.153554c8-910f-4d5c-a40c-42da028053d3@github.com>

On Mon, 17 Mar 2025 13:11:58 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This PR implements an optimization of `ObjectMonitor::unlink_after_acquire()`. If it's possible it only converts the first part (the singly linked part) of the `entry_list` into a doubly linked list and leave the _entry_list_tail pointer untouched. 
> 
> It has passed tier1-tier8 tests.

This pull request has now been integrated.

Changeset: 45a9750b
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45a9750b2c9364a05e00cdb935ef986c0a2c3e19
Stats:     73 lines in 2 files changed: 51 ins; 14 del; 8 mod

8351655: Optimize ObjectMonitor::unlink_after_acquire()

Reviewed-by: pchilanomate, dholmes, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/24078

From rkennke at openjdk.org  Wed Mar 26 07:54:43 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 26 Mar 2025 07:54:43 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable [v3]
In-Reply-To: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
Message-ID: <y-y8xOaFmHnNbITpoqhM8yPRcM5GaNN0TsathNvAO-U=.5ca2af8c-c960-4cc9-9d39-e85f09b7da35@github.com>

> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
> - Some small code shufflings.
> 
> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
> without-OMT: 773.3 ms
> with-OMT: 797.28 ms
> 
> That is still a regression of ~3%

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Include objectMonitor.inline.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24098/files
  - new: https://git.openjdk.org/jdk/pull/24098/files/15a54aa0..fc5062a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24098&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24098&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24098/head:pull/24098

PR: https://git.openjdk.org/jdk/pull/24098

From jkern at openjdk.org  Wed Mar 26 09:52:27 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 26 Mar 2025 09:52:27 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v3]
In-Reply-To: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
Message-ID: <W2jxtldlJ6r3shE-GQHUwdQNDu6dZjYoXz8kHEAL08k=.3ba90e2c-0eef-41e0-8995-97bd75ff34cc@github.com>

> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
> 
> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
> 
> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
> So my proposal is to skip this sub test for aix and musl.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24055/files
  - new: https://git.openjdk.org/jdk/pull/24055/files/ea56e279..41670da2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=01-02

  Stats: 55 lines in 1 file changed: 1 ins; 40 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24055/head:pull/24055

PR: https://git.openjdk.org/jdk/pull/24055

From coleenp at openjdk.org  Wed Mar 26 11:52:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Mar 2025 11:52:07 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
Message-ID: <OieTDXmChXsZvFVKYPGPaTqhD6APN4GplGi9OYgtsHQ=.1c1332b4-f5f7-46b6-a16b-4370122646ad@github.com>

On Sat, 22 Mar 2025 04:39:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
> 
> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.

src/hotspot/share/cds/metaspaceShared.cpp line 759:

> 757:     for (int i = 0; i < collect_cld.nof_cld(); i++) {
> 758:       ClassLoaderData* cld = collect_cld.cld_at(i);
> 759:       for (Klass* klass = cld->klasses(); klass != nullptr; klass = klass->next_link()) {

Why doesn't this call loaded_classes_do() ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24172#discussion_r2013968090

From mbaesken at openjdk.org  Wed Mar 26 14:29:47 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Mar 2025 14:29:47 GMT
Subject: RFR: 8352946: SEGV_BND signal code of SIGSEGV missing from our
 signal-code table
Message-ID: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>

On Linux we had recently a crash looking like this


siginfo_t @ 0x00007fff2723dc98:
  Signal: 11 (SIGSEGV)
  Signal Code: 3 (unknown signal code)
  Address of faulting memory reference: 0x007fff8c31629838


Seems signal code 3 is
`#define SEGV_BNDERR 3 /* failed address bound checks */`

so we should add this to our signal code table; on AIX I cannot find this code so it might be Linux-only.
Even on Linux the define is not always available in the system headers so we better add a define .

-------------

Commit messages:
 - JDK-8352946

Changes: https://git.openjdk.org/jdk/pull/24255/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24255&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352946
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24255.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24255/head:pull/24255

PR: https://git.openjdk.org/jdk/pull/24255

From jsjolen at openjdk.org  Wed Mar 26 14:35:13 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 26 Mar 2025 14:35:13 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v7]
In-Reply-To: <zbJUb5iseGf6BA_NVOmgf81Ucza5NeRPUgfHZvzsb7g=.6e5a7c0f-b20e-497e-87f4-c5414fa5858d@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <zbJUb5iseGf6BA_NVOmgf81Ucza5NeRPUgfHZvzsb7g=.6e5a7c0f-b20e-497e-87f4-c5414fa5858d@github.com>
Message-ID: <QXU-t_9x5UeqruELxP8JQ7mrXtcCZeXDMm1zQLuQ9PE=.61b00f5c-a132-4356-ac15-072e507fe590@github.com>

On Tue, 25 Mar 2025 14:57:04 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix the GHA failures.

OK,

This seems good to me. Thanks!

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2717480259

From jiangli at openjdk.org  Wed Mar 26 16:40:19 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Mar 2025 16:40:19 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v3]
In-Reply-To: <y_YNwL-qOHh9RO9rBQVhuj_pHtiwZ4GHzlfrpaI1_qw=.0820bac4-5ec7-4460-8aa6-20f320181e1e@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <35G0hqgMGHVzjo6j8oj3UqySFKkiGlFjkSrXorCbe4g=.7790d883-0261-47dc-a731-1b9f98840633@github.com>
 <y_YNwL-qOHh9RO9rBQVhuj_pHtiwZ4GHzlfrpaI1_qw=.0820bac4-5ec7-4460-8aa6-20f320181e1e@github.com>
Message-ID: <K095d9uiT2aWZmWe-TXUjwTRsUmvGjSky0cly2ZLQgs=.79a7ecab-47bc-44a1-a7cd-8a203e568372@github.com>

On Wed, 26 Mar 2025 06:02:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address @dholmes-ora's comment: Use `strlen` to get the length for ", static" and ", sharing".
>
> Thanks for the updates. That seems okay to me.

Thanks for the review and suggestions, @dholmes-ora!

Could anyone help with a second review for this, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24171#issuecomment-2755050457

From shade at openjdk.org  Wed Mar 26 17:35:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Mar 2025 17:35:16 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106 [v2]
In-Reply-To: <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
 <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
Message-ID: <IfoloHQsdOsS-TTr9YbEvppWBnj58KPQeoMM71qj7cM=.45e9b980-0b5f-42a9-bf3c-3ca11d6f5cca@github.com>

On Tue, 25 Mar 2025 20:19:30 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> Add missing header to resolve the compilation failure.
>> 
>> Testing:
>>  - built openjdk in PPC qemu vm.
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix: use generic os_linux.hpp

Looks good for me, thanks!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24216#pullrequestreview-2718079704

From shade at openjdk.org  Wed Mar 26 17:35:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Mar 2025 17:35:17 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106 [v2]
In-Reply-To: <BwgAHVDBEUkLHcm_imKuRnHg37csXjPlBvK3xVq_KAw=.b12c0340-cb90-45f4-a97b-a160cfb50007@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
 <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
 <BwgAHVDBEUkLHcm_imKuRnHg37csXjPlBvK3xVq_KAw=.b12c0340-cb90-45f4-a97b-a160cfb50007@github.com>
Message-ID: <C3MI-f3D_J7pIpfsA5Xlvfb2f3VMnP62Ucr-VLmGtqA=.682d3d2a-86d7-489a-8aa7-25b33939d7f0@github.com>

On Wed, 26 Mar 2025 07:20:29 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix: use generic os_linux.hpp
>
> src/hotspot/os_cpu/linux_ppc/javaThread_linux_ppc.cpp line 27:
> 
>> 25: 
>> 26: #include "memory/metaspace.hpp"
>> 27: #include "os_linux.hpp"
> 
> I think you should include `os_linux.inline.hpp` (according to the [style-guide](https://github.com/openjdk/jdk/blob/2e4d7d1846d846fd98201b9b3abeb7b91239a40d/doc/hotspot-style.md?plain=1#L163)).

Not really? I think that rule only says "do not include `os_linux.hpp` if `os_linux.inline.hpp` is already included". We do not include `os_linux.inline.hpp`, so we should include just the `os_linux.hpp`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24216#discussion_r2014671300

From shade at openjdk.org  Wed Mar 26 17:38:15 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Mar 2025 17:38:15 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log
In-Reply-To: <sZv0FzRRLRSLo8R_Iq2OG7hZktGpFMvHdRGAVOhMOiA=.26b0e4e8-51ff-4e24-8dd0-f05ba2c0f93d@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
 <xCBXaORe0jcNod3su9nEctPzUAZtzrYPiiSmD-K-xtY=.dbe5fcaa-fbe8-48cf-bb48-ad09f7d3954a@github.com>
 <sZv0FzRRLRSLo8R_Iq2OG7hZktGpFMvHdRGAVOhMOiA=.26b0e4e8-51ff-4e24-8dd0-f05ba2c0f93d@github.com>
Message-ID: <_3QEhfeXB-l7Wp2i26op0awRB2z0NFYfMZ8vkv2CAVI=.e04c6ca5-9dbe-4456-b783-a6d13bd8b4ec@github.com>

On Tue, 25 Mar 2025 22:55:37 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/share/cds/metaspaceShared.cpp line 1169:
>> 
>>> 1167:     dynamic_mapinfo = open_dynamic_archive();
>>> 1168: 
>>> 1169:     log_info(cds)("ArchiveRelocationMode = %d", ArchiveRelocationMode);
>> 
>> Looks like the style in adjacent output is `Archive relocation mode: %d`. How does the `-Xlog:cds` look with this change?
>
> With ArchiveRelocationMode = 0
> 
> [0.042s][info][cds] ArchiveRelocationMode = 0
> [0.042s][info][cds] Reserved archive_space_rs [0x0000000800000000 - 0x0000000801000000] (16777216) bytes
> [0.042s][info][cds] Reserved class_space_rs   [0x0000000801000000 - 0x0000000841000000] (1073741824) bytes
> [0.042s][info][cds] Mapped static  region #0 at base 0x0000000800000000 top 0x000000080055d000 (ReadWrite)
> [0.042s][info][cds] Mapped static  region #1 at base 0x000000080055d000 top 0x0000000800e05000 (ReadOnly)
> [0.042s][info][cds] _archived_main_module_name (null)
> [0.042s][info][cds] jdk.module.main (null)
> [0.042s][info][cds] optimized module handling: enabled
> [0.042s][info][cds] full module graph: enabled
> [0.042s][info][cds] jdk.module.addmods (null)
> [0.042s][info][cds] optimized module handling: enabled
> [0.042s][info][cds] full module graph: enabled
> [0.042s][info][cds] jdk.module.enable.native.access (null)
> [0.042s][info][cds] optimized module handling: enabled
> [0.042s][info][cds] full module graph: enabled
> 
> 
> With ArchiveRelocationMode = 1
> 
> [0.042s][info][cds] ArchiveRelocationMode = 1
> [0.042s][info][cds] Reserved archive_space_rs [0x0000000800000000 - 0x0000000801000000] (16777216) bytes
> [0.042s][info][cds] Reserved class_space_rs   [0x0000000801000000 - 0x0000000841000000] (1073741824) bytes
> [0.042s][info][cds] Mapped static  region #0 at base 0x0000000800000000 top 0x000000080055d000 (ReadWrite)
> [0.042s][info][cds] Mapped static  region #1 at base 0x000000080055d000 top 0x0000000800e05000 (ReadOnly)
> [0.042s][info][cds] _archived_main_module_name (null)
> [0.042s][info][cds] jdk.module.main (null)
> [0.042s][info][cds] optimized module handling: enabled
> [0.042s][info][cds] full module graph: enabled
> [0.042s][info][cds] jdk.module.addmods (null)
> [0.042s][info][cds] optimized module handling: enabled
> [0.042s][info][cds] full module graph: enabled
> [0.042s][info][cds] jdk.module.enable.native.access (null)
> [0.042s][info][cds] optimized module handling: enabled
> [0.042s][info][cds] full module graph: enabled
> [0.042s][info][cds] ArchiveRelocationMode == 1: always map archive(s) at an alternative address

Yeah, it's just the logging line just 3 lines earlier says: `Core region alignment: %zu`, so maybe match that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23878#discussion_r2014680501

From ccheung at openjdk.org  Wed Mar 26 17:48:17 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 26 Mar 2025 17:48:17 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v2]
In-Reply-To: <gC2sHYWT3OwonissrywET7hat7IvvrrDSxQZbNcO2KU=.529bf399-5ad7-461a-aafd-f5375397d7d4@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
 <gC2sHYWT3OwonissrywET7hat7IvvrrDSxQZbNcO2KU=.529bf399-5ad7-461a-aafd-f5375397d7d4@github.com>
Message-ID: <pg6YWFNk-3JJn08ov2P3wkY_eyOmOVgKZOTeQelZEDE=.4dbd4e37-3c0f-4f4f-9206-4baac3349141@github.com>

On Wed, 19 Mar 2025 23:03:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.
>> 
>> Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:
>> 
>> https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
>> 
>> This PR adds a few new classes to simplify the test cases:
>> 
>> Example: build two modular JAR files into `modulePath`
>> 
>> 
>> CDSModulePackager modulePackager = new CDSModulePackager(SRC);
>> modulePath = modulePackager.getOutputDir().toString();
>> 
>> modulePackager.createModularJar("com.foos");
>> modulePackager.createModularJar("com.needsfoosaddexport",
>>                                 "--add-exports",
>>                                 "com.foos/com.foos.internal=com.needsfoosaddexport");
>> 
>> 
>> Example: use modules in training/assembly/production phases
>> 
>> 
>> SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
>>    .classpath(dummyJar)
>>    .modulepath(modulePath)
>>    .addVmArgs("--add-modules", "com.needsjdkaddexport",
>>               "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
>>    .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
>>    .setAssemblyChecker((OutputAnalyzer out) -> {
>>            out.shouldContain("Full module graph = enabled");
>>         })
>>     .setProductionChecker((OutputAnalyzer out) -> {
>>             out.shouldContain("use_full_module_graph = true; java.base");
>>         })
>>     .runStaticWorkflow()
>>     .runAOTWorkflow();
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments

Found some nits. Looks good otherwise.

test/lib/jdk/test/lib/cds/CDSJarUtils.java line 224:

> 222:             }
> 223:         }
> 224:         System.out.println();

Should this be printed only if DEBUG is enabled?

test/lib/jdk/test/lib/cds/CDSModulePackager.java line 28:

> 26: 
> 27: import java.io.File;
> 28: import java.nio.file.Files;

Unused import.

test/lib/jdk/test/lib/cds/CDSModulePackager.java line 33:

> 31: import jdk.test.lib.StringArrayUtils;
> 32: import jdk.test.lib.compiler.CompilerUtils;
> 33: import jdk.test.lib.util.FileUtils;

Unused import.

test/lib/jdk/test/lib/cds/SimpleCDSAppTester.java line 29:

> 27: import jdk.test.lib.Asserts;
> 28: import jdk.test.lib.cds.CDSTestUtils;
> 29: import jdk.test.lib.process.ProcessTools;

Unused import.

test/lib/jdk/test/lib/cds/SimpleCDSAppTester.java line 33:

> 31: import jdk.test.lib.StringArrayUtils;
> 32: import jdk.test.whitebox.WhiteBox;
> 33: import jtreg.SkippedException;

Unused import.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24122#pullrequestreview-2718081398
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014672929
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014678719
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014683065
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014699055
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014713064

From shade at openjdk.org  Wed Mar 26 17:50:24 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Mar 2025 17:50:24 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v3]
In-Reply-To: <35G0hqgMGHVzjo6j8oj3UqySFKkiGlFjkSrXorCbe4g=.7790d883-0261-47dc-a731-1b9f98840633@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <35G0hqgMGHVzjo6j8oj3UqySFKkiGlFjkSrXorCbe4g=.7790d883-0261-47dc-a731-1b9f98840633@github.com>
Message-ID: <CT6mRVhZQFnISm0VvsfhjYNb3btI3H3rJDRG0DckiTc=.c2aa4523-f5ab-4f63-9a09-550c24a53358@github.com>

On Tue, 25 Mar 2025 15:25:56 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review following changes, thanks.
>> 
>> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
>> 
>> 
>> $ static-jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
>> 
>> $ jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
>> 
>> 
>> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
>> 
>> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
>> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
>> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @dholmes-ora's comment: Use `strlen` to get the length for ", static" and ", sharing".

Looks basically fine, just nits:

src/hotspot/share/runtime/abstract_vm_version.cpp line 167:

> 165:   const char* sharing_info = ", sharing";
> 166:   size_t len = strlen(mode) + (is_vm_statically_linked() ? strlen(static_info) : 0) +
> 167:                (CDSConfig::is_using_archive() ? strlen(sharing_info) : 0) + 1;

Make it easier to add new cases:

Suggestion:

  size_t len = strlen(mode) +
               (is_vm_statically_linked() ? strlen(static_info) : 0) +
               (CDSConfig::is_using_archive() ? strlen(sharing_info) : 0) + 
               1;

test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java line 56:

> 54: 
> 55:     /* Used to start the JVM with the same type as current */
> 56:     static String VMType = null;

No need, `static`-s are implicitly initialized to `null`. Otherwise there is a style question why any other fields are not initialized! Maybe initialize it straight in `clinit`, like `GCType` is initialized.

test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java line 71:

> 69:             } else if (Platform.isMinimal()) {
> 70:                 VMType = "-minimal";
> 71:             }

OK, so `isStatic` supercedes everything? Then just add a preceding block, like:


if (Platform.isStatic()) {
    // In static JDK, no launcher options are accepted.
    VMType = null;
} else if (Platform.isServer()) {
    VMType = "-server";
} else if (Platform.isClient()) {
    VMType = "-client";
} else if (Platform.isMinimal()) {
    VMType = "-minimal";
} else {
    VMType = null;
}


?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24171#pullrequestreview-2718108323
PR Review Comment: https://git.openjdk.org/jdk/pull/24171#discussion_r2014724228
PR Review Comment: https://git.openjdk.org/jdk/pull/24171#discussion_r2014690413
PR Review Comment: https://git.openjdk.org/jdk/pull/24171#discussion_r2014719650

From jiangli at openjdk.org  Wed Mar 26 19:28:24 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Mar 2025 19:28:24 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v4]
In-Reply-To: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
Message-ID: <EI6oxbfApre5ajFHVRWwQ3ZYjQZAF7JxR7SPOPBLebc=.e1dd4b90-917a-427b-8ee5-906d7866c9e4@github.com>

> Please review following changes, thanks.
> 
> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
> 
> 
> $ static-jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
> 
> $ jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
> 
> 
> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
> 
> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Address @shipilev comments:
  - In JVMOptionsUtils.<clinit>, make `if (Platform.isStatic())` block as a preceding block of other checks.
  - In Abstract_VM_Version::vm_info_string(), break lines.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24171/files
  - new: https://git.openjdk.org/jdk/pull/24171/files/bfaa6e48..b059c11c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24171&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24171&range=02-03

  Stats: 16 lines in 2 files changed: 5 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24171/head:pull/24171

PR: https://git.openjdk.org/jdk/pull/24171

From jiangli at openjdk.org  Wed Mar 26 19:28:24 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Mar 2025 19:28:24 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v3]
In-Reply-To: <CT6mRVhZQFnISm0VvsfhjYNb3btI3H3rJDRG0DckiTc=.c2aa4523-f5ab-4f63-9a09-550c24a53358@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <35G0hqgMGHVzjo6j8oj3UqySFKkiGlFjkSrXorCbe4g=.7790d883-0261-47dc-a731-1b9f98840633@github.com>
 <CT6mRVhZQFnISm0VvsfhjYNb3btI3H3rJDRG0DckiTc=.c2aa4523-f5ab-4f63-9a09-550c24a53358@github.com>
Message-ID: <vZ2vPNPpRpsQImC0YGW79s9xCXu6rBJ9BVyyQ7kjRWU=.a0f7ad16-019e-4378-9689-b90074a3f6c7@github.com>

On Wed, 26 Mar 2025 17:46:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address @dholmes-ora's comment: Use `strlen` to get the length for ", static" and ", sharing".
>
> src/hotspot/share/runtime/abstract_vm_version.cpp line 167:
> 
>> 165:   const char* sharing_info = ", sharing";
>> 166:   size_t len = strlen(mode) + (is_vm_statically_linked() ? strlen(static_info) : 0) +
>> 167:                (CDSConfig::is_using_archive() ? strlen(sharing_info) : 0) + 1;
> 
> Make it easier to add new cases:
> 
> Suggestion:
> 
>   size_t len = strlen(mode) +
>                (is_vm_statically_linked() ? strlen(static_info) : 0) +
>                (CDSConfig::is_using_archive() ? strlen(sharing_info) : 0) + 
>                1;

Done.

> test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java line 71:
> 
>> 69:             } else if (Platform.isMinimal()) {
>> 70:                 VMType = "-minimal";
>> 71:             }
> 
> OK, so `isStatic` supercedes everything? Then just add a preceding block, like:
> 
> 
> if (Platform.isStatic()) {
>     // In static JDK, no launcher options are accepted.
>     VMType = null;
> } else if (Platform.isServer()) {
>     VMType = "-server";
> } else if (Platform.isClient()) {
>     VMType = "-client";
> } else if (Platform.isMinimal()) {
>     VMType = "-minimal";
> } else {
>     VMType = null;
> }
> 
> 
> ?

Suggestion applied.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24171#discussion_r2014863778
PR Review Comment: https://git.openjdk.org/jdk/pull/24171#discussion_r2014863579

From jiangli at openjdk.org  Wed Mar 26 19:36:11 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 26 Mar 2025 19:36:11 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v3]
In-Reply-To: <CT6mRVhZQFnISm0VvsfhjYNb3btI3H3rJDRG0DckiTc=.c2aa4523-f5ab-4f63-9a09-550c24a53358@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <35G0hqgMGHVzjo6j8oj3UqySFKkiGlFjkSrXorCbe4g=.7790d883-0261-47dc-a731-1b9f98840633@github.com>
 <CT6mRVhZQFnISm0VvsfhjYNb3btI3H3rJDRG0DckiTc=.c2aa4523-f5ab-4f63-9a09-550c24a53358@github.com>
Message-ID: <g0xyVhftK6k4fh5vkcgOV8F-rWU8ZMwxLLza728A1UY=.a88c340c-b07c-4e15-ad7c-c411ba598875@github.com>

On Wed, 26 Mar 2025 17:47:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks basically fine, just nits:

Thanks for reviewing, @shipilev!

Please help re-approve after update.

> test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOptionsUtils.java line 56:
> 
>> 54: 
>> 55:     /* Used to start the JVM with the same type as current */
>> 56:     static String VMType = null;
> 
> No need, `static`-s are implicitly initialized to `null`. Otherwise there is a style question why any other fields are not initialized! Maybe initialize it straight in `clinit`, like `GCType` is initialized.

Right, static field with reference type has null as the default value. Took your other suggestion in the `clinit` and remove `= null` here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24171#issuecomment-2755551969
PR Review Comment: https://git.openjdk.org/jdk/pull/24171#discussion_r2014872570

From iklam at openjdk.org  Wed Mar 26 19:42:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 26 Mar 2025 19:42:29 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v3]
In-Reply-To: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
Message-ID: <O-k2s8OLNennU8Y0AngztjFK25kHWIrzjsF9bzfScgs=.0e031ca8-7b16-4aa0-8f2d-ab760d18b1eb@github.com>

> In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.
> 
> Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:
> 
> https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
> 
> This PR adds a few new classes to simplify the test cases:
> 
> Example: build two modular JAR files into `modulePath`
> 
> 
> CDSModulePackager modulePackager = new CDSModulePackager(SRC);
> modulePath = modulePackager.getOutputDir().toString();
> 
> modulePackager.createModularJar("com.foos");
> modulePackager.createModularJar("com.needsfoosaddexport",
>                                 "--add-exports",
>                                 "com.foos/com.foos.internal=com.needsfoosaddexport");
> 
> 
> Example: use modules in training/assembly/production phases
> 
> 
> SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
>    .classpath(dummyJar)
>    .modulepath(modulePath)
>    .addVmArgs("--add-modules", "com.needsjdkaddexport",
>               "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
>    .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
>    .setAssemblyChecker((OutputAnalyzer out) -> {
>            out.shouldContain("Full module graph = enabled");
>         })
>     .setProductionChecker((OutputAnalyzer out) -> {
>             out.shouldContain("use_full_module_graph = true; java.base");
>         })
>     .runStaticWorkflow()
>     .runAOTWorkflow();

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - @calvinccheung comments
 - @shipilev comments; renamed variables in ExportModule.java for clarity

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24122/files
  - new: https://git.openjdk.org/jdk/pull/24122/files/6a95590b..79879423

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24122&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24122&range=01-02

  Stats: 33 lines in 4 files changed: 9 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24122/head:pull/24122

PR: https://git.openjdk.org/jdk/pull/24122

From iklam at openjdk.org  Wed Mar 26 19:42:30 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 26 Mar 2025 19:42:30 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v2]
In-Reply-To: <pg6YWFNk-3JJn08ov2P3wkY_eyOmOVgKZOTeQelZEDE=.4dbd4e37-3c0f-4f4f-9206-4baac3349141@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
 <gC2sHYWT3OwonissrywET7hat7IvvrrDSxQZbNcO2KU=.529bf399-5ad7-461a-aafd-f5375397d7d4@github.com>
 <pg6YWFNk-3JJn08ov2P3wkY_eyOmOVgKZOTeQelZEDE=.4dbd4e37-3c0f-4f4f-9206-4baac3349141@github.com>
Message-ID: <B1BLFFuCd4nWlC7iLfEY96EStAFTV7a6s26nsY4mvaY=.f8e1ab76-8577-4730-b191-927b4dbcbb9f@github.com>

On Wed, 26 Mar 2025 17:32:17 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added comments
>
> test/lib/jdk/test/lib/cds/CDSJarUtils.java line 224:
> 
>> 222:             }
>> 223:         }
>> 224:         System.out.println();
> 
> Should this be printed only if DEBUG is enabled?

I think it's better to always print the files being compiled, as jtreg also does the same thing for files that it compiles. That way it's easy to diagnose problems in the test source code.

> test/lib/jdk/test/lib/cds/CDSModulePackager.java line 28:
> 
>> 26: 
>> 27: import java.io.File;
>> 28: import java.nio.file.Files;
> 
> Unused import.

Fixed

> test/lib/jdk/test/lib/cds/CDSModulePackager.java line 33:
> 
>> 31: import jdk.test.lib.StringArrayUtils;
>> 32: import jdk.test.lib.compiler.CompilerUtils;
>> 33: import jdk.test.lib.util.FileUtils;
> 
> Unused import.

Fixed

> test/lib/jdk/test/lib/cds/SimpleCDSAppTester.java line 29:
> 
>> 27: import jdk.test.lib.Asserts;
>> 28: import jdk.test.lib.cds.CDSTestUtils;
>> 29: import jdk.test.lib.process.ProcessTools;
> 
> Unused import.

Fixed

> test/lib/jdk/test/lib/cds/SimpleCDSAppTester.java line 33:
> 
>> 31: import jdk.test.lib.StringArrayUtils;
>> 32: import jdk.test.whitebox.WhiteBox;
>> 33: import jtreg.SkippedException;
> 
> Unused import.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014892588
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014893047
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014892969
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014892931
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014892879

From iklam at openjdk.org  Wed Mar 26 19:42:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 26 Mar 2025 19:42:29 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v2]
In-Reply-To: <QDzCp9sYJcsIy69MreT16zRLkLGACWWLiJGJU-2pIUM=.9da43d3f-98c0-4f05-b26c-b65d7e766c57@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
 <gC2sHYWT3OwonissrywET7hat7IvvrrDSxQZbNcO2KU=.529bf399-5ad7-461a-aafd-f5375397d7d4@github.com>
 <QDzCp9sYJcsIy69MreT16zRLkLGACWWLiJGJU-2pIUM=.9da43d3f-98c0-4f05-b26c-b65d7e766c57@github.com>
Message-ID: <-Gqbmb15-ZN7KPyZMDTPXu1KmF3undccdYX8aRWJ4AQ=.d049cd8a-41aa-4084-a2bf-0e8f73f51955@github.com>

On Tue, 25 Mar 2025 17:55:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added comments
>
> test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java line 111:
> 
>> 109:         String MAIN_CLASS = "com.foos.Test";
>> 110: 
>> 111:         String appClasses[] = {MAIN_CLASS};
> 
> Suggestion:
> 
>         String[] appClasses = {MAIN_CLASS};

Fixed.

> test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java line 99:
> 
>> 97:         OutputAnalyzer output = TestCommon.createArchive(
>> 98:                                         appJar1.toString(), appClasses,
>> 99:                                         "--module-path", moduleDir2.toString(),
> 
> Is this correct to use `appJar1` but `moduleDir2`?

This is actually correct but it's not clear from the names of the variables. I've updated the names and added comments for clarification (but otherwise the logic is unchanged).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014889730
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2014889677

From ccheung at openjdk.org  Wed Mar 26 19:46:02 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 26 Mar 2025 19:46:02 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log [v2]
In-Reply-To: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
Message-ID: <Xhz0Eg9ksPSNq3jWNFVuMD9hkPIHwENz-kvO-HwCBOk=.cf603204-a94b-4db9-94e2-88f46e91d40e@github.com>

> Always include the ArchiveRelocationMode in the CDS info log. Before this fix, ArchiveRelocationMode is not in the log if it is set to 0.
> The ArchiveRelocationMode default value was set to 1 about 2 years ago. Some tests need to be updated accordingly.
> 
> Testing:
> 
> - ran the modified tests manually on linux-x64
> - tier1

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @shipilev comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23878/files
  - new: https://git.openjdk.org/jdk/pull/23878/files/d1589451..7f8e72a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23878&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23878&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23878/head:pull/23878

PR: https://git.openjdk.org/jdk/pull/23878

From ccheung at openjdk.org  Wed Mar 26 19:46:03 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 26 Mar 2025 19:46:03 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log [v2]
In-Reply-To: <_3QEhfeXB-l7Wp2i26op0awRB2z0NFYfMZ8vkv2CAVI=.e04c6ca5-9dbe-4456-b783-a6d13bd8b4ec@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
 <xCBXaORe0jcNod3su9nEctPzUAZtzrYPiiSmD-K-xtY=.dbe5fcaa-fbe8-48cf-bb48-ad09f7d3954a@github.com>
 <sZv0FzRRLRSLo8R_Iq2OG7hZktGpFMvHdRGAVOhMOiA=.26b0e4e8-51ff-4e24-8dd0-f05ba2c0f93d@github.com>
 <_3QEhfeXB-l7Wp2i26op0awRB2z0NFYfMZ8vkv2CAVI=.e04c6ca5-9dbe-4456-b783-a6d13bd8b4ec@github.com>
Message-ID: <7B7ddNz6s1OdEIdScn5MoRlWke3EsArAAphcVeblrgk=.25cfa2ac-c135-413d-8dc8-51a990c56cd4@github.com>

On Wed, 26 Mar 2025 17:35:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> With ArchiveRelocationMode = 0
>> 
>> [0.042s][info][cds] ArchiveRelocationMode = 0
>> [0.042s][info][cds] Reserved archive_space_rs [0x0000000800000000 - 0x0000000801000000] (16777216) bytes
>> [0.042s][info][cds] Reserved class_space_rs   [0x0000000801000000 - 0x0000000841000000] (1073741824) bytes
>> [0.042s][info][cds] Mapped static  region #0 at base 0x0000000800000000 top 0x000000080055d000 (ReadWrite)
>> [0.042s][info][cds] Mapped static  region #1 at base 0x000000080055d000 top 0x0000000800e05000 (ReadOnly)
>> [0.042s][info][cds] _archived_main_module_name (null)
>> [0.042s][info][cds] jdk.module.main (null)
>> [0.042s][info][cds] optimized module handling: enabled
>> [0.042s][info][cds] full module graph: enabled
>> [0.042s][info][cds] jdk.module.addmods (null)
>> [0.042s][info][cds] optimized module handling: enabled
>> [0.042s][info][cds] full module graph: enabled
>> [0.042s][info][cds] jdk.module.enable.native.access (null)
>> [0.042s][info][cds] optimized module handling: enabled
>> [0.042s][info][cds] full module graph: enabled
>> 
>> 
>> With ArchiveRelocationMode = 1
>> 
>> [0.042s][info][cds] ArchiveRelocationMode = 1
>> [0.042s][info][cds] Reserved archive_space_rs [0x0000000800000000 - 0x0000000801000000] (16777216) bytes
>> [0.042s][info][cds] Reserved class_space_rs   [0x0000000801000000 - 0x0000000841000000] (1073741824) bytes
>> [0.042s][info][cds] Mapped static  region #0 at base 0x0000000800000000 top 0x000000080055d000 (ReadWrite)
>> [0.042s][info][cds] Mapped static  region #1 at base 0x000000080055d000 top 0x0000000800e05000 (ReadOnly)
>> [0.042s][info][cds] _archived_main_module_name (null)
>> [0.042s][info][cds] jdk.module.main (null)
>> [0.042s][info][cds] optimized module handling: enabled
>> [0.042s][info][cds] full module graph: enabled
>> [0.042s][info][cds] jdk.module.addmods (null)
>> [0.042s][info][cds] optimized module handling: enabled
>> [0.042s][info][cds] full module graph: enabled
>> [0.042s][info][cds] jdk.module.enable.native.access (null)
>> [0.042s][info][cds] optimized module handling: enabled
>> [0.042s][info][cds] full module graph: enabled
>> [0.042s][info][cds] ArchiveRelocationMode == 1: always map archive(s) at an alternative address
>
> Yeah, it's just the logging line just 3 lines earlier says: `Core region alignment: %zu`, so maybe match that?

I've updated the fix based on your suggestion.
Now, the log looks as follows:

[0.042s][info][cds] Core region alignment: 4096
[0.042s][info][cds] ArchiveRelocationMode: 0
[0.042s][info][cds] Reserved archive_space_rs [0x0000000800000000 - 0x0000000801000000] (16777216) bytes

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23878#discussion_r2014896128

From shade at openjdk.org  Wed Mar 26 20:00:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Mar 2025 20:00:09 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log [v2]
In-Reply-To: <Xhz0Eg9ksPSNq3jWNFVuMD9hkPIHwENz-kvO-HwCBOk=.cf603204-a94b-4db9-94e2-88f46e91d40e@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
 <Xhz0Eg9ksPSNq3jWNFVuMD9hkPIHwENz-kvO-HwCBOk=.cf603204-a94b-4db9-94e2-88f46e91d40e@github.com>
Message-ID: <slgHbTn0nPUCPOVdOJJ_1CcKE9W6ytsAd6mhzSUzeLg=.0a6d7444-33b8-4a10-9838-db78745818b6@github.com>

On Wed, 26 Mar 2025 19:46:02 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Always include the ArchiveRelocationMode in the CDS info log. Before this fix, ArchiveRelocationMode is not in the log if it is set to 0.
>> The ArchiveRelocationMode default value was set to 1 about 2 years ago. Some tests need to be updated accordingly.
>> 
>> Testing:
>> 
>> - ran the modified tests manually on linux-x64
>> - tier1
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @shipilev comment

Still good!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23878#pullrequestreview-2718483126

From shade at openjdk.org  Wed Mar 26 20:02:15 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Mar 2025 20:02:15 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v4]
In-Reply-To: <EI6oxbfApre5ajFHVRWwQ3ZYjQZAF7JxR7SPOPBLebc=.e1dd4b90-917a-427b-8ee5-906d7866c9e4@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <EI6oxbfApre5ajFHVRWwQ3ZYjQZAF7JxR7SPOPBLebc=.e1dd4b90-917a-427b-8ee5-906d7866c9e4@github.com>
Message-ID: <NSpBZ81yAcDpTYZiEhJmQH50RqTUbFJ--UOltUgrosQ=.8d10c303-ac37-4d0c-9fa8-03d5e5aa38de@github.com>

On Wed, 26 Mar 2025 19:28:24 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review following changes, thanks.
>> 
>> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
>> 
>> 
>> $ static-jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
>> 
>> $ jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
>> 
>> 
>> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
>> 
>> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
>> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
>> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @shipilev comments:
>   - In JVMOptionsUtils.<clinit>, make `if (Platform.isStatic())` block as a preceding block of other checks.
>   - In Abstract_VM_Version::vm_info_string(), break lines.

Looks fine, thanks!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24171#pullrequestreview-2718487126

From rrich at openjdk.org  Wed Mar 26 20:24:10 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 26 Mar 2025 20:24:10 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106 [v2]
In-Reply-To: <C3MI-f3D_J7pIpfsA5Xlvfb2f3VMnP62Ucr-VLmGtqA=.682d3d2a-86d7-489a-8aa7-25b33939d7f0@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
 <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
 <BwgAHVDBEUkLHcm_imKuRnHg37csXjPlBvK3xVq_KAw=.b12c0340-cb90-45f4-a97b-a160cfb50007@github.com>
 <C3MI-f3D_J7pIpfsA5Xlvfb2f3VMnP62Ucr-VLmGtqA=.682d3d2a-86d7-489a-8aa7-25b33939d7f0@github.com>
Message-ID: <ERxXxuOWDlER2HpvPK8jkuJwsRhi3nICIvRpn_Ro3p4=.bf898f44-0b23-4964-82b8-a0f69d8d8629@github.com>

On Wed, 26 Mar 2025 17:31:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/os_cpu/linux_ppc/javaThread_linux_ppc.cpp line 27:
>> 
>>> 25: 
>>> 26: #include "memory/metaspace.hpp"
>>> 27: #include "os_linux.hpp"
>> 
>> I think you should include `os_linux.inline.hpp` (according to the [style-guide](https://github.com/openjdk/jdk/blob/2e4d7d1846d846fd98201b9b3abeb7b91239a40d/doc/hotspot-style.md?plain=1#L163)).
>
> Not really? I think that rule only says "do not include `os_linux.hpp` if `os_linux.inline.hpp` is already included". We do not include `os_linux.inline.hpp`, so we should include just the `os_linux.hpp`.

You're right. I misread this rule as a rule I expected to exist too (always prefer the *.inline.hpp over *.hpp).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24216#discussion_r2014944203

From rrich at openjdk.org  Wed Mar 26 20:24:09 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 26 Mar 2025 20:24:09 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106 [v2]
In-Reply-To: <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
 <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
Message-ID: <gyBQjZ-q3cP7zYnFVq0CuNpEAMju59yxyW7mTD2q1Sg=.0e3d2c4b-201a-4d54-895d-5851970de79c@github.com>

On Tue, 25 Mar 2025 20:19:30 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> Add missing header to resolve the compilation failure.
>> 
>> Testing:
>>  - built openjdk in PPC qemu vm.
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix: use generic os_linux.hpp

Marked as reviewed by rrich (Reviewer).

Looks good to me.
Thanks, Richard.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24216#pullrequestreview-2718533683
PR Comment: https://git.openjdk.org/jdk/pull/24216#issuecomment-2755663089

From duke at openjdk.org  Wed Mar 26 21:49:13 2025
From: duke at openjdk.org (duke)
Date: Wed, 26 Mar 2025 21:49:13 GMT
Subject: RFR: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106 [v2]
In-Reply-To: <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
 <4hOToYFvISjdlZpYHdst5OOsOm8SciTRz_V8HwsbKvY=.46354660-5511-4f8c-9d6a-962ddd3def5d@github.com>
Message-ID: <QZviz0yCtkdVzBIGX2zp917EiHI4ZTRSycXafB0U4gY=.cdac4651-54e1-47e7-8954-324e7e36eb0f@github.com>

On Tue, 25 Mar 2025 20:19:30 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> Add missing header to resolve the compilation failure.
>> 
>> Testing:
>>  - built openjdk in PPC qemu vm.
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix: use generic os_linux.hpp

@vpa1977 
Your change (at version 2a64115258dadef740423e5d8aad48f5c73fb42f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24216#issuecomment-2755817887

From sspitsyn at openjdk.org  Wed Mar 26 22:55:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Mar 2025 22:55:34 GMT
Subject: RFR: 8316397:
 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with:
 SingleStep event is NOT expected [v6]
In-Reply-To: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
References: <WJgllMayrNpYJ-wGtFFSIQfX2QopMinAX2k6tACg0hU=.160bc0c0-93ba-42b0-b8f7-efb651504740@github.com>
Message-ID: <n_L0A3iV2kWqH3ZNbXKPaHJiIkb8moEFEcwRQD9O_gg=.175ab7fe-fb6b-4347-b2c1-69ab97daadbb@github.com>

> The `get_jvmti_thread_state()` function is called from `JvmtiExport::at_single_stepping_point()`.  It can block for virtual threads. Then the `SingleStep` events can be enabled at that point. The incorrect behavior is that the `SingleStep` events will be posted even though the virtual thread has been suspended with the JVMTI `SuspendThread`, `SuspendThreadList`, or `SuspendAllVirtualThreads`. The fix is to add a suspend point for virtual threads to the `get_jvmti_thread_state()` function.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Serguei Spitsyn 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 seven additional commits since the last revision:

 - Merge
 - Merge
 - review: move suspend point from post_single_step() to get_jvmti_thread_state()
 - Merge
 - removed obsolete fragment that was not removed in last update
 - review: re-fixed the issue as initial fix was wrong
 - 8316397: StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with: SingleStep event is NOT expected

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23490/files
  - new: https://git.openjdk.org/jdk/pull/23490/files/94cfbd5f..d6c647a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23490&range=04-05

  Stats: 51916 lines in 1623 files changed: 12164 ins; 33596 del; 6156 mod
  Patch: https://git.openjdk.org/jdk/pull/23490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23490/head:pull/23490

PR: https://git.openjdk.org/jdk/pull/23490

From dholmes at openjdk.org  Thu Mar 27 00:45:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Mar 2025 00:45:12 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v3]
In-Reply-To: <xSD92MXiQ_ST8b0G_dqh9pLvSx9gzfAFHIWxKkII6kc=.2c39b11b-063b-4c53-bbb9-95180d1a4c57@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <3L1fY17sI1HmjuMd7p2wgnydbChvf4nSxj4_G12hxwA=.71b39558-1938-40c9-bd8d-55c69c10a084@github.com>
 <xSD92MXiQ_ST8b0G_dqh9pLvSx9gzfAFHIWxKkII6kc=.2c39b11b-063b-4c53-bbb9-95180d1a4c57@github.com>
Message-ID: <9D9L7xLzGIJoVg7Q1vd6Xe-sbW19EbGnZ6BDOd8XCBk=.7864f057-2a3b-4fe0-b8c5-943c93d64ee9@github.com>

On Tue, 25 Mar 2025 06:57:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform
>
> test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 67:
> 
>> 65:         List<String> command = new ArrayList<>();
>> 66:         // Force language to English before running systeminfo to get the OS version
>> 67:         command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;C:\\Windows\\System32;C:\\Windows\\System32\\wbem", "&&"));
> 
> Not sure about hardcoding C:\Windows in tests as Windows could be installed on a different volume. Don't you need to use the value of %SystemRoot% to the directory?

I thought it unfortunate that a path needed to be specified, but there is a precedent for assuming` C:\Windows`:

./jdk/java/lang/ProcessHandle/ProcessUtil.java:   
     return Platform.isWindows() && p.info().command().orElse("").endsWith("C:\\Windows\\System32\\conhost.exe");

though a more general approach would be similar to `./jdk/java/lang/RuntimeTests/exec/WinCommand.java`:

     File systemRoot =
            getenv("SystemRoot") != null ? new File(getenv("SystemRoot")) :
            getenv("WINDIR")     != null ? new File(getenv ("WINDIR")) :
            null;
        if (systemRoot == null || ! systemRoot.isDirectory())
            return; // Not Windows as we know it

        String systemDirW = new File(systemRoot, "System32").getPath();


I was also reminded that testing under non-US-English locales is not really supported:
https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html#windows
> The recommended and supported way of building the JDK on Windows is to set both the system locale and the user locale to US English. The system setting can be changed by going to the Control Panel, choosing "Regional Settings" -> "Administrative" and then pressing on the "Change System Locale" button.
>
> Since this is annoying for users who prefer another locale, we strive to get the building and testing to work on other locales as well. This is on a "best effort" level, so beware! You might get odd results in both building and testing. If you do, remember that locales other than US English are not supported nor recommended.
>
> It is also imperative to install the US English language pack in Visual Studio. For details, see [Microsoft Visual Studio](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk/master/doc/building.html#microsoft-visual-studio).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2015184320

From ccheung at openjdk.org  Thu Mar 27 01:00:10 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 27 Mar 2025 01:00:10 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v3]
In-Reply-To: <O-k2s8OLNennU8Y0AngztjFK25kHWIrzjsF9bzfScgs=.0e031ca8-7b16-4aa0-8f2d-ab760d18b1eb@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
 <O-k2s8OLNennU8Y0AngztjFK25kHWIrzjsF9bzfScgs=.0e031ca8-7b16-4aa0-8f2d-ab760d18b1eb@github.com>
Message-ID: <wE06ru7SBWTzI67GXE-1YPtCWp3vjQDC2bGbUKqyT9A=.f79848d7-ca12-445d-b9be-b31f759fab5d@github.com>

On Wed, 26 Mar 2025 19:42:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.
>> 
>> Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:
>> 
>> https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
>> 
>> This PR adds a few new classes to simplify the test cases:
>> 
>> Example: build two modular JAR files into `modulePath`
>> 
>> 
>> CDSModulePackager modulePackager = new CDSModulePackager(SRC);
>> modulePath = modulePackager.getOutputDir().toString();
>> 
>> modulePackager.createModularJar("com.foos");
>> modulePackager.createModularJar("com.needsfoosaddexport",
>>                                 "--add-exports",
>>                                 "com.foos/com.foos.internal=com.needsfoosaddexport");
>> 
>> 
>> Example: use modules in training/assembly/production phases
>> 
>> 
>> SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
>>    .classpath(dummyJar)
>>    .modulepath(modulePath)
>>    .addVmArgs("--add-modules", "com.needsjdkaddexport",
>>               "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
>>    .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
>>    .setAssemblyChecker((OutputAnalyzer out) -> {
>>            out.shouldContain("Full module graph = enabled");
>>         })
>>     .setProductionChecker((OutputAnalyzer out) -> {
>>             out.shouldContain("use_full_module_graph = true; java.base");
>>         })
>>     .runStaticWorkflow()
>>     .runAOTWorkflow();
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - @calvinccheung comments
>  - @shipilev comments; renamed variables in ExportModule.java for clarity

You may have forgot to remove a few unused import.

test/lib/jdk/test/lib/cds/CDSModulePackager.java line 31:

> 29: import java.nio.file.Paths;
> 30: import jdk.test.lib.StringArrayUtils;
> 31: import jdk.test.lib.compiler.CompilerUtils;

I think CompilerUtils is not used.

test/lib/jdk/test/lib/cds/SimpleCDSAppTester.java line 28:

> 26: import java.io.File;
> 27: import jdk.test.lib.Asserts;
> 28: import jdk.test.lib.cds.CDSTestUtils;

I think the above two imports are not used.

test/lib/jdk/test/lib/cds/SimpleCDSAppTester.java line 31:

> 29: import jdk.test.lib.process.OutputAnalyzer;
> 30: import jdk.test.lib.StringArrayUtils;
> 31: import jdk.test.whitebox.WhiteBox;

I think WhiteBox is not used.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24122#pullrequestreview-2718942522
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2015194104
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2015194703
PR Review Comment: https://git.openjdk.org/jdk/pull/24122#discussion_r2015195310

From dholmes at openjdk.org  Thu Mar 27 01:09:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Mar 2025 01:09:09 GMT
Subject: RFR: 8352946: SEGV_BND signal code of SIGSEGV missing from our
 signal-code table
In-Reply-To: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
References: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
Message-ID: <VbfvrKRrbQyAo9uCYlfWIWuLrFEF6l4gPaxlr0O3QRs=.c20b87f3-f65a-45c5-97fc-a46ae18a1d67@github.com>

On Wed, 26 Mar 2025 14:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux we had recently a crash looking like this
> 
> 
> siginfo_t @ 0x00007fff2723dc98:
>   Signal: 11 (SIGSEGV)
>   Signal Code: 3 (unknown signal code)
>   Address of faulting memory reference: 0x007fff8c31629838
> 
> 
> Seems signal code 3 is
> `#define SEGV_BNDERR 3 /* failed address bound checks */`
> 
> so we should add this to our signal code table; on AIX I cannot find this code so it might be Linux-only.
> Even on Linux the define is not always available in the system headers so we better add a define .

FWIW there is also `SEGV_PKUERR`, but not sure we need to try and cater for every possibility here. Unless we are looking at the fields that will be set when these specific sub-signal occur, I'm not sure there is any real value in identifying them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24255#issuecomment-2756149046

From iklam at openjdk.org  Thu Mar 27 01:12:18 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Mar 2025 01:12:18 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log [v2]
In-Reply-To: <Xhz0Eg9ksPSNq3jWNFVuMD9hkPIHwENz-kvO-HwCBOk=.cf603204-a94b-4db9-94e2-88f46e91d40e@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
 <Xhz0Eg9ksPSNq3jWNFVuMD9hkPIHwENz-kvO-HwCBOk=.cf603204-a94b-4db9-94e2-88f46e91d40e@github.com>
Message-ID: <28THY5IGt2vwP4xeYl1Sh2H2onIYXMifXky1E_jZ-nE=.9b9e5372-249c-4b93-b342-9344a0ca0a00@github.com>

On Wed, 26 Mar 2025 19:46:02 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Always include the ArchiveRelocationMode in the CDS info log. Before this fix, ArchiveRelocationMode is not in the log if it is set to 0.
>> The ArchiveRelocationMode default value was set to 1 about 2 years ago. Some tests need to be updated accordingly.
>> 
>> Testing:
>> 
>> - ran the modified tests manually on linux-x64
>> - tier1
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @shipilev comment

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23878#pullrequestreview-2718986720

From iklam at openjdk.org  Thu Mar 27 01:14:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Mar 2025 01:14:08 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v4]
In-Reply-To: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
Message-ID: <Ufnwurl1wFUbM95T2VDx7o1qaVHpAh5vrT424v8fXME=.94c7a7d9-0664-46f7-9098-2ee98a8ee1c1@github.com>

> In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.
> 
> Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:
> 
> https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
> 
> This PR adds a few new classes to simplify the test cases:
> 
> Example: build two modular JAR files into `modulePath`
> 
> 
> CDSModulePackager modulePackager = new CDSModulePackager(SRC);
> modulePath = modulePackager.getOutputDir().toString();
> 
> modulePackager.createModularJar("com.foos");
> modulePackager.createModularJar("com.needsfoosaddexport",
>                                 "--add-exports",
>                                 "com.foos/com.foos.internal=com.needsfoosaddexport");
> 
> 
> Example: use modules in training/assembly/production phases
> 
> 
> SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
>    .classpath(dummyJar)
>    .modulepath(modulePath)
>    .addVmArgs("--add-modules", "com.needsjdkaddexport",
>               "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
>    .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
>    .setAssemblyChecker((OutputAnalyzer out) -> {
>            out.shouldContain("Full module graph = enabled");
>         })
>     .setProductionChecker((OutputAnalyzer out) -> {
>             out.shouldContain("use_full_module_graph = true; java.base");
>         })
>     .runStaticWorkflow()
>     .runAOTWorkflow();

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @calvinccheung comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24122/files
  - new: https://git.openjdk.org/jdk/pull/24122/files/79879423..d32b7c1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24122&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24122&range=02-03

  Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24122/head:pull/24122

PR: https://git.openjdk.org/jdk/pull/24122

From ccheung at openjdk.org  Thu Mar 27 01:31:08 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 27 Mar 2025 01:31:08 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v4]
In-Reply-To: <Ufnwurl1wFUbM95T2VDx7o1qaVHpAh5vrT424v8fXME=.94c7a7d9-0664-46f7-9098-2ee98a8ee1c1@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
 <Ufnwurl1wFUbM95T2VDx7o1qaVHpAh5vrT424v8fXME=.94c7a7d9-0664-46f7-9098-2ee98a8ee1c1@github.com>
Message-ID: <6Uzini7Tlzpxq2NpojFwBPJXWBvqYEXzSkyHA30qyS0=.da456e3e-1313-452d-91a1-639826c4a4fa@github.com>

On Thu, 27 Mar 2025 01:14:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.
>> 
>> Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:
>> 
>> https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
>> 
>> This PR adds a few new classes to simplify the test cases:
>> 
>> Example: build two modular JAR files into `modulePath`
>> 
>> 
>> CDSModulePackager modulePackager = new CDSModulePackager(SRC);
>> modulePath = modulePackager.getOutputDir().toString();
>> 
>> modulePackager.createModularJar("com.foos");
>> modulePackager.createModularJar("com.needsfoosaddexport",
>>                                 "--add-exports",
>>                                 "com.foos/com.foos.internal=com.needsfoosaddexport");
>> 
>> 
>> Example: use modules in training/assembly/production phases
>> 
>> 
>> SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
>>    .classpath(dummyJar)
>>    .modulepath(modulePath)
>>    .addVmArgs("--add-modules", "com.needsjdkaddexport",
>>               "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
>>    .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
>>    .setAssemblyChecker((OutputAnalyzer out) -> {
>>            out.shouldContain("Full module graph = enabled");
>>         })
>>     .setProductionChecker((OutputAnalyzer out) -> {
>>             out.shouldContain("use_full_module_graph = true; java.base");
>>         })
>>     .runStaticWorkflow()
>>     .runAOTWorkflow();
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung comments

Thanks for the updates.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24122#pullrequestreview-2719070767

From iklam at openjdk.org  Thu Mar 27 03:54:13 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Mar 2025 03:54:13 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <OieTDXmChXsZvFVKYPGPaTqhD6APN4GplGi9OYgtsHQ=.1c1332b4-f5f7-46b6-a16b-4370122646ad@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <OieTDXmChXsZvFVKYPGPaTqhD6APN4GplGi9OYgtsHQ=.1c1332b4-f5f7-46b6-a16b-4370122646ad@github.com>
Message-ID: <ryQrh10CV0_T1w1D8Amhv1ZpMDuEyqMJKewG2F-pcuc=.21e280ab-a50a-442a-a750-bb964e41a1cb@github.com>

On Wed, 26 Mar 2025 11:49:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
>> 
>> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.
>
> src/hotspot/share/cds/metaspaceShared.cpp line 759:
> 
>> 757:     for (int i = 0; i < collect_cld.nof_cld(); i++) {
>> 758:       ClassLoaderData* cld = collect_cld.cld_at(i);
>> 759:       for (Klass* klass = cld->klasses(); klass != nullptr; klass = klass->next_link()) {
> 
> Why doesn't this call loaded_classes_do() ?

I update the PR to use `ClassLoaderDataGraph::loaded_classes_do_keepalive()`, so there's no need to explicitly check for `is_loaded()`.

Also, instead of holding onto the ClassLoader oops which has a side effect of keeping the classes alive, I am now holding onto the Java mirrors directly. This simplifies the code and hopefully makes it easier to understand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24172#discussion_r2015558249

From iklam at openjdk.org  Thu Mar 27 03:58:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Mar 2025 03:58:48 GMT
Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache
Message-ID: <iR733lyiN_8Hq3VI8XytMA7L6c-dWIN6K4ZIMkDMjWk=.41b641f7-3a68-4dd5-ad2f-66f88e3bdab1@github.com>

When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint.

In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used.

-------------

Commit messages:
 - 8353014: Exclude AOT tooling classes from AOT cache

Changes: https://git.openjdk.org/jdk/pull/24272/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24272&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353014
  Stats: 296 lines in 14 files changed: 215 ins; 43 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/24272.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24272/head:pull/24272

PR: https://git.openjdk.org/jdk/pull/24272

From dholmes at openjdk.org  Thu Mar 27 04:40:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Mar 2025 04:40:07 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v4]
In-Reply-To: <EI6oxbfApre5ajFHVRWwQ3ZYjQZAF7JxR7SPOPBLebc=.e1dd4b90-917a-427b-8ee5-906d7866c9e4@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <EI6oxbfApre5ajFHVRWwQ3ZYjQZAF7JxR7SPOPBLebc=.e1dd4b90-917a-427b-8ee5-906d7866c9e4@github.com>
Message-ID: <PfWMqSgYP1BzUYPfR7ZKzslBBzu4c2pmUSl8hQxq5lk=.ff1a3a11-89f2-4b81-9e47-3f8c66ade682@github.com>

On Wed, 26 Mar 2025 19:28:24 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review following changes, thanks.
>> 
>> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
>> 
>> 
>> $ static-jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
>> 
>> $ jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
>> 
>> 
>> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
>> 
>> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
>> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
>> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @shipilev comments:
>   - In JVMOptionsUtils.<clinit>, make `if (Platform.isStatic())` block as a preceding block of other checks.
>   - In Abstract_VM_Version::vm_info_string(), break lines.

Updates look good.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24171#pullrequestreview-2719597887

From dholmes at openjdk.org  Thu Mar 27 04:55:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Mar 2025 04:55:06 GMT
Subject: RFR: 8352762: Use EXACTFMT instead of expanded version where
 applicable
In-Reply-To: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
References: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
Message-ID: <DoMcNyYeq2mcsw4vSVzJRVHVQc1eq_rwqLSk4k_PP08=.06d33245-bd7a-4db7-bd46-cc863888b63c@github.com>

On Tue, 25 Mar 2025 13:59:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> [JDK-8310233](https://bugs.openjdk.org/browse/JDK-8310233) introduced the EXACTFMT macro, which is a shorthand for printing exact values using methods defined in globalDefinitions.hpp. There are currently 20 places in HotSpot which uses the expanded version of the macro, along with the "trace_page_size_params" macro that is defined and used in os.cpp.
> 
> I have replaced places that use the expanded macro(s) with EXACTFMT + EXACTFMTARGS, and also removed trace_page_size_params from os.cpp, which was essentially a redefnition of EXACTFMTARGS.
> 
> Testing: GHA, tiers 1-4

Paging @tstuefe ! Thomas added EXACTFMT in [JDK-8310233](https://github.com/openjdk/jdk/pull/14739/files#top) and did not use it for some of the places where you are now using it. Despite being a reviewer of Thomas's change, I'm not all sure when EXACTFMT should be used

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24228#issuecomment-2756673746

From dholmes at openjdk.org  Thu Mar 27 05:03:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Mar 2025 05:03:06 GMT
Subject: RFR: 8352762: Use EXACTFMT instead of expanded version where
 applicable
In-Reply-To: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
References: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
Message-ID: <HCWf2p2pmdZy01GY7F-Y6hXmXj7EqZKis-Oprtx0RYc=.92ce92e7-a3ee-4305-b9ec-56567c8a06b4@github.com>

On Tue, 25 Mar 2025 13:59:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> [JDK-8310233](https://bugs.openjdk.org/browse/JDK-8310233) introduced the EXACTFMT macro, which is a shorthand for printing exact values using methods defined in globalDefinitions.hpp. There are currently 20 places in HotSpot which uses the expanded version of the macro, along with the "trace_page_size_params" macro that is defined and used in os.cpp.
> 
> I have replaced places that use the expanded macro(s) with EXACTFMT + EXACTFMTARGS, and also removed trace_page_size_params from os.cpp, which was essentially a redefnition of EXACTFMTARGS.
> 
> Testing: GHA, tiers 1-4

This looks very consistent and reasonable to me.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24228#pullrequestreview-2719664900

From clanger at openjdk.org  Thu Mar 27 06:57:07 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 27 Mar 2025 06:57:07 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v3]
In-Reply-To: <W2jxtldlJ6r3shE-GQHUwdQNDu6dZjYoXz8kHEAL08k=.3ba90e2c-0eef-41e0-8995-97bd75ff34cc@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <W2jxtldlJ6r3shE-GQHUwdQNDu6dZjYoXz8kHEAL08k=.3ba90e2c-0eef-41e0-8995-97bd75ff34cc@github.com>
Message-ID: <Gfk88OdA5gGfrtgrJjC8_GzxP2GI1MrxnBTCiKOTSR0=.0b9f2e16-5654-4760-8924-22aa14ed2e4f@github.com>

On Wed, 26 Mar 2025 09:52:27 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
>> 
>> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
>> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
>> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
>> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
>> 
>> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
>> So my proposal is to skip this sub test for aix and musl.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

Looks good and thanks for cleaning out the test.

@AlanBateman @RogerRiggs would you mind having a look here as well?

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24055#pullrequestreview-2720002360

From clanger at openjdk.org  Thu Mar 27 07:01:10 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 27 Mar 2025 07:01:10 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v3]
In-Reply-To: <W2jxtldlJ6r3shE-GQHUwdQNDu6dZjYoXz8kHEAL08k=.3ba90e2c-0eef-41e0-8995-97bd75ff34cc@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <W2jxtldlJ6r3shE-GQHUwdQNDu6dZjYoXz8kHEAL08k=.3ba90e2c-0eef-41e0-8995-97bd75ff34cc@github.com>
Message-ID: <IRGoWR-191BPiGPtre7aEig0V0beFOWbclv4TLlaxNo=.bb03ff4c-796d-4ff8-ad0d-b75fc384ff48@github.com>

On Wed, 26 Mar 2025 09:52:27 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
>> 
>> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
>> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
>> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
>> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
>> 
>> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
>> So my proposal is to skip this sub test for aix and musl.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

test/jdk/tools/launcher/ExecutionEnvironment.java line 31:

> 29:  * @modules jdk.compiler
> 30:  *          jdk.zipfs
> 31:  * @compile -XDignore.symbol.file ExecutionEnvironment.java

One addition as for cleaning: I'm wondering whether we need this @compile directive with `-XDignore.symbol.file`. I guess this can be removed, too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24055#discussion_r2015784618

From mbaesken at openjdk.org  Thu Mar 27 08:08:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Mar 2025 08:08:06 GMT
Subject: RFR: 8352946: SEGV_BND signal code of SIGSEGV missing from our
 signal-code table
In-Reply-To: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
References: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
Message-ID: <bh8phj8XXjmz1iA8XEg-R7t6oZHj5MlCBpzeNLnoi7U=.cee13dc9-e254-4534-90d5-9eec9e879adf@github.com>

On Wed, 26 Mar 2025 14:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux we had recently a crash looking like this
> 
> 
> siginfo_t @ 0x00007fff2723dc98:
>   Signal: 11 (SIGSEGV)
>   Signal Code: 3 (unknown signal code)
>   Address of faulting memory reference: 0x007fff8c31629838
> 
> 
> Seems signal code 3 is
> `#define SEGV_BNDERR 3 /* failed address bound checks */`
> 
> so we should add this to our signal code table; on AIX I cannot find this code so it might be Linux-only.
> Even on Linux the define is not always available in the system headers so we better add a define .

Yeah true, there is potentially more 

/* `si_code' values for SIGSEGV signal.  */
enum
{
  SEGV_MAPERR = 1,              /* Address not mapped to object.  */
#  define SEGV_MAPERR   SEGV_MAPERR
  SEGV_ACCERR,                  /* Invalid permissions for mapped object.  */
#  define SEGV_ACCERR   SEGV_ACCERR
  SEGV_BNDERR,                  /* Bounds checking failure.  */
#  define SEGV_BNDERR   SEGV_BNDERR
  SEGV_PKUERR,                  /* Protection key checking failure.  */
#  define SEGV_PKUERR   SEGV_PKUERR
  SEGV_ACCADI,                  /* ADI not enabled for mapped object.  */
#  define SEGV_ACCADI   SEGV_ACCADI
  SEGV_ADIDERR,                 /* Disrupting MCD error.  */
#  define SEGV_ADIDERR  SEGV_ADIDERR
  SEGV_ADIPERR                  /* Precise MCD exception.  */
#  define SEGV_ADIPERR  SEGV_ADIPERR
};

but I only wanted to add the one we really saw recently in a crash.
I will check a few more old hserr , maybe I find more other sigcodes we do not cover currently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24255#issuecomment-2757072772

From stuefe at openjdk.org  Thu Mar 27 08:09:09 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 27 Mar 2025 08:09:09 GMT
Subject: RFR: 8352762: Use EXACTFMT instead of expanded version where
 applicable
In-Reply-To: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
References: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
Message-ID: <Q8L87KDrO1guoZLy14wCIFhW9teYJ1WUY8GzljTxFCc=.bf445859-f710-42cc-b69c-e0e9734baaee@github.com>

On Tue, 25 Mar 2025 13:59:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> [JDK-8310233](https://bugs.openjdk.org/browse/JDK-8310233) introduced the EXACTFMT macro, which is a shorthand for printing exact values using methods defined in globalDefinitions.hpp. There are currently 20 places in HotSpot which uses the expanded version of the macro, along with the "trace_page_size_params" macro that is defined and used in os.cpp.
> 
> I have replaced places that use the expanded macro(s) with EXACTFMT + EXACTFMTARGS, and also removed trace_page_size_params from os.cpp, which was essentially a redefnition of EXACTFMTARGS.
> 
> Testing: GHA, tiers 1-4

Neat, thank you. Looks good.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24228#pullrequestreview-2720217267

From mbaesken at openjdk.org  Thu Mar 27 08:35:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Mar 2025 08:35:16 GMT
Subject: RFR: 8352946: SEGV_BND signal code of SIGSEGV missing from our
 signal-code table
In-Reply-To: <bh8phj8XXjmz1iA8XEg-R7t6oZHj5MlCBpzeNLnoi7U=.cee13dc9-e254-4534-90d5-9eec9e879adf@github.com>
References: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
 <bh8phj8XXjmz1iA8XEg-R7t6oZHj5MlCBpzeNLnoi7U=.cee13dc9-e254-4534-90d5-9eec9e879adf@github.com>
Message-ID: <tV_Dhh2-Njo_ci86ZVk0jRILt9Xeq0dKfMf2kJ3wR_w=.09895b3d-de4d-4216-a8f4-a4be39d0df67@github.com>

On Thu, 27 Mar 2025 08:05:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I will check a few more old hserr , maybe I find more other sigcodes we do not cover currently.

I found a couple of Signal Code 3 cases in our old hserr, and also one strage Code 0 from macOS (not sure what that is)  


siginfo_t @ 0x000070001548f6f8:
  Signal: 11 (SIGSEGV)
  Signal Code: 0 (unknown signal code)
  Address of faulting memory reference: 0x0000000000000000

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24255#issuecomment-2757181016

From vpetko at openjdk.org  Thu Mar 27 10:34:26 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 27 Mar 2025 10:34:26 GMT
Subject: Integrated: 8352800: [PPC] OpenJDK fails to build on PPC after
 JDK-8350106
In-Reply-To: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
References: <lzEuW1-whBKkopCkhSEaz2V96ki19VWpWevxuJS5FQA=.97f2c716-66f5-4c47-89ea-a8b82fa31eb2@github.com>
Message-ID: <F9kcGQIeY4UccgQc1-KQGGOTkQYs4lPKQp8XHH85OK0=.517ee4ac-5080-4ac0-839d-51d281dc2612@github.com>

On Tue, 25 Mar 2025 08:12:37 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> Add missing header to resolve the compilation failure.
> 
> Testing:
>  - built openjdk in PPC qemu vm.

This pull request has now been integrated.

Changeset: 9a87e213
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a87e2134ef531a6906454186517d3eee2e487c2
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8352800: [PPC] OpenJDK fails to build on PPC after JDK-8350106

Reviewed-by: rrich, shade

-------------

PR: https://git.openjdk.org/jdk/pull/24216

From varadam at openjdk.org  Thu Mar 27 11:48:12 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 27 Mar 2025 11:48:12 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <E06CHVVLgEsjNqyLcIoHokyX4Q-LUts9t3kU3BqOkaM=.d2123616-dfa4-466e-93af-b14865a861a9@github.com>

On Sun, 23 Mar 2025 14:33:36 GMT, Varada M <varadam at openjdk.org> wrote:

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java

Initial failure
Execution failed: `main' threw exception: java.lang.Exception: VM did not logged expected 'executing command setflag, streaming output: 1'

AIX hasn?t adopted changes to support the new protocol version v2 https://github.com/openjdk/jdk/blob/8efd253f3d0a58233c0fde31a9514b8c911c892c/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java#L114. Additionally aix doesn?t have the changes to support streaming output. The "getversion? command supports an "options" argument which currently takes option  "streaming"which allows client to control streaming/buffered output mode.
On aix, this process uses unix sockets for communications like posix had more similar implementation. Is there anything additional changes I should take care of?


https://github.com/openjdk/jdk/pull/20782#issuecomment-2319508258
https://github.com/openjdk/jdk/pull/23405#issuecomment-2628559151

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2757747650

From jpai at openjdk.org  Thu Mar 27 13:31:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Mar 2025 13:31:23 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v3]
In-Reply-To: <W2jxtldlJ6r3shE-GQHUwdQNDu6dZjYoXz8kHEAL08k=.3ba90e2c-0eef-41e0-8995-97bd75ff34cc@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <W2jxtldlJ6r3shE-GQHUwdQNDu6dZjYoXz8kHEAL08k=.3ba90e2c-0eef-41e0-8995-97bd75ff34cc@github.com>
Message-ID: <L3-PVNKfwAssXWOKUGfpOkYLnC8STbPZV1ACxk9IY3M=.8fb75b7e-1973-4915-8852-c19b9eaf9af3@github.com>

On Wed, 26 Mar 2025 09:52:27 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
>> 
>> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
>> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
>> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
>> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
>> 
>> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
>> So my proposal is to skip this sub test for aix and musl.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

test/jdk/tools/launcher/ExecutionEnvironment.java line 28:

> 26:  * @bug 4780570 4731671 6354700 6367077 6670965 4882974
> 27:  * @summary Checks for LD_LIBRARY_PATH and execution  on *nixes
> 28:  * @requires os.family != "windows" & !vm.musl & os.family != "aix"

Hello @JoKern65, I haven't yet fully grasped the change, but I think the:

@requires os.family != "windows"

part should still be retained to prevent this test from being launched on Windows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24055#discussion_r2016586747

From clanger at openjdk.org  Thu Mar 27 13:53:15 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 27 Mar 2025 13:53:15 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v3]
In-Reply-To: <L3-PVNKfwAssXWOKUGfpOkYLnC8STbPZV1ACxk9IY3M=.8fb75b7e-1973-4915-8852-c19b9eaf9af3@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <W2jxtldlJ6r3shE-GQHUwdQNDu6dZjYoXz8kHEAL08k=.3ba90e2c-0eef-41e0-8995-97bd75ff34cc@github.com>
 <L3-PVNKfwAssXWOKUGfpOkYLnC8STbPZV1ACxk9IY3M=.8fb75b7e-1973-4915-8852-c19b9eaf9af3@github.com>
Message-ID: <qCCPRBn0v08Pha3nvX7ePnu7hrRQoaZ_3R8IuQTx7OY=.abf6c438-f22d-4f5e-82dc-4e1c38a6d1e4@github.com>

On Thu, 27 Mar 2025 13:28:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> test/jdk/tools/launcher/ExecutionEnvironment.java line 28:
> 
>> 26:  * @bug 4780570 4731671 6354700 6367077 6670965 4882974
>> 27:  * @summary Checks for LD_LIBRARY_PATH and execution  on *nixes
>> 28:  * @requires os.family != "windows" & !vm.musl & os.family != "aix"
> 
> Hello @JoKern65, I haven't yet fully grasped the change, but I think the:
> 
> @requires os.family != "windows"
> 
> part should still be retained to prevent this test from being launched on Windows.

Good catch. The test doesn't fail on Windows but it also doesn't make sense because it aims to test Unix specific things.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24055#discussion_r2016709613

From jkern at openjdk.org  Thu Mar 27 14:15:12 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 27 Mar 2025 14:15:12 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v4]
In-Reply-To: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
Message-ID: <mkMV1z7f-wZmqNw4QJBhnHPVWXHZqkQacDw_y2b04us=.2a3859c2-7603-4129-b4bd-afb09b7e0403@github.com>

> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
> 
> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
> 
> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
> So my proposal is to skip this sub test for aix and musl.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  add !windows again and remove @compile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24055/files
  - new: https://git.openjdk.org/jdk/pull/24055/files/41670da2..3f72981e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24055/head:pull/24055

PR: https://git.openjdk.org/jdk/pull/24055

From iklam at openjdk.org  Thu Mar 27 14:32:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Mar 2025 14:32:53 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state [v2]
In-Reply-To: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
Message-ID: <NQ8P7WHCn3AgNJxy8rCHrlVM6ul1Ct_dzuhFw-7AUOA=.cf22e030-8812-4f42-999f-caf50613e384@github.com>

> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
> 
> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - Move CollectClassesForLinking inside while loop to see classes loaded as side effect of linking
 - @coleenp comments - use ClassLoaderDataGraph::loaded_classes_do_keepalive()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24172/files
  - new: https://git.openjdk.org/jdk/pull/24172/files/3bb77d59..ae23a56d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24172&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24172&range=00-01

  Stats: 50 lines in 1 file changed: 17 ins; 18 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24172/head:pull/24172

PR: https://git.openjdk.org/jdk/pull/24172

From jiangli at openjdk.org  Thu Mar 27 14:42:20 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Mar 2025 14:42:20 GMT
Subject: Integrated: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK
In-Reply-To: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
Message-ID: <zlhs4GGQRyVis1kc_HLFfYl6t-O4pcGbk9gmz1D1044=.3c9c8ff6-76b2-4380-b2f3-a6b3b72bc7a4@github.com>

On Sat, 22 Mar 2025 03:46:38 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review following changes, thanks.
> 
> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
> 
> 
> $ static-jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
> 
> $ jdk/bin/java -version
> openjdk version "25-internal" 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
> 
> 
> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
> 
> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.

This pull request has now been integrated.

Changeset: 79824c34
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79824c344ee36bcf9f3434ccb3b44d2d24defc5c
Stats:     53 lines in 5 files changed: 29 ins; 8 del; 16 mod

8352184: Jtreg tests using CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils fail on static JDK

Reviewed-by: dholmes, shade

-------------

PR: https://git.openjdk.org/jdk/pull/24171

From jiangli at openjdk.org  Thu Mar 27 14:42:20 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 27 Mar 2025 14:42:20 GMT
Subject: RFR: 8352184: Jtreg tests using
 CommandLineOptionTest.getVMTypeOption() and optionsvalidation.JVMOptionsUtils
 fail on static JDK [v4]
In-Reply-To: <EI6oxbfApre5ajFHVRWwQ3ZYjQZAF7JxR7SPOPBLebc=.e1dd4b90-917a-427b-8ee5-906d7866c9e4@github.com>
References: <AnpMtabvkq9L8rhIojh_kL57wG1-JSBduKX7VniGv4c=.ae84af1d-f047-46f7-8a0f-35040eb06d0d@github.com>
 <EI6oxbfApre5ajFHVRWwQ3ZYjQZAF7JxR7SPOPBLebc=.e1dd4b90-917a-427b-8ee5-906d7866c9e4@github.com>
Message-ID: <Aqk_o7SkUm75fy0ZwnH4PIYEJO3DzW0sBPSkS5ZSyH8=.fab41cc2-acf9-4454-a148-dc89cbfdab38@github.com>

On Wed, 26 Mar 2025 19:28:24 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review following changes, thanks.
>> 
>> - Add `static` to the vm_info for static JDK. The `-version` output now contains `static` on static JDK, e.g.:
>> 
>> 
>> $ static-jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, static, sharing)
>> 
>> $ jdk/bin/java -version
>> openjdk version "25-internal" 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-internal-adhoc.jianglizhou.jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-internal-adhoc.jianglizhou.jdk, mixed mode, sharing)
>> 
>> 
>> Following changes resolve jtreg test failures on static JDK due to '-server|-client|-minimal|-zero' flag added by `CommandLineOptionTest.getVMTypeOption()` or `optionsvalidation.JVMOptionsUtils`. '-server|-client|-minimal|-zero' flags are unrecognized on static JDK (please see https://bugs.openjdk.org/browse/JDK-8350982).
>> 
>> - Add `jdk.test.lib.Platform.isStatic()`, which checks for `static` in `java.vm.info` system property to determine if current test is running on static JDK. 
>> - Change `CommandLineOptionTest` to only call `getVMTypeOption()` on regular JDK (`!Platform.isStatic()`).
>> - Change `optionsvalidation.JVMOptionsUtils` to only set VMType to '-server|-client|-minimal' on regular JDK ( `!Platform.isStatic()`.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @shipilev comments:
>   - In JVMOptionsUtils.<clinit>, make `if (Platform.isStatic())` block as a preceding block of other checks.
>   - In Abstract_VM_Version::vm_info_string(), break lines.

Thank you, both!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24171#issuecomment-2758314709

From mdoerr at openjdk.org  Thu Mar 27 14:47:08 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 27 Mar 2025 14:47:08 GMT
Subject: RFR: 8352946: SEGV_BND signal code of SIGSEGV missing from our
 signal-code table
In-Reply-To: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
References: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
Message-ID: <oM1llA-Nt3Q6GUdyMdaBoqhZxya0Bm7n0tEl2084mt8=.b3d45145-7f55-466f-9288-f76fa7e071e6@github.com>

On Wed, 26 Mar 2025 14:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux we had recently a crash looking like this
> 
> 
> siginfo_t @ 0x00007fff2723dc98:
>   Signal: 11 (SIGSEGV)
>   Signal Code: 3 (unknown signal code)
>   Address of faulting memory reference: 0x007fff8c31629838
> 
> 
> Seems signal code 3 is
> `#define SEGV_BNDERR 3 /* failed address bound checks */`
> 
> so we should add this to our signal code table; on AIX I cannot find this code so it might be Linux-only.
> Even on Linux the define is not always available in the system headers so we better add a define .

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24255#pullrequestreview-2722013860

From duke at openjdk.org  Thu Mar 27 15:25:43 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Thu, 27 Mar 2025 15:25:43 GMT
Subject: RFR: 8352114: New test runtime/interpreter/CountBytecodesTest.java is
 failing
Message-ID: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>

8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

-------------

Commit messages:
 - 8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

Changes: https://git.openjdk.org/jdk/pull/24281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24281&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352114
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24281/head:pull/24281

PR: https://git.openjdk.org/jdk/pull/24281

From duke at openjdk.org  Thu Mar 27 15:25:43 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Thu, 27 Mar 2025 15:25:43 GMT
Subject: RFR: 8352114: New test runtime/interpreter/CountBytecodesTest.java
 is failing
In-Reply-To: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
References: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
Message-ID: <3t5JSpvwjc66RwECpBVIcqk2otCJQg3bjKIVGh9jcxU=.ddc4d95c-cf19-460d-b4ab-d8412bdf889d@github.com>

On Thu, 27 Mar 2025 15:19:43 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> 8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

Hi @dholmes-ora ,
could you please verify that this fixes the issue? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24281#issuecomment-2758451077

From ccheung at openjdk.org  Thu Mar 27 15:37:19 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 27 Mar 2025 15:37:19 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log [v2]
In-Reply-To: <slgHbTn0nPUCPOVdOJJ_1CcKE9W6ytsAd6mhzSUzeLg=.0a6d7444-33b8-4a10-9838-db78745818b6@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
 <Xhz0Eg9ksPSNq3jWNFVuMD9hkPIHwENz-kvO-HwCBOk=.cf603204-a94b-4db9-94e2-88f46e91d40e@github.com>
 <slgHbTn0nPUCPOVdOJJ_1CcKE9W6ytsAd6mhzSUzeLg=.0a6d7444-33b8-4a10-9838-db78745818b6@github.com>
Message-ID: <Bc1Njhz-VhuoNHLr-vz-unp_4RuxpwFnE7snqAWtoao=.b0ede3bb-946f-4f1b-b5a8-16a3f9b48386@github.com>

On Wed, 26 Mar 2025 19:57:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @shipilev comment
>
> Still good!

Thanks @shipilev and @iklam for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23878#issuecomment-2758495192

From ccheung at openjdk.org  Thu Mar 27 15:37:19 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 27 Mar 2025 15:37:19 GMT
Subject: Integrated: 8325132: CDS: Make sure the ArchiveRelocationMode is
 always printed in the log
In-Reply-To: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
Message-ID: <5YiUkNF6iHGJDMKe46OP-plWrUKY_T0KINZyTHlc1mg=.9d150345-941a-4584-8306-46c480ee1114@github.com>

On Tue, 4 Mar 2025 00:44:55 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Always include the ArchiveRelocationMode in the CDS info log. Before this fix, ArchiveRelocationMode is not in the log if it is set to 0.
> The ArchiveRelocationMode default value was set to 1 about 2 years ago. Some tests need to be updated accordingly.
> 
> Testing:
> 
> - ran the modified tests manually on linux-x64
> - tier1

This pull request has now been integrated.

Changeset: 2eeda646
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2eeda64632621c31c6b0a9257ddec7ce9bc5eaec
Stats:     18 lines in 4 files changed: 10 ins; 0 del; 8 mod

8325132: CDS: Make sure the ArchiveRelocationMode is always printed in the log

Reviewed-by: shade, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/23878

From jsikstro at openjdk.org  Thu Mar 27 15:52:19 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 27 Mar 2025 15:52:19 GMT
Subject: RFR: 8352762: Use EXACTFMT instead of expanded version where
 applicable
In-Reply-To: <DoMcNyYeq2mcsw4vSVzJRVHVQc1eq_rwqLSk4k_PP08=.06d33245-bd7a-4db7-bd46-cc863888b63c@github.com>
References: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
 <DoMcNyYeq2mcsw4vSVzJRVHVQc1eq_rwqLSk4k_PP08=.06d33245-bd7a-4db7-bd46-cc863888b63c@github.com>
Message-ID: <NQG3ievKXsfWzTKdeYSpOON8QxGcJWDqIr8W3eA5enU=.390f5ab5-a23a-4731-8185-845a30ce4e00@github.com>

On Thu, 27 Mar 2025 04:52:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> [JDK-8310233](https://bugs.openjdk.org/browse/JDK-8310233) introduced the EXACTFMT macro, which is a shorthand for printing exact values using methods defined in globalDefinitions.hpp. There are currently 20 places in HotSpot which uses the expanded version of the macro, along with the "trace_page_size_params" macro that is defined and used in os.cpp.
>> 
>> I have replaced places that use the expanded macro(s) with EXACTFMT + EXACTFMTARGS, and also removed trace_page_size_params from os.cpp, which was essentially a redefnition of EXACTFMTARGS.
>> 
>> Testing: GHA, tiers 1-4
>
> Paging @tstuefe ! Thomas added EXACTFMT in [JDK-8310233](https://github.com/openjdk/jdk/pull/14739/files#top) and did not use it for some of the places where you are now using it. Despite being a reviewer of Thomas's change, I'm not at all sure when EXACTFMT should be used. But this looks good.

Thank you for the reviews! @dholmes-ora @tstuefe

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24228#issuecomment-2758536909

From jsikstro at openjdk.org  Thu Mar 27 15:52:19 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 27 Mar 2025 15:52:19 GMT
Subject: Integrated: 8352762: Use EXACTFMT instead of expanded version where
 applicable
In-Reply-To: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
References: <zPUowWtWvnLX9O_KK6BgDtHnfbrULUGgt3Pvsl3tQho=.25cd8492-bcb8-4c36-b841-06c02f84dda2@github.com>
Message-ID: <b-WT348vm4fD7lP9LegDUnhztF-Ixqf1zLbRnbIzE0k=.81683722-34e4-41a4-a1d2-f56cdc0d7b7a@github.com>

On Tue, 25 Mar 2025 13:59:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> [JDK-8310233](https://bugs.openjdk.org/browse/JDK-8310233) introduced the EXACTFMT macro, which is a shorthand for printing exact values using methods defined in globalDefinitions.hpp. There are currently 20 places in HotSpot which uses the expanded version of the macro, along with the "trace_page_size_params" macro that is defined and used in os.cpp.
> 
> I have replaced places that use the expanded macro(s) with EXACTFMT + EXACTFMTARGS, and also removed trace_page_size_params from os.cpp, which was essentially a redefnition of EXACTFMTARGS.
> 
> Testing: GHA, tiers 1-4

This pull request has now been integrated.

Changeset: dc5c4148
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc5c4148c70ca43d0a69c326e14898adca2f0bae
Stats:     70 lines in 8 files changed: 0 ins; 20 del; 50 mod

8352762: Use EXACTFMT instead of expanded version where applicable

Reviewed-by: dholmes, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/24228

From kvn at openjdk.org  Thu Mar 27 16:07:14 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 27 Mar 2025 16:07:14 GMT
Subject: RFR: 8353014: Exclude AOT tooling classes from AOT cache
In-Reply-To: <iR733lyiN_8Hq3VI8XytMA7L6c-dWIN6K4ZIMkDMjWk=.41b641f7-3a68-4dd5-ad2f-66f88e3bdab1@github.com>
References: <iR733lyiN_8Hq3VI8XytMA7L6c-dWIN6K4ZIMkDMjWk=.41b641f7-3a68-4dd5-ad2f-66f88e3bdab1@github.com>
Message-ID: <ZTPBvsl57RjMyauW--XJMD6prwOFhjup8106UNJYuJU=.8374ffdc-4f0a-4475-80b1-71e8f3d6c7ab@github.com>

On Thu, 27 Mar 2025 03:47:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When creating the AOT configuration file or the AOT cache file, we load a few "AOT tooling" classes that are not needed in the production run. This PR adds an API for filtering out such classes to reduce footprint.
> 
> In addition, with the upcoming [JDK-8325147](https://bugs.openjdk.org/browse/JDK-8325147) (Ahead-of-Time Method Profiling), profiles for the tooling classes will be also be excluded. This will prevent the JVM from compiling methods at start-up which aren't going to be used.

Seems fine.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24272#pullrequestreview-2722340199

From varadam at openjdk.org  Thu Mar 27 16:54:36 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 27 Mar 2025 16:54:36 GMT
Subject: Withdrawn: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <SO_5Nst90zGUjDQDO0tntpQHz0JCrM6mZ3HSRogYaIc=.ad4f255a-7524-4c3c-80cb-cc58b2885b31@github.com>

On Sun, 23 Mar 2025 14:33:36 GMT, Varada M <varadam at openjdk.org> wrote:

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24177

From iklam at openjdk.org  Thu Mar 27 20:31:34 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Mar 2025 20:31:34 GMT
Subject: Integrated: 8352435: Refactor CDS test library for execution and
 module packaging
In-Reply-To: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
Message-ID: <37r1Kt_b1TDfrQZJgP2UtPoLduwKYQKeuNnPrygNbY0=.5d3f5e14-45e4-4167-94f1-fa684ba586e8@github.com>

On Wed, 19 Mar 2025 21:56:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In CDS/AOT testing, we have a lot of code that deal with compiling/packaging modules, as well as running various child processes for the training/assembly/production phases.
> 
> Currently, these operations are done in many low-level steps, so it's difficult to understand and maintain:
> 
> https://github.com/openjdk/jdk/blob/fcc2a24291d499f7149debad1250903ddc369d91/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
> 
> This PR adds a few new classes to simplify the test cases:
> 
> Example: build two modular JAR files into `modulePath`
> 
> 
> CDSModulePackager modulePackager = new CDSModulePackager(SRC);
> modulePath = modulePackager.getOutputDir().toString();
> 
> modulePackager.createModularJar("com.foos");
> modulePackager.createModularJar("com.needsfoosaddexport",
>                                 "--add-exports",
>                                 "com.foos/com.foos.internal=com.needsfoosaddexport");
> 
> 
> Example: use modules in training/assembly/production phases
> 
> 
> SimpleCDSAppTester.of("moduleNeedsJdkAddExport")
>    .classpath(dummyJar)
>    .modulepath(modulePath)
>    .addVmArgs("--add-modules", "com.needsjdkaddexport",
>               "--add-exports", "java.base/jdk.internal.misc=com.needsjdkaddexport", "-Xlog:cds")
>    .appCommandLine("-m", "com.needsjdkaddexport/com.needsjdkaddexport.Main")
>    .setAssemblyChecker((OutputAnalyzer out) -> {
>            out.shouldContain("Full module graph = enabled");
>         })
>     .setProductionChecker((OutputAnalyzer out) -> {
>             out.shouldContain("use_full_module_graph = true; java.base");
>         })
>     .runStaticWorkflow()
>     .runAOTWorkflow();

This pull request has now been integrated.

Changeset: 4ce9b4c7
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ce9b4c72ef00d81fc07527a89d20cfa5400d673
Stats:     1144 lines in 7 files changed: 735 ins; 339 del; 70 mod

8352435: Refactor CDS test library for execution and module packaging

Reviewed-by: ccheung, shade

-------------

PR: https://git.openjdk.org/jdk/pull/24122

From iklam at openjdk.org  Thu Mar 27 20:31:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 27 Mar 2025 20:31:32 GMT
Subject: RFR: 8352435: Refactor CDS test library for execution and module
 packaging [v2]
In-Reply-To: <QDzCp9sYJcsIy69MreT16zRLkLGACWWLiJGJU-2pIUM=.9da43d3f-98c0-4f05-b26c-b65d7e766c57@github.com>
References: <fLomuxlFSzkvGj_wxLzA1q925iHCYSb1zoYCv56Kg1E=.0ad22726-1686-4da5-8f3e-819db2f5ce16@github.com>
 <gC2sHYWT3OwonissrywET7hat7IvvrrDSxQZbNcO2KU=.529bf399-5ad7-461a-aafd-f5375397d7d4@github.com>
 <QDzCp9sYJcsIy69MreT16zRLkLGACWWLiJGJU-2pIUM=.9da43d3f-98c0-4f05-b26c-b65d7e766c57@github.com>
Message-ID: <26pmhn5CvW0uG3zxCmpS0FcB3v1QOoF8ZIn-qf38yQ8=.fa4c8af5-e805-4775-8262-25fd31c19ff0@github.com>

On Tue, 25 Mar 2025 18:51:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added comments
>
> Looks good to me, although this is the first time I look into this code :)

Thanks @shipilev and @calvinccheung for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24122#issuecomment-2759399688

From coleenp at openjdk.org  Thu Mar 27 20:59:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Mar 2025 20:59:28 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable [v3]
In-Reply-To: <y-y8xOaFmHnNbITpoqhM8yPRcM5GaNN0TsathNvAO-U=.5ca2af8c-c960-4cc9-9d39-e85f09b7da35@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <y-y8xOaFmHnNbITpoqhM8yPRcM5GaNN0TsathNvAO-U=.5ca2af8c-c960-4cc9-9d39-e85f09b7da35@github.com>
Message-ID: <ub4yWNkcGVY-mNSGSQLC7S--xDIzuuqZZoseoy2Om1I=.e50a6520-29e8-4546-838e-a891856e4d97@github.com>

On Wed, 26 Mar 2025 07:54:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
>> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
>> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
>> - Some small code shufflings.
>> 
>> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
>> without-OMT: 773.3 ms
>> with-OMT: 797.28 ms
>> 
>> That is still a regression of ~3%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include objectMonitor.inline.hpp

This change looks really good.  I'll ping @xmas92 to review it tomorrow if he doesn't notice this mention.  Thanks.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24098#pullrequestreview-2723364339

From coleenp at openjdk.org  Thu Mar 27 20:59:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Mar 2025 20:59:29 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable [v3]
In-Reply-To: <S5_o1xVLEBvewGcmlnHEd2Jf85SAFDH0-7a8y69g4wU=.eb2b7ea1-62e6-42cc-a839-6c3eecdcfc94@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <KjsQAmJcI5GvU2oRkvyGJx_a-RRmN3n3nf77szTtjaI=.6e092298-c5b2-4b10-9e4c-b05ef840bc6e@github.com>
 <HZ2DrySldFuiBRb88TYV23NSa5NlCzN1qpYog2CdFP4=.f6d9e803-ab98-4073-a6f8-d15def7e8452@github.com>
 <bYOO0TbWMbxz5uswJuf2ou5EPIvmZ3cX8d1uuRQ4yi0=.bee7fc37-92f3-438d-9cf0-e328235c89be@github.com>
 <HE0ufRqFtSHREnSydlbsJiEMp4GteCYlef1X8FhId84=.2eb23060-825f-47ca-8fd0-7f0d9248c513@github.com>
 <PltYmB_nicNxvm_HxKaOV0LtVWLdNSVtapG2g2S_wEo=.2acc1d42-1164-4588-9f78-e49261907fbf@github.com>
 <S5_o1xVLEBvewGcmlnHEd2Jf85SAFDH0-7a8y69g4wU=.eb2b7ea1-62e6-42cc-a839-6c3eecdcfc94@github.com>
Message-ID: <czHVtRskZ6foait9MAmKpOVF6111CV1Ed2CV-NPBG6c=.7c229a8b-b862-4d1c-9092-eb33446a34b5@github.com>

On Wed, 26 Mar 2025 07:26:19 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Looks like from GHA, this also fails the same test.  I think you should remove this optimization since I don't think it helps any.
>
> 'it does not help any' is not correct. The point of this PR is to put the OM in the BasicLock cache early, even if it does not succeed to enter, so that slower paths can pick it up from there. Also, simply removing this particular line would not change anything, because we put the OM in the BasicLock cache in the C2 fast-path in the same way.
> 
> I think the BasicLock OM cache should be treated the same way as the thread's OMCache. The BasicLock cache is basically the L1 cache, while the OMCache is the L2 cache. And just like the OMCache lookup, we should clear the BasicLock cache when we observe a deflating monitor. This fixes the failing test.
> @xmas92 should also look at this.

Yes, the concept of a L1 and L2 cache is good and clear.  And does help performance of look ups in the OMCache.  I reconstructed the crash I got with the runtime/Monitor/UseObjectMonitorTableTest.java#ExtremeDeflation test.  I was setting the OMCache also with the monitor found, because I was only trying to avoid redoing the lookup in the table itself, but in this test, we find a deflated monitor in the OMCache, and then got the assert that it's not in the table.

I don't know if you want to recheck if the monitor is deflated at this time, even though it might be racy.  It's unlikely and the check and clearing in BasicLock is better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24098#discussion_r2017589913

From amenkov at openjdk.org  Thu Mar 27 21:04:10 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 27 Mar 2025 21:04:10 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <1oBEVCWBXmozuxIEAIZUhxQHKc-C7LQ9unqKcrOUkB8=.53f87b6f-8ef5-45e1-99ac-55e1a67c79ba@github.com>

On Sun, 23 Mar 2025 14:33:36 GMT, Varada M <varadam at openjdk.org> wrote:

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

The change looks good.
Couple notes:
- need to update copyright year in VirtualMachineImpl.java
- need to remove StreamingOutputTest.java from problem list (revert JDK-8352393)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2759465481

From gziemski at openjdk.org  Thu Mar 27 21:39:58 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 27 Mar 2025 21:39:58 GMT
Subject: RFR: 8341095: Possible overflow in os::Posix::print_uptime_info
 [v2]
In-Reply-To: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>
References: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>
Message-ID: <qKO7dUDX0rb1C5x_TqnFqFfkng-sMdiKognExJK3oG0=.34c97745-b21c-49e3-93cb-96d4dac4bb34@github.com>

> This is a trivial change that will quiet Xcode only visual warning in os_posix.cpp file.
> 
> There are 31,536,000 seconds in a year, so if int is 32bits, then we have MAX int value of 2,147,483,647 so it would overflow in 68 years - unlikely to affect anyone.

Gerard Ziemski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8341095
 - remove test stufff
 - remove test stufff
 - remove test stufff
 - test
 - test
 - test
 - test
 - test
 - test
 - ... and 6 more: https://git.openjdk.org/jdk/compare/f6a4cebd...0ca5615f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24140/files
  - new: https://git.openjdk.org/jdk/pull/24140/files/88d0f7a4..0ca5615f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24140&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24140&range=00-01

  Stats: 4508 lines in 99 files changed: 1917 ins; 2030 del; 561 mod
  Patch: https://git.openjdk.org/jdk/pull/24140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24140/head:pull/24140

PR: https://git.openjdk.org/jdk/pull/24140

From liach at openjdk.org  Thu Mar 27 22:40:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Mar 2025 22:40:14 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <v596TlVCfNtjrGUEXtFItD4xTol9OIECCs2ABgsKUAw=.2ac68717-ed86-4700-afdd-b66e8c46fae1@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
 <v596TlVCfNtjrGUEXtFItD4xTol9OIECCs2ABgsKUAw=.2ac68717-ed86-4700-afdd-b66e8c46fae1@github.com>
Message-ID: <gZdZbwSapPnXCLQhQeMbGAE4H62XdxyDRTTho5VPzO4=.04a123ee-d750-4da2-b423-7b37a9dabd42@github.com>

On Fri, 21 Feb 2025 07:10:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>>    
>>    The UnsafeOps JMH benchmark fails with the following error:
>>    
>>          ```
>>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>>          ```
>>    
>>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>>    
>>    Note that even it will raise "proprietary API" warnings after this
>>    patch, it is acceptable because the relevant APIs are bound for removal
>>    for the integrity of the platform.
>>    
>>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>>    
>>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.
>
> Thanks for restoring, this micro was specifically for sun.misc.Unsafe. I'm not wondering about the FFM micros that were also changed by JDK-8332744. Might not matter there but I think the original motive was to compare against sun.misc.Unsafe usage.

@AlanBateman Can you review this if this patch looks good in principle? Or should this bench be nuked like the virtual thread continuation one?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2759689700

From gziemski at openjdk.org  Thu Mar 27 23:06:43 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 27 Mar 2025 23:06:43 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code,
 so that we only have 1 code path
Message-ID: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>

This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):

proposed:

time:72,642,827[ns]
[samples:807,804] [NMT headers:382,064]
[malloc#:588,703] [realloc#:12,462] [free#:206,639]
memory requested:57,274,288 bytes, allocated:69,004,800 bytes
malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
existing code:

time:73,085,446[ns]
[samples:807,804] [NMT headers:382,064]
[malloc#:588,703] [realloc#:12,462] [free#:206,639]
memory requested:57,274,288 bytes, allocated:69,004,800 bytes
malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.

The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).

This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).

To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

-------------

Commit messages:
 - work
 - work
 - work
 - work
 - work:
 - work
 - work
 - work
 - work
 - work
 - ... and 4 more: https://git.openjdk.org/jdk/compare/a8757332...abfb5f2c

Changes: https://git.openjdk.org/jdk/pull/24189/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301404
  Stats: 115 lines in 3 files changed: 52 ins; 46 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/24189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24189/head:pull/24189

PR: https://git.openjdk.org/jdk/pull/24189

From cslucas at openjdk.org  Fri Mar 28 01:12:57 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 28 Mar 2025 01:12:57 GMT
Subject: RFR: 8352920: Compilation failure: comparison of unsigned expression
 >= 0 is always true
Message-ID: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>

Please review this patch to fix the compilation failure. The fix is simply to only define the `BytecodeTransfer::trace_interpreter` method  in NOT_PRODUCT builds.

Tested on OSX/Linux aarch64/x86_64 with JTREG.

-------------

Commit messages:
 - Trace_interpreter only in NOT_PRODUCT

Changes: https://git.openjdk.org/jdk/pull/24284/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24284&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352920
  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24284.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24284/head:pull/24284

PR: https://git.openjdk.org/jdk/pull/24284

From dholmes at openjdk.org  Fri Mar 28 02:36:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Mar 2025 02:36:08 GMT
Subject: RFR: 8352920: Compilation failure: comparison of unsigned
 expression >= 0 is always true
In-Reply-To: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
References: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
Message-ID: <v57UXfXxi1CjV8sZ6BkNA5nW99UeUOybQARVha6uDLw=.c5b23c08-d52b-4517-a3ab-4e102b3d44fb@github.com>

On Fri, 28 Mar 2025 01:06:53 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this patch to fix the compilation failure. The fix is simply to only define the `BytecodeTransfer::trace_interpreter` method  in NOT_PRODUCT builds.
> 
> Tested on OSX/Linux aarch64/x86_64 with JTREG.

Sorry ignore previous brain malfunction in the mailing lists

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24284#issuecomment-2760018357

From dholmes at openjdk.org  Fri Mar 28 02:40:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Mar 2025 02:40:18 GMT
Subject: RFR: 8352920: Compilation failure: comparison of unsigned
 expression >= 0 is always true
In-Reply-To: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
References: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
Message-ID: <l1pAO0gxvDPwxoRJ7XXbUeQTdT1Frzw2BIxOykevAhI=.fbb66b63-48a9-40ea-8bb1-c742dd196c24@github.com>

On Fri, 28 Mar 2025 01:06:53 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this patch to fix the compilation failure. The fix is simply to only define the `BytecodeTransfer::trace_interpreter` method  in NOT_PRODUCT builds.
> 
> Tested on OSX/Linux aarch64/x86_64 with JTREG.

Looks good.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24284#pullrequestreview-2724104528

From dholmes at openjdk.org  Fri Mar 28 02:42:24 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Mar 2025 02:42:24 GMT
Subject: RFR: 8352946: SEGV_BND signal code of SIGSEGV missing from our
 signal-code table
In-Reply-To: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
References: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
Message-ID: <yQ68TW6JAXkh7lr_cCyGwrnhDVc8N2kw8Hsu0LZsHGg=.507185e1-61b8-4f95-bd29-98410eaf541b@github.com>

On Wed, 26 Mar 2025 14:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux we had recently a crash looking like this
> 
> 
> siginfo_t @ 0x00007fff2723dc98:
>   Signal: 11 (SIGSEGV)
>   Signal Code: 3 (unknown signal code)
>   Address of faulting memory reference: 0x007fff8c31629838
> 
> 
> Seems signal code 3 is
> `#define SEGV_BNDERR 3 /* failed address bound checks */`
> 
> so we should add this to our signal code table; on AIX I cannot find this code so it might be Linux-only.
> Even on Linux the define is not always available in the system headers so we better add a define .

Okay - seems harmless.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24255#pullrequestreview-2724106248

From dholmes at openjdk.org  Fri Mar 28 03:02:26 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Mar 2025 03:02:26 GMT
Subject: RFR: 8325132: CDS: Make sure the ArchiveRelocationMode is always
 printed in the log [v2]
In-Reply-To: <Xhz0Eg9ksPSNq3jWNFVuMD9hkPIHwENz-kvO-HwCBOk=.cf603204-a94b-4db9-94e2-88f46e91d40e@github.com>
References: <Kkos_-Z4MjnbMxbCwll2j6OXOw0ta62THINtiHOMH3E=.c519df21-ef21-4216-8c74-afc0b0ad7d72@github.com>
 <Xhz0Eg9ksPSNq3jWNFVuMD9hkPIHwENz-kvO-HwCBOk=.cf603204-a94b-4db9-94e2-88f46e91d40e@github.com>
Message-ID: <EKFlZ0APzdvgvBiYdfVXwFW3qrq-EhgC7JTDM4QYps4=.15bd482d-1f24-4eda-949d-c223604c6be8@github.com>

On Wed, 26 Mar 2025 19:46:02 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Always include the ArchiveRelocationMode in the CDS info log. Before this fix, ArchiveRelocationMode is not in the log if it is set to 0.
>> The ArchiveRelocationMode default value was set to 1 about 2 years ago. Some tests need to be updated accordingly.
>> 
>> Testing:
>> 
>> - ran the modified tests manually on linux-x64
>> - tier1
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @shipilev comment

FYI updated tests are failing in tier4. Filed JDK-8353129

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23878#issuecomment-2760053177

From duke at openjdk.org  Fri Mar 28 03:45:09 2025
From: duke at openjdk.org (duke)
Date: Fri, 28 Mar 2025 03:45:09 GMT
Subject: RFR: 8352920: Compilation failure: comparison of unsigned
 expression >= 0 is always true
In-Reply-To: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
References: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
Message-ID: <2fBm_8tb6WqvDGwx15Ak6yp4MmHPmcGEuo60sJR5DFQ=.76f82288-12ae-4b57-84ee-228ae75227c6@github.com>

On Fri, 28 Mar 2025 01:06:53 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this patch to fix the compilation failure. The fix is simply to only define the `BytecodeTransfer::trace_interpreter` method  in NOT_PRODUCT builds.
> 
> Tested on OSX/Linux aarch64/x86_64 with JTREG.

@JohnTortugo 
Your change (at version 7f2c0616fd72eabcd22b8d643b5507bc5d8b79e2) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24284#issuecomment-2760102699

From dholmes at openjdk.org  Fri Mar 28 04:53:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Mar 2025 04:53:20 GMT
Subject: RFR: 8352920: Compilation failure: comparison of unsigned
 expression >= 0 is always true
In-Reply-To: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
References: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
Message-ID: <HeJAkbQcmfxT401xMA1k4qtp6C6M3B79GW4RwnwP6Xs=.9f281c79-5f1c-4f37-86f6-1880643d38f3@github.com>

On Fri, 28 Mar 2025 01:06:53 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this patch to fix the compilation failure. The fix is simply to only define the `BytecodeTransfer::trace_interpreter` method  in NOT_PRODUCT builds.
> 
> Tested on OSX/Linux aarch64/x86_64 with JTREG.

I think this counts as a trivial change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24284#issuecomment-2760175768

From cslucas at openjdk.org  Fri Mar 28 04:53:21 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 28 Mar 2025 04:53:21 GMT
Subject: Integrated: 8352920: Compilation failure: comparison of unsigned
 expression >= 0 is always true
In-Reply-To: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
References: <vzbf3-IaGUAuylVsOYyhfb6Xf9QjD-yiW5PIBR7yqnQ=.d738931c-75fe-4e42-b900-1e40578ee770@github.com>
Message-ID: <L9jCrLysnCRNxLocLpHDZpGTtM50LGZMKkbP19aClwU=.1343d2c1-cb57-4000-a163-9dd9c86f018b@github.com>

On Fri, 28 Mar 2025 01:06:53 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this patch to fix the compilation failure. The fix is simply to only define the `BytecodeTransfer::trace_interpreter` method  in NOT_PRODUCT builds.
> 
> Tested on OSX/Linux aarch64/x86_64 with JTREG.

This pull request has now been integrated.

Changeset: f4428e89
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4428e89b7d9f00833a437f08fe0c0bbcec87a11
Stats:     3 lines in 2 files changed: 2 ins; 0 del; 1 mod

8352920: Compilation failure: comparison of unsigned expression >= 0 is always true

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/24284

From mbaesken at openjdk.org  Fri Mar 28 08:16:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Mar 2025 08:16:12 GMT
Subject: RFR: 8352946: SEGV_BND signal code of SIGSEGV missing from our
 signal-code table
In-Reply-To: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
References: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
Message-ID: <MrrIOdOYGtx8y-WVqp4FgFgorwdgQyJR4WmxhfFLoVQ=.c4f2788c-7d6b-4b4f-b833-607f76f58796@github.com>

On Wed, 26 Mar 2025 14:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux we had recently a crash looking like this
> 
> 
> siginfo_t @ 0x00007fff2723dc98:
>   Signal: 11 (SIGSEGV)
>   Signal Code: 3 (unknown signal code)
>   Address of faulting memory reference: 0x007fff8c31629838
> 
> 
> Seems signal code 3 is
> `#define SEGV_BNDERR 3 /* failed address bound checks */`
> 
> so we should add this to our signal code table; on AIX I cannot find this code so it might be Linux-only.
> Even on Linux the define is not always available in the system headers so we better add a define .

David and Martin, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24255#issuecomment-2760509748

From mbaesken at openjdk.org  Fri Mar 28 08:16:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Mar 2025 08:16:12 GMT
Subject: Integrated: 8352946: SEGV_BND signal code of SIGSEGV missing from our
 signal-code table
In-Reply-To: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
References: <VMpg9wZRx-VWM7HDdjFIvOvDX69LULqpBKC1jEDoabU=.f2ddbfc7-d4d2-4324-a290-a24d7976df41@github.com>
Message-ID: <AOPU203sfmkGC4k9fETGSC_awedyBFEPg7qHW5azJ7o=.ce35f3e6-801b-4432-b660-3b4b266ac6ff@github.com>

On Wed, 26 Mar 2025 14:24:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux we had recently a crash looking like this
> 
> 
> siginfo_t @ 0x00007fff2723dc98:
>   Signal: 11 (SIGSEGV)
>   Signal Code: 3 (unknown signal code)
>   Address of faulting memory reference: 0x007fff8c31629838
> 
> 
> Seems signal code 3 is
> `#define SEGV_BNDERR 3 /* failed address bound checks */`
> 
> so we should add this to our signal code table; on AIX I cannot find this code so it might be Linux-only.
> Even on Linux the define is not always available in the system headers so we better add a define .

This pull request has now been integrated.

Changeset: bac2aa44
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bac2aa44454982684e06854add1dbbb806fba363
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8352946: SEGV_BND signal code of SIGSEGV missing from our signal-code table

Reviewed-by: mdoerr, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/24255

From varadam at openjdk.org  Fri Mar 28 08:48:27 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 28 Mar 2025 08:48:27 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
 [v2]
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <L7Q0uo9u_dIiITmbEKyKGVdRh7xfN94LqdJ8bRgIYXM=.5654dd84-a53e-45d4-ae5a-956afd020d33@github.com>

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

Varada M 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 'openjdk:master' into test-fix
 - AIX: implement attach API v2 and streaming output
 - AIX: implement attach API v2 and streaming output
 - AIX: implement attach API v2 and streaming output
 - AIX: Problem list serviceability/attach/AttachAPIv2/StreamingOutputTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24177/files
  - new: https://git.openjdk.org/jdk/pull/24177/files/8efd253f..ab6941f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=00-01

  Stats: 59685 lines in 1814 files changed: 15314 ins; 37325 del; 7046 mod
  Patch: https://git.openjdk.org/jdk/pull/24177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24177/head:pull/24177

PR: https://git.openjdk.org/jdk/pull/24177

From varadam at openjdk.org  Fri Mar 28 09:01:26 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 28 Mar 2025 09:01:26 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
 [v3]
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

Varada M has updated the pull request incrementally with two additional commits since the last revision:

 - updated copyright header
 - removed StreamingOutputTest.java from problem list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24177/files
  - new: https://git.openjdk.org/jdk/pull/24177/files/ab6941f2..d22f0ab9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24177/head:pull/24177

PR: https://git.openjdk.org/jdk/pull/24177

From varadam at openjdk.org  Fri Mar 28 09:01:26 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 28 Mar 2025 09:01:26 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <1oBEVCWBXmozuxIEAIZUhxQHKc-C7LQ9unqKcrOUkB8=.53f87b6f-8ef5-45e1-99ac-55e1a67c79ba@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
 <1oBEVCWBXmozuxIEAIZUhxQHKc-C7LQ9unqKcrOUkB8=.53f87b6f-8ef5-45e1-99ac-55e1a67c79ba@github.com>
Message-ID: <DPmPD-tg8BQ_KwTlvkg3mfJDviY47-CQVwfqWdfzCFI=.ff30ceb5-bd8d-48e3-b202-e511e9aba3c0@github.com>

On Thu, 27 Mar 2025 21:01:29 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
>> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
>> 
>> tier1, tier2 and tier3 testing is successful with fastdebug level
>> 
>> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)
>
> The change looks good.
> Couple notes:
> - need to update copyright year in VirtualMachineImpl.java
> - need to remove StreamingOutputTest.java from problem list (revert JDK-8352393)

Thank you @alexmenkov, I have updated copyright year and reverted the changes from JDK-8352393.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2760600605

From aboldtch at openjdk.org  Fri Mar 28 09:20:38 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 28 Mar 2025 09:20:38 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable [v3]
In-Reply-To: <y-y8xOaFmHnNbITpoqhM8yPRcM5GaNN0TsathNvAO-U=.5ca2af8c-c960-4cc9-9d39-e85f09b7da35@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <y-y8xOaFmHnNbITpoqhM8yPRcM5GaNN0TsathNvAO-U=.5ca2af8c-c960-4cc9-9d39-e85f09b7da35@github.com>
Message-ID: <JFTdtfWPDEgvlUuimDo9WCC53dbLfMhZgvHot2HrAL8=.8b97c302-3a98-46d9-beb5-acf7b6c8b4e2@github.com>

On Wed, 26 Mar 2025 07:54:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
>> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
>> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
>> - Some small code shufflings.
>> 
>> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
>> without-OMT: 773.3 ms
>> with-OMT: 797.28 ms
>> 
>> That is still a regression of ~3%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include objectMonitor.inline.hpp

The exit and hashcode changes seem good, I see no issue there.

The enter changes require more thought and testing I think.

# First the caches:

There are two fundamental differences between the two caches. 

First the thread stack cache (BasicLock) is assumed to be guarded from use after free by only containing a monitor if it is locked by the thread. So deflation cannot occur. There is a small window where it exists because C2, due to register pressure, saves a potential value to the stack. Currently we never read this value in the slow path, and the CacheSetter overwrites it with the monitor we actually lock on or nullptr in the case of fast locking.

Second exit assumes that whatever is in the cache is what is locked on. So if we do not do inflated locking in enter for whatever reason, it must be cleared. 

We must also verify that all paths that create a BasicLock also clears the memory, so we do not read garbage. And that no platform relies on the CacheSetter, I do not think that is the case. I see you fixed the C++ constructions with a constructor. But need to look at (interpreter, c1, c2, jvmci) x (all supported platforms). I think the CacheSetter in quick_enter was added specifically for x86_32 which used to share the C2 code with x86_64. However after [JDK-8338383](https://bugs.openjdk.org/browse/JDK-8338383) / #21565 x86_32 C2 support was disabled due to 64bit CAS requirements. So this might work, and the x86_32 is deprecated and being actively removed, but I think it would be good to have the clear the thread stack cache (BasicLock) for NOT_LP64. 

# Second the spinning:

`try_enter` -> `spin_enter`

This changes the monitor spinning quite dramatically. For virtual threads the number of `try_spin` calls increase from 1 -> 2 (+100%). And for non virtual threads the number of `try_spin` calls increase from 2 -> 3 (+50%). This seems significant enough to warrant looking at a large suite of benchmarks and see how they behave. And remember multiple calls to `try_spin` affect both the total spin duration and the velocity of the adaptive spinning change.

# Performance evaluation

I spent some time yesterday trying to understand what in this patch is important for performance. Xalan seems to be a workload which wants to spend its time in `try_spin`. When playing around with the patch, the `try_enter` -> `spin_enter` change seems to be the most important change, at least in our (Oracle) java performance system. But have not exhaustively tested all changes. And the behavior in our java performance system and what I see on my virtualized sky lake xeon based cloud instance differs quite a bit. 

I suspect it boils down to the sort of "effective" scheduling of our successor windows (times when there is a successor set). Which avoids exit slow paths and re-locking.

This made me do some experiments with the successor and evaluate the performance.

Explanation of the different versions
* Base: b891bfa7e67c21478475642e2bfa2cdc65a3bffe
  * Mainline commit used as a baseline (the current PRs base)
* PR: fc5062a48767646414f9fd7e57a9370c766bda3e
  * The PR branch as of fc5062a: Include objectMonitor.inline.hpp
  * Personal instance:
    * Reduced regression by 27% with table (-XX:+UseObjectMonitorTable)
    * 16% regression without table (-XX:-UseObjectMonitorTable)
  * Oracle Java Performance System:
    * Reduced regression by 73% with table (-XX:+UseObjectMonitorTable) on Linux x64
    * Regression gone with table (-XX:+UseObjectMonitorTable) on Linux aarch64
      * Not significant, needs more runs.
    * Run without table (-XX:-UseObjectMonitorTable) is still in the queue.
* V3: https://github.com/xmas92/jdk/tree/JDK-8339114-review-v3
  * This is just my review comments / cleanups on the PR. 
  * Has the same performance characteristics as the PR.
* V4: https://github.com/xmas92/jdk/tree/JDK-8339114-review-v4
  * Adhoc experiment with successor. Only clear the successor after the final spin, before parking.
  * Most likely incorrect / contains holes, but should only lead to stranding. (Looking at GHA there seem to be some stranding occurring). Though it is an interesting idea to evaluate.
  * Personal instance:
    * Similar performance as the PR / V3 branch
  * Oracle Java Performance System:
    * Regression gone with table (-XX:+UseObjectMonitorTable) on both Linux aarch64 and x64
      * Not significant, needs more runs.
* V5: https://github.com/xmas92/jdk/tree/JDK-8339114-review-v5
  * Instead of only clearing before the parking. It clears the successor more often, every 256 iteration of the `try_spin` spin loop. The idea is to instead of prologing the successor window, create more small windows where the successor is clear so that other threads that may be earlier in their spinning can take over the successor. 
  * This is probably correct, there might be that a fence is needed after clearing the successor inside the loop. The reason that it is not there is because the spinner will always either get the lock or retry setting the successor, which if it succeeds will lead to a fence later, or another thread have become the successor, and that thread will fence.
  * Personal instance:
    * Marginal improvements over V4.
  * Oracle Java Performance System:
    * Is still in the queue.
* V6: https://github.com/xmas92/jdk/tree/JDK-8339114-review-v6
  * Based on V4, but it sets the successor unconditionally in `try_spin` which may overwrite another successor. The idea is similar to V5 but instead of sometimes clearing, we simply allow for as long as a thread is in `try_spin` there is a successor, and reducing the number of clear successors (and fences) required.
  * The branch has stranding issues because it is based on V4. Will probably rerun this experiment but without the V4 changes to the successor.
  * Personal instance:
    * Marginal improvements over V4.
  * Oracle Java Performance System:
    * Is still in the queue.
* V7: https://github.com/xmas92/jdk/tree/JDK-8339114-review-v7
  * Based on V6. But now clearing the successor is done with a CAS, and only if it succeeds do the thread fence.
  * The branch has stranding issues because it is based on V4.
  * Combining this with V6 is probably a bad idea, because all threads are writing to this cache line, and at the same time some thread is trying to CAS. It is probably more effective do just do the load check store fence, and sometimes overwrite another threads successor claiming. (The idea was to not allow any time slice where there are no successor if there is a thread inside, but seems not worth the tradeoff).
  * Personal instance:
    * No improvement over V3, (effectively negates the improvements gained by V4+V6)
  * Oracle Java Performance System:
    * Is still in the queue.

# Conclusion

I think parts of this PR could go in. But the enter changes should be held of on until we understand the impact on other benchmarks (even if we can just use `try_enter` over `spin_enter` for -XX:-UseObjectMonitorTable to avoid the -XX:-UseObjectMonitorTable regressions).

I also think there is some room for improvements with this CacheSetter and C2. Using the thread stack cache is (currently) only relevant for C2. If keep track in the runtime that we came from a context where this thread stack cache is preloaded with what is in the thread local stack, or nullptr. We can optimize away a lot of the CacheSetter logic. Have only be something we do if we retry due to deflation or if we come from a another context. From other contexts clear the thread stack cache is required and setting the thread stack cache is beneficial due to OSR. But it may not be worth setting the the thread local cache unless we are locking from C2, because on C2 uses this cache for lookups, and C2 is what we want to be fast. So limit the OMCache to only C2 locked monitors is probably beneficial. 

I will update the this post with the rest of the benchmark results as they finished, maybe something I do next week. Similarly I might experiment some more with a better version of V6. 

Cheers.

# Benchmarks results

## On Personal Intel cloud instance:

* Difference vs Base Without Table (-XX:-UseObjectMonitorTable) b891bfa7e67c21478475642e2bfa2cdc65a3bffe
  * With Table (-XX:+UseObjectMonitorTable)
    * Columns
      * `Name               Cnt     Base    Error      Test    Error Unit  Change (* = significant)`
    * Base b891bfa7e67c21478475642e2bfa2cdc65a3bffe
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1474.200 ? 50.614   ms   0.75x (p = 0.000*)`
    * PR branch fc5062a48767646414f9fd7e57a9370c766bda3e
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1407.650 ? 37.815   ms   0.79x (p = 0.000*)`
    * v3 branch b18c83a8118d58ef615405de494234971336878d
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1414.650 ? 50.783   ms   0.79x (p = 0.000*)`
    * v4 branch ec91413b81a410cc9f00920f6987c5c3ca4d1ed2
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1423.000 ? 39.226   ms   0.78x (p = 0.000*)`
    * v5 branch 19340a0f8930fa916154f2f7549faedcf1f20f02
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1405.600 ? 78.450   ms   0.79x (p = 0.000*)`
    * v6 branch 9a332cb090fb5797907052533f41556dd7cdeb94
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1371.750 ? 36.835   ms   0.81x (p = 0.000*)`
    * v7 branch 13297b13bd2a9e89e1a51c7a4e27ad39928a8b00
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1474.700 ? 72.045   ms   0.75x (p = 0.000*)`
  * Without Table (-XX:-UseObjectMonitorTable)
    * Columns
      * `Name               Cnt     Base    Error      Test    Error Unit  Change (* = significant)`
    * PR branch fc5062a48767646414f9fd7e57a9370c766bda3e
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1324.650 ? 46.528   ms   0.84x (p = 0.000*)` 
    * v3 branch b18c83a8118d58ef615405de494234971336878d
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1322.600 ? 46.727   ms   0.84x (p = 0.000*)`
    * v4 branch ec91413b81a410cc9f00920f6987c5c3ca4d1ed2
      * `Not run yet`
    * v5 branch 19340a0f8930fa916154f2f7549faedcf1f20f02
      * `DaCapo-xalan-large  20 1111.150 ? 49.733  1309.450 ? 31.553   ms   0.85x (p = 0.000*)`
    * v6 branch 9a332cb090fb5797907052533f41556dd7cdeb94
      * `Not run yet`
    * v7 branch 13297b13bd2a9e89e1a51c7a4e27ad39928a8b00
      * `Not run yet`


## In Oracle Java Performance System:

### Linux x64
* Difference vs Base Without Table (-XX:-UseObjectMonitorTable) b891bfa7e67c21478475642e2bfa2cdc65a3bffe
  * With Table (-XX:+UseObjectMonitorTable)
    * Columns
      * `Name                Cnt    Base    Error      Test    Error Unit  Change (* = significant)`
    * Base b891bfa7e67c21478475642e2bfa2cdc65a3bffe
      * `DaCapo-xalan-large   20 1172.50 ?  39.45   1344.15 ?  83.49   ms   0.75x (p = 0.000*)`
      * `DaCapo23-xalan-large  5 9763.60 ? 479.44  10803.20 ? 864.69   ms   0.89x (p = 0.0553)`
    * PR branch fc5062a48767646414f9fd7e57a9370c766bda3e
      * `DaCapo-xalan-large   20 1172.50 ?  39.45   1218.40 ?  64.03   ms   0.96x (p = 0.0103)`
      * `DaCapo23-xalan-large  5 9763.60 ? 479.44  10182.40 ? 391.79   ms   0.96x (p = 0.1703)`
    * v3 branch b18c83a8118d58ef615405de494234971336878d
      * `DaCapo-xalan-large   20 1172.50 ?  39.45   1235.75 ?  60.57   ms   0.95x (p = 0.0004*)`
      * `DaCapo23-xalan-large  5 9763.60 ? 479.44  10111.40 ? 441.37   ms   0.96x (p = 0.2671)`
    * v4 branch ec91413b81a410cc9f00920f6987c5c3ca4d1ed2
      * `DaCapo-xalan-large   20 1172.50 ?  39.45   1161.15 ?  47.45   ms   1.01x (p = 0.4161)`
      * `DaCapo23-xalan-large  5 9763.60 ? 479.44   9812.00 ? 419.23   ms   1.00x (p = 0.8694)`
    * v5 branch 19340a0f8930fa916154f2f7549faedcf1f20f02
      * `In queue`
    * v6 branch 9a332cb090fb5797907052533f41556dd7cdeb94
      * `In queue`
    * v7 branch 13297b13bd2a9e89e1a51c7a4e27ad39928a8b00
      * `In queue`
  * Without Table (-XX:-UseObjectMonitorTable)
    * Columns
      * `Name                Cnt     Base    Error      Test    Error Unit  Change (* = significant)`
    * PR branch fc5062a48767646414f9fd7e57a9370c766bda3e
      * `In queue`

### Linux aarch64

* Difference vs Base Without Table (-XX:-UseObjectMonitorTable) b891bfa7e67c21478475642e2bfa2cdc65a3bffe
  * With Table (-XX:+UseObjectMonitorTable)
    * Columns
      * `Name                Cnt     Base    Error      Test    Error Unit  Change (* = significant)`
    * Base b891bfa7e67c21478475642e2bfa2cdc65a3bffe
      * `DaCapo-xalan-large   20  1999.55 ?  81.08   2176.85 ? 100.63   ms   0.91x (p = 0.000*)`
      * `DaCapo23-xalan-large  5 15595.20 ? 524.15  15326.60 ? 442.64   ms   1.02x (p = 0.4075)`
    * PR branch fc5062a48767646414f9fd7e57a9370c766bda3e
      * `DaCapo-xalan-large   20  1999.55 ?  81.08   2003.25 ?  83.89   ms   1.00x (p = 0.8880)`
      * `DaCapo23-xalan-large  5 15595.20 ? 524.15  15960.80 ? 826.91   ms   0.98x (p = 0.4322)`
    * v3 branch b18c83a8118d58ef615405de494234971336878d
      * `DaCapo-xalan-large   20  1999.55 ?  81.08   2020.60 ?  70.67   ms   0.99x (p = 0.3870)`
      * `DaCapo23-xalan-large  5 15595.20 ? 524.15  15382.00 ? 385.40   ms   1.01x (p = 0.4864)`
    * v4 branch ec91413b81a410cc9f00920f6987c5c3ca4d1ed2
      * `DaCapo-xalan-large   20  1999.55 ?  81.08   1987.55 ?  73.91   ms   1.01x (p = 0.6276)`
      * `DaCapo23-xalan-large  5 15595.20 ? 524.15  15601.00 ? 996.23   ms   1.00x (p = 0.9912)`
    * v5 branch 19340a0f8930fa916154f2f7549faedcf1f20f02
      * `In queue`
    * v6 branch 9a332cb090fb5797907052533f41556dd7cdeb94
      * `In queue`
    * v7 branch 13297b13bd2a9e89e1a51c7a4e27ad39928a8b00
      * `In queue`
  * Without Table (-XX:-UseObjectMonitorTable)
    * Columns
      * `Name                Cnt     Base    Error      Test    Error Unit  Change (* = significant)`
    * PR branch fc5062a48767646414f9fd7e57a9370c766bda3e
      * `In queue`

-------------

Changes requested by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24098#pullrequestreview-2724780944

From alanb at openjdk.org  Fri Mar 28 09:29:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Mar 2025 09:29:13 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <v596TlVCfNtjrGUEXtFItD4xTol9OIECCs2ABgsKUAw=.2ac68717-ed86-4700-afdd-b66e8c46fae1@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
 <v596TlVCfNtjrGUEXtFItD4xTol9OIECCs2ABgsKUAw=.2ac68717-ed86-4700-afdd-b66e8c46fae1@github.com>
Message-ID: <0Y8uHktq6uDbnT2Pydvzi0Ighxuvqw4Rajix5G9ZoAs=.cb0be1e7-594b-4886-8fed-a717e44e4e1f@github.com>

On Fri, 21 Feb 2025 07:10:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Nicole Xu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe
>>    
>>    The UnsafeOps JMH benchmark fails with the following error:
>>    
>>          ```
>>          java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>>          ```
>>    
>>    Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
>>    `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
>>    
>>    Note that even it will raise "proprietary API" warnings after this
>>    patch, it is acceptable because the relevant APIs are bound for removal
>>    for the integrity of the platform.
>>    
>>    Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c
>>  - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe"
>>    
>>    This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b.
>
> Thanks for restoring, this micro was specifically for sun.misc.Unsafe. I'm not wondering about the FFM micros that were also changed by JDK-8332744. Might not matter there but I think the original motive was to compare against sun.misc.Unsafe usage.

> @AlanBateman Can you review this if this patch looks good in principle? 

It needs confirmation that it doesn't break the build, I haven't looked into which parts of Liam's change weren't backed out. So if there are no build issues then it should be okay to integrate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2760691364

From mbaesken at openjdk.org  Fri Mar 28 10:00:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Mar 2025 10:00:25 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v4]
In-Reply-To: <mkMV1z7f-wZmqNw4QJBhnHPVWXHZqkQacDw_y2b04us=.2a3859c2-7603-4129-b4bd-afb09b7e0403@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <mkMV1z7f-wZmqNw4QJBhnHPVWXHZqkQacDw_y2b04us=.2a3859c2-7603-4129-b4bd-afb09b7e0403@github.com>
Message-ID: <8Z-6vUr6JviTC4Ce5o6cUsDKYzIArZdM2lSiI6Ex1cg=.b4082cf9-bc48-4c10-9dba-545d007aab67@github.com>

On Thu, 27 Mar 2025 14:15:12 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
>> 
>> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
>> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
>> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
>> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
>> 
>> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
>> So my proposal is to skip this sub test for aix and musl.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add !windows again and remove @compile

test/jdk/tools/launcher/ExecutionEnvironment.java line 42:

> 40:  *      LD_LIBRARY_PATH if set are not modified in any way.
> 41:  *   3. the correct vm is chosen with -server and -client options
> 42:  *   4. no extra symlink exists on Solaris i.e.

You can remove Solaris, we do not build/test on Solaris for some time .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24055#discussion_r2018277509

From jkern at openjdk.org  Fri Mar 28 10:08:43 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 28 Mar 2025 10:08:43 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v5]
In-Reply-To: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
Message-ID: <ryBLyQg-BcLGDwC9et0cn51Kb8plg4UH-qQjeREYsHc=.57a6e6cd-d357-472a-8004-bd63c03020ba@github.com>

> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
> 
> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
> 
> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
> So my proposal is to skip this sub test for aix and musl.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  remove Solaris remnant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24055/files
  - new: https://git.openjdk.org/jdk/pull/24055/files/3f72981e..bfe39455

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24055/head:pull/24055

PR: https://git.openjdk.org/jdk/pull/24055

From clanger at openjdk.org  Fri Mar 28 10:56:15 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 28 Mar 2025 10:56:15 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v4]
In-Reply-To: <8Z-6vUr6JviTC4Ce5o6cUsDKYzIArZdM2lSiI6Ex1cg=.b4082cf9-bc48-4c10-9dba-545d007aab67@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <mkMV1z7f-wZmqNw4QJBhnHPVWXHZqkQacDw_y2b04us=.2a3859c2-7603-4129-b4bd-afb09b7e0403@github.com>
 <8Z-6vUr6JviTC4Ce5o6cUsDKYzIArZdM2lSiI6Ex1cg=.b4082cf9-bc48-4c10-9dba-545d007aab67@github.com>
Message-ID: <3VQbb-w2axmr0MzS-qeDYjJe02M1vu61_kNGsfJ5Z4M=.3a1bd7dd-4934-47c7-b2bb-73a1a04c780e@github.com>

On Fri, 28 Mar 2025 09:55:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add !windows again and remove @compile
>
> test/jdk/tools/launcher/ExecutionEnvironment.java line 42:
> 
>> 40:  *      LD_LIBRARY_PATH if set are not modified in any way.
>> 41:  *   3. the correct vm is chosen with -server and -client options
>> 42:  *   4. no extra symlink exists on Solaris i.e.
> 
> You can remove Solaris, we do not build/test on Solaris for some time .

I think it is wrong to completely remove point 4. You should rather remove the term "on Solaris". The thing itself is still tested in testNoSymLink().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24055#discussion_r2018408222

From mbaesken at openjdk.org  Fri Mar 28 11:02:05 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Mar 2025 11:02:05 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v4]
In-Reply-To: <3VQbb-w2axmr0MzS-qeDYjJe02M1vu61_kNGsfJ5Z4M=.3a1bd7dd-4934-47c7-b2bb-73a1a04c780e@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <mkMV1z7f-wZmqNw4QJBhnHPVWXHZqkQacDw_y2b04us=.2a3859c2-7603-4129-b4bd-afb09b7e0403@github.com>
 <8Z-6vUr6JviTC4Ce5o6cUsDKYzIArZdM2lSiI6Ex1cg=.b4082cf9-bc48-4c10-9dba-545d007aab67@github.com>
 <3VQbb-w2axmr0MzS-qeDYjJe02M1vu61_kNGsfJ5Z4M=.3a1bd7dd-4934-47c7-b2bb-73a1a04c780e@github.com>
Message-ID: <MdIo1i_-po4_qWM_M-XqdeEjVz7u9x0CVWuDc3i5MO4=.e3d091cf-dfac-48f5-94ea-b624932d5f24@github.com>

On Fri, 28 Mar 2025 10:52:55 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I think it is wrong to completely remove point 4. You should rather remove the term "on Solaris". The thing itself is still tested in testNoSymLink().

Yes just remove Solaris not the whole comment  (on the other hand, is the symlink point still valid/important these days) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24055#discussion_r2018423646

From dholmes at openjdk.org  Fri Mar 28 12:27:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Mar 2025 12:27:17 GMT
Subject: RFR: 8352114: New test runtime/interpreter/CountBytecodesTest.java
 is failing
In-Reply-To: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
References: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
Message-ID: <KLuXXiRIiPCk0DQYL65Zj-Ip9iKkAamyLPDB6TtsZYA=.ae267484-2bd9-459d-a594-2b4354ecbfe0@github.com>

On Thu, 27 Mar 2025 15:19:43 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> 8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

I will test this on Monday.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24281#issuecomment-2761219515

From gziemski at openjdk.org  Fri Mar 28 14:33:55 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 28 Mar 2025 14:33:55 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v2]
In-Reply-To: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
Message-ID: <SOHQgPFIQSVbOrp3EagaPuCJP-lgncn_L1kYr3RdM60=.706cef5f-3f96-4473-a684-7c8b11dfb229@github.com>

> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
> 
> proposed:
> 
> time:72,642,827[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> existing code:
> 
> time:73,085,446[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
> 
> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
> 
> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
> 
> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

Gerard Ziemski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8301404
 - work
 - work
 - work
 - work
 - work:
 - work
 - work
 - work
 - work
 - ... and 5 more: https://git.openjdk.org/jdk/compare/0d33a7af...01470b34

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24189/files
  - new: https://git.openjdk.org/jdk/pull/24189/files/abfb5f2c..01470b34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=00-01

  Stats: 52215 lines in 1601 files changed: 12489 ins; 34879 del; 4847 mod
  Patch: https://git.openjdk.org/jdk/pull/24189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24189/head:pull/24189

PR: https://git.openjdk.org/jdk/pull/24189

From gziemski at openjdk.org  Fri Mar 28 14:36:08 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 28 Mar 2025 14:36:08 GMT
Subject: RFR: 8341095: Possible overflow in os::Posix::print_uptime_info
 [v3]
In-Reply-To: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>
References: <W7lXJ4WDbjlM1h200bi0lBbOJMPijAWCLCBOj2Uja1c=.54c9e8ca-65be-42ae-9287-9affe2c589ea@github.com>
Message-ID: <RItxJImedXzz3vouNn8MYWaEKPUf79ZejRD2W6dBUWU=.42fc365c-2971-4169-8440-a3a11f3632a2@github.com>

> This is a trivial change that will quiet Xcode only visual warning in os_posix.cpp file.
> 
> There are 31,536,000 seconds in a year, so if int is 32bits, then we have MAX int value of 2,147,483,647 so it would overflow in 68 years - unlikely to affect anyone.

Gerard Ziemski 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 17 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8341095
 - Merge remote-tracking branch 'upstream/master' into JDK-8341095
 - remove test stufff
 - remove test stufff
 - remove test stufff
 - test
 - test
 - test
 - test
 - test
 - ... and 7 more: https://git.openjdk.org/jdk/compare/5b2bfbfe...c9d07aa6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24140/files
  - new: https://git.openjdk.org/jdk/pull/24140/files/0ca5615f..c9d07aa6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24140&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24140&range=01-02

  Stats: 51614 lines in 1598 files changed: 11978 ins; 34812 del; 4824 mod
  Patch: https://git.openjdk.org/jdk/pull/24140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24140/head:pull/24140

PR: https://git.openjdk.org/jdk/pull/24140

From coleenp at openjdk.org  Fri Mar 28 16:28:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Mar 2025 16:28:26 GMT
Subject: RFR: 8339114: DaCapo xalan performance with
 -XX:+UseObjectMonitorTable [v3]
In-Reply-To: <y-y8xOaFmHnNbITpoqhM8yPRcM5GaNN0TsathNvAO-U=.5ca2af8c-c960-4cc9-9d39-e85f09b7da35@github.com>
References: <JSIzNPF8exKAEGifxk4avSLqwNSwzM0M6e7CGgkOrhI=.704bd957-836f-4ade-ab8c-71a20a672d8f@github.com>
 <y-y8xOaFmHnNbITpoqhM8yPRcM5GaNN0TsathNvAO-U=.5ca2af8c-c960-4cc9-9d39-e85f09b7da35@github.com>
Message-ID: <ftPyH-LJMvZD9Z6v5br2sU7IvLXoBGTDgItItLE11cA=.0e44ff64-c264-4fbf-9427-12deeba1dd57@github.com>

On Wed, 26 Mar 2025 07:54:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> - When successfully looked up an OM in the OMCache, then make it avaiable in the BasicLock cache. Use that cache whenever possible.
>> - When successfully looked up an OM in the OMCache, then don't push-back the OM on that cache to avoid shuffling the cache on each monitor enter.
>> - In the runtime path of monitorexit, attempt to use the BasicLock cache, then the OMCache, and only look up in the table when the caches failed.
>> - Some small code shufflings.
>> 
>> I did 50 runs of xalan, each of which do 10 warmup iterations before doing one measurement. The following results are the averages of the measurement iterations across the 50 runs:
>> without-OMT: 773.3 ms
>> with-OMT: 797.28 ms
>> 
>> That is still a regression of ~3%
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include objectMonitor.inline.hpp

My testing also showed that the try_spin was the most beneficial of these changes to getting UseObjectMonitorTable performance mostly up to without UseObjectMonitorTable.

I've just started a Oracle internal benchmark run comparing mainline (base) with a version with try_spin instead of try_lock to see if that change has any adverse effects on any of the other benchmarks without UseObjectMonitorTable.  xalan does benefit from adaptive spinning, so it makes sense moving this extra level of spinning earlier.

The BasicLock cache and OMCache changes are really good, so we want these and the try_spin changes if they don't regress any benchmarks (will update with results).  That's this PR.

The cleanup to add read_caches() to encapsulate both BasicLock and OMCache is nice but I don't really like the new read_monitor().  LightweightSynchronizer::read_caches() can be private in lightweightSynchronizer.cpp and added to this change.  Not sure about the CacheSetter changes to Axel's changes.  And the successor changes should be in another PR.

I still think this PR is a good improvement, as is, pending try_spin performance testing.  The additional work should be done as a set of separate PRs.  1. Fix CacheSetter to be only used for C2 (possibly, but do we want more conditional code?) 2. Experiment with setting successor in ObjectMonitor::try_spin.  I did a little of this once and didn't have any good numbers to show for it, so I think it should be a new investigation. Your numbers are better for this.

Lastly, thank you Axel for running these performance tests. It looks like the performance for the PR change is quite good on the Oracle benchmarking machines, but less good on your personal cloud instance.  The performance tests that we've (Eric Caspole and I have) done show that the PR changes are mostly good with some expected variation that we always see with locking changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24098#issuecomment-2761849268

From jkern at openjdk.org  Fri Mar 28 17:04:03 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 28 Mar 2025 17:04:03 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v6]
In-Reply-To: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
Message-ID: <pi7W0uNdHZUr-LPysc5qg_JluSTMgx5gC4HP4bBNgwM=.b23e2eb1-a4f2-4be5-b93a-5e66feca9a70@github.com>

> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
> 
> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
> 
> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
> So my proposal is to skip this sub test for aix and musl.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  add symlink comment again, but without solaris

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24055/files
  - new: https://git.openjdk.org/jdk/pull/24055/files/bfe39455..966c1435

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24055&range=04-05

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24055/head:pull/24055

PR: https://git.openjdk.org/jdk/pull/24055

From duke at openjdk.org  Fri Mar 28 18:11:47 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 28 Mar 2025 18:11:47 GMT
Subject: RFR: 8353190: Use "/native" Run Option for TestAvailableProcessors
 Execution
Message-ID: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>

Currently, the test executes the program using `test.nativepath`, but it relies on path resolution. I propose following standard conventions in this case and running the test with the `/native` option instead.

With this change:
- Path resolution is no longer required.
- If `nativepath` is not specified at runtime, a standard error message will be printed to the console.

This improves consistency and simplifies the test execution process.

I kindly ask the original author of the test @swesonga and those who reviewed the original pull request  #17576 for this test to take a look at this PR: @jdksjolen and @dholmes

-------------

Commit messages:
 - Replaced the call to GetProcessorInfo.exe via resolve path with the use of the test launch option "/native".

Changes: https://git.openjdk.org/jdk/pull/23803/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23803&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353190
  Stats: 12 lines in 1 file changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23803/head:pull/23803

PR: https://git.openjdk.org/jdk/pull/23803

From duke at openjdk.org  Fri Mar 28 18:11:47 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 28 Mar 2025 18:11:47 GMT
Subject: RFR: 8353190: Use "/native" Run Option for TestAvailableProcessors
 Execution
In-Reply-To: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
References: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
Message-ID: <x3ssQeLDTqhHJpQcSVmITnwydYP0v-3jyUaRkOF4eKI=.fff20057-4539-4ac2-9ee7-f4854a38d0ab@github.com>

On Wed, 26 Feb 2025 14:17:31 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Currently, the test executes the program using `test.nativepath`, but it relies on path resolution. I propose following standard conventions in this case and running the test with the `/native` option instead.
> 
> With this change:
> - Path resolution is no longer required.
> - If `nativepath` is not specified at runtime, a standard error message will be printed to the console.
> 
> This improves consistency and simplifies the test execution process.
> 
> I kindly ask the original author of the test @swesonga and those who reviewed the original pull request  #17576 for this test to take a look at this PR: @jdksjolen and @dholmes

Hi @asilichenko, is there a JBS issue for this fix? I do see the improved error message when the -nativepath argument is not provided. Thanks for the improvement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23803#issuecomment-2689969156

From duke at openjdk.org  Fri Mar 28 18:11:47 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 28 Mar 2025 18:11:47 GMT
Subject: RFR: 8353190: Use "/native" Run Option for TestAvailableProcessors
 Execution
In-Reply-To: <x3ssQeLDTqhHJpQcSVmITnwydYP0v-3jyUaRkOF4eKI=.fff20057-4539-4ac2-9ee7-f4854a38d0ab@github.com>
References: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
 <x3ssQeLDTqhHJpQcSVmITnwydYP0v-3jyUaRkOF4eKI=.fff20057-4539-4ac2-9ee7-f4854a38d0ab@github.com>
Message-ID: <SxxySz31y7aWprVZgQsPPqZQlBmWg8WziSYsu8NSmuU=.cef47d86-92fb-4e9d-acef-102f0f90a52e@github.com>

On Fri, 28 Feb 2025 07:54:25 GMT, Saint Wesonga <duke at openjdk.org> wrote:

> Hi @asilichenko, is there a JBS issue for this fix? I do see the improved error message when the -nativepath argument is not provided. Thanks for the improvement.

Hi @swesonga, thank you for your feedback. Unfortunately, there isn't a JBS issue for this fix, as I don't have the permissions to create one. I hope someone with the necessary rights will create the issue.

Regarding the error message, it wasn?t improved, but I made it so that when `-nativepath` is not set, the system automatically outputs the default message for this case, instead of the misleading "GetProcessorInfo.exe file not found", which didn't clearly indicate that `-nativepath` should be set.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23803#issuecomment-2690278771

From duke at openjdk.org  Fri Mar 28 18:11:47 2025
From: duke at openjdk.org (Oleksii Sylichenko)
Date: Fri, 28 Mar 2025 18:11:47 GMT
Subject: RFR: 8353190: Use "/native" Run Option for TestAvailableProcessors
 Execution
In-Reply-To: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
References: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
Message-ID: <fsuIhUkJ-Yqgc3DncpYbkostN6tXoO01sb88MgwfKKw=.ce06cbe0-d50d-4790-9be5-46e90727f29a@github.com>

On Wed, 26 Feb 2025 14:17:31 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Currently, the test executes the program using `test.nativepath`, but it relies on path resolution. I propose following standard conventions in this case and running the test with the `/native` option instead.
> 
> With this change:
> - Path resolution is no longer required.
> - If `nativepath` is not specified at runtime, a standard error message will be printed to the console.
> 
> This improves consistency and simplifies the test execution process.
> 
> I kindly ask the original author of the test @swesonga and those who reviewed the original pull request  #17576 for this test to take a look at this PR: @jdksjolen and @dholmes

keep-alive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23803#issuecomment-2761682576

From duke at openjdk.org  Fri Mar 28 18:11:47 2025
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 28 Mar 2025 18:11:47 GMT
Subject: RFR: 8353190: Use "/native" Run Option for TestAvailableProcessors
 Execution
In-Reply-To: <fsuIhUkJ-Yqgc3DncpYbkostN6tXoO01sb88MgwfKKw=.ce06cbe0-d50d-4790-9be5-46e90727f29a@github.com>
References: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
 <fsuIhUkJ-Yqgc3DncpYbkostN6tXoO01sb88MgwfKKw=.ce06cbe0-d50d-4790-9be5-46e90727f29a@github.com>
Message-ID: <euuuHNDg9ERFa-auoAaYCbthqMaXRJpNa6AFe7oBQ4U=.c6b59899-fdd5-4e77-a2de-7807855a95ae@github.com>

On Fri, 28 Mar 2025 15:23:02 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, the test executes the program using `test.nativepath`, but it relies on path resolution. I propose following standard conventions in this case and running the test with the `/native` option instead.
>> 
>> With this change:
>> - Path resolution is no longer required.
>> - If `nativepath` is not specified at runtime, a standard error message will be printed to the console.
>> 
>> This improves consistency and simplifies the test execution process.
>> 
>> I kindly ask the original author of the test @swesonga and those who reviewed the original pull request  #17576 for this test to take a look at this PR: @jdksjolen and @dholmes
>
> keep-alive

@asilichenko, I have created https://bugs.openjdk.org/browse/JDK-8353190 for this change.  You will need to change the PR title to start with the JBS issue ID followed by a colon, similar to the other PRs at https://github.com/openjdk/jdk/pulls

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23803#issuecomment-2761819548

From amenkov at openjdk.org  Fri Mar 28 20:09:18 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 28 Mar 2025 20:09:18 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
 [v3]
In-Reply-To: <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
 <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
Message-ID: <i-h-6u3UzxOKhbEmpeTslcfkyoad1zwYk9DVF6YpgQk=.b3e1601e-9501-4f14-a4ed-39ba07fa7419@github.com>

On Fri, 28 Mar 2025 09:01:26 GMT, Varada M <varadam at openjdk.org> wrote:

>> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
>> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
>> 
>> tier1, tier2 and tier3 testing is successful with fastdebug level
>> 
>> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)
>
> Varada M has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated copyright header
>  - removed StreamingOutputTest.java from problem list

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24177#pullrequestreview-2726618858

From ccheung at openjdk.org  Sat Mar 29 04:56:36 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Sat, 29 Mar 2025 04:56:36 GMT
Subject: RFR: 8171508: os::jvm_path: error in handling
 -Dsun.java.launcher.is_altjvm option after 8066474
Message-ID: <J7H9yC6VskVDVZO0l1IXkfW-_AZn03FRktBmmDA7zIY=.9d7bcf5e-dbe1-494f-bb6f-5c81c4c9c817@github.com>

This change fixes two issues in `os::jvm_path()`:

- go back 4 instead of 5 slashes and then checking for "/jre/lib";
- fix the hardcoded "hotspot" sub-directory before the jvm library name.

Passed tiers 1 - 3 testing.

-------------

Commit messages:
 - 8171508: os::jvm_path: error in handling -Dsun.java.launcher.is_altjvm option after 8066474

Changes: https://git.openjdk.org/jdk/pull/24310/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24310&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8171508
  Stats: 21 lines in 4 files changed: 3 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24310.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24310/head:pull/24310

PR: https://git.openjdk.org/jdk/pull/24310

From stuefe at openjdk.org  Sat Mar 29 06:28:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 29 Mar 2025 06:28:10 GMT
Subject: RFR: 8171508: os::jvm_path: error in handling
 -Dsun.java.launcher.is_altjvm option after 8066474
In-Reply-To: <J7H9yC6VskVDVZO0l1IXkfW-_AZn03FRktBmmDA7zIY=.9d7bcf5e-dbe1-494f-bb6f-5c81c4c9c817@github.com>
References: <J7H9yC6VskVDVZO0l1IXkfW-_AZn03FRktBmmDA7zIY=.9d7bcf5e-dbe1-494f-bb6f-5c81c4c9c817@github.com>
Message-ID: <VYqFAd0c2KiBjVR3cvxEXS5bGWDl7WWExPAgSBNQbuI=.c0a6f053-f7b6-4e80-a937-ebc4cde173ac@github.com>

On Sat, 29 Mar 2025 04:28:49 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This change fixes two issues in `os::jvm_path()`:
> 
> - go back 4 instead of 5 slashes and then checking for "/jre/lib";
> - fix the hardcoded "hotspot" sub-directory before the jvm library name.
> 
> Passed tiers 1 - 3 testing.

Hi @calvinccheung, I thought we planned on removing altjvm handling altogether? See mail thread https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2017-April/023205.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2763187206

From stuefe at openjdk.org  Sat Mar 29 06:41:16 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 29 Mar 2025 06:41:16 GMT
Subject: RFR: 8171508: os::jvm_path: error in handling
 -Dsun.java.launcher.is_altjvm option after 8066474
In-Reply-To: <J7H9yC6VskVDVZO0l1IXkfW-_AZn03FRktBmmDA7zIY=.9d7bcf5e-dbe1-494f-bb6f-5c81c4c9c817@github.com>
References: <J7H9yC6VskVDVZO0l1IXkfW-_AZn03FRktBmmDA7zIY=.9d7bcf5e-dbe1-494f-bb6f-5c81c4c9c817@github.com>
Message-ID: <hhOgyGKbWCVuf81DWoJ4YLBszot57PbzST0U_cFZeLI=.ed8bd9d9-e040-407c-ad9f-5d9668b1a077@github.com>

On Sat, 29 Mar 2025 04:28:49 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This change fixes two issues in `os::jvm_path()`:
> 
> - go back 4 instead of 5 slashes and then checking for "/jre/lib";
> - fix the hardcoded "hotspot" sub-directory before the jvm library name.
> 
> Passed tiers 1 - 3 testing.

See https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2017-April/023228.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24310#issuecomment-2763191351

From stuefe at openjdk.org  Sun Mar 30 16:49:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 30 Mar 2025 16:49:02 GMT
Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS archive
Message-ID: <brAzvbymuYfkdhJv6ldG9_ZPvq-GBvXhoRNs1ELcqCQ=.87d40500-de5a-4690-bd78-f8c576456611@github.com>

Please consider.

This patch adds a way to iterate all Klass structures in the loaded CDS archive (`SystemDictionaryShared::iterate_klasses_in_shared_archive(ConstKlassClosure* klassClosure, bool is_static);`). This uses the same mechanism that `PrintSharedArchiveAndExit` uses. I  need this mechanism for some future GC work.

Then, it re-implements `PrintSharedArchiveAndExit` to reuse the new iteration API instead. This also serves as a way to test, since there are pre-existing tests for this flag.

It also adds a new, rather basic, gtest.

Finally, the new gtest picked up a small pre-existing bug in the implementation of `PrintSharedArchiveAndExit`: it prints all array classes of all InstanceKlass inside the archive, for all dimensions, without testing if that array class is part of the archive. The array class may have been created dynamically, however. The patch fixes that.

----

Testing:
- I ensured that the output of `PrintSharedArchiveAndExit`, before and after this patch, are identical apart from the small error fix concerning array classes
- I ran all runtime/cds tests on Linux x64
- GHAs

-------------

Commit messages:
 - iterate_klasses

Changes: https://git.openjdk.org/jdk/pull/24311/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24311&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353225
  Stats: 195 lines in 10 files changed: 146 ins; 16 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/24311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24311/head:pull/24311

PR: https://git.openjdk.org/jdk/pull/24311

From stuefe at openjdk.org  Sun Mar 30 16:49:02 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 30 Mar 2025 16:49:02 GMT
Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS
 archive
In-Reply-To: <brAzvbymuYfkdhJv6ldG9_ZPvq-GBvXhoRNs1ELcqCQ=.87d40500-de5a-4690-bd78-f8c576456611@github.com>
References: <brAzvbymuYfkdhJv6ldG9_ZPvq-GBvXhoRNs1ELcqCQ=.87d40500-de5a-4690-bd78-f8c576456611@github.com>
Message-ID: <SFR4-1c_zD5ZSTHLy7ttPFAhyE7VsfdS9HBggOYsYSc=.c0e325dc-147e-49c1-a436-8aee7d84b49f@github.com>

On Sat, 29 Mar 2025 07:53:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Please consider.
> 
> This patch adds a way to iterate all Klass structures in the loaded CDS archive (`SystemDictionaryShared::iterate_klasses_in_shared_archive(ConstKlassClosure* klassClosure, bool is_static);`). This uses the same mechanism that `PrintSharedArchiveAndExit` uses. I  need this mechanism for some future GC work.
> 
> Then, it re-implements `PrintSharedArchiveAndExit` to reuse the new iteration API instead. This also serves as a way to test, since there are pre-existing tests for this flag.
> 
> It also adds a new, rather basic, gtest.
> 
> Finally, the new gtest picked up a small pre-existing bug in the implementation of `PrintSharedArchiveAndExit`: it prints all array classes of all InstanceKlass inside the archive, for all dimensions, without testing if that array class is part of the archive. The array class may have been created dynamically, however. The patch fixes that.
> 
> ----
> 
> Testing:
> - I ensured that the output of `PrintSharedArchiveAndExit`, before and after this patch, are identical apart from the small error fix concerning array classes
> - I ran all runtime/cds tests on Linux x64
> - GHAs

@iklam could you take a look at this small change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24311#issuecomment-2764642142

From dholmes at openjdk.org  Mon Mar 31 01:34:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 01:34:46 GMT
Subject: RFR: 8352114: New test runtime/interpreter/CountBytecodesTest.java
 is failing
In-Reply-To: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
References: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
Message-ID: <SVlpWiw6DoDLqA4425ubQEf_fodTG6EXxeD0yR7EfXk=.ee8e771f-83f8-49a9-8c0f-f4e84d3c4c69@github.com>

On Thu, 27 Mar 2025 15:19:43 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> 8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

Looks good and passes our failing test run.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24281#pullrequestreview-2728104545

From jpai at openjdk.org  Mon Mar 31 02:12:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 31 Mar 2025 02:12:27 GMT
Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs
In-Reply-To: <R87zGYiWJVcjCXHyTk10xy9dtvC0BP6IG--vv08QGAI=.5086a8f4-94b5-4e08-bdd9-1110674facfc@github.com>
References: <QwzDtbLRcLqECqESR3gPrBx-7MVT_14RSb2D4oKL9GU=.a43e940d-a7c1-448d-b761-2e7858d540b1@github.com>
 <R87zGYiWJVcjCXHyTk10xy9dtvC0BP6IG--vv08QGAI=.5086a8f4-94b5-4e08-bdd9-1110674facfc@github.com>
Message-ID: <SfiEUDgIxD8QjqE0tE3dO-zzqw8t2o33lgnZcDndCF0=.52008f43-8db2-4014-ab9d-24b17bef3e26@github.com>

On Mon, 31 Mar 2025 01:28:47 GMT, tison <duke at openjdk.org> wrote:

>> Try to add clear type annotations.
>> 
>> Please let me know how this patch can be properly reviewed >_<
>
> retest?

Hello @tisonkun, is there an issue created for this? https://bugs.openjdk.org/browse/JDK-8304674 against which this PR is linked is for something else. The PR description too isn't clear what this change is about.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2764925445

From duke at openjdk.org  Mon Mar 31 02:46:10 2025
From: duke at openjdk.org (tison)
Date: Mon, 31 Mar 2025 02:46:10 GMT
Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs
In-Reply-To: <SfiEUDgIxD8QjqE0tE3dO-zzqw8t2o33lgnZcDndCF0=.52008f43-8db2-4014-ab9d-24b17bef3e26@github.com>
References: <QwzDtbLRcLqECqESR3gPrBx-7MVT_14RSb2D4oKL9GU=.a43e940d-a7c1-448d-b761-2e7858d540b1@github.com>
 <R87zGYiWJVcjCXHyTk10xy9dtvC0BP6IG--vv08QGAI=.5086a8f4-94b5-4e08-bdd9-1110674facfc@github.com>
 <SfiEUDgIxD8QjqE0tE3dO-zzqw8t2o33lgnZcDndCF0=.52008f43-8db2-4014-ab9d-24b17bef3e26@github.com>
Message-ID: <bN_f8H0x-KxHCQss51F7z2HufNfdxMmrt7eeGpR3Dk0=.bfbb377e-5d82-4324-bb06-02effd27702b@github.com>

On Mon, 31 Mar 2025 02:08:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> retest?
>
> Hello @tisonkun, is there an issue created for this? https://bugs.openjdk.org/browse/JDK-8304674 against which this PR is linked is for something else. The PR description too isn't clear what this change is about.

@jaikiran not yet. How can I create an issue for this PR? I don't find some instructions :/

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2764963574

From david.holmes at oracle.com  Mon Mar 31 02:53:55 2025
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 31 Mar 2025 12:53:55 +1000
Subject: RFR: 8304674: AttachCurrentThread 's argument is JavaVMAttachArgs
In-Reply-To: <bN_f8H0x-KxHCQss51F7z2HufNfdxMmrt7eeGpR3Dk0=.bfbb377e-5d82-4324-bb06-02effd27702b@github.com>
References: <QwzDtbLRcLqECqESR3gPrBx-7MVT_14RSb2D4oKL9GU=.a43e940d-a7c1-448d-b761-2e7858d540b1@github.com>
 <R87zGYiWJVcjCXHyTk10xy9dtvC0BP6IG--vv08QGAI=.5086a8f4-94b5-4e08-bdd9-1110674facfc@github.com>
 <SfiEUDgIxD8QjqE0tE3dO-zzqw8t2o33lgnZcDndCF0=.52008f43-8db2-4014-ab9d-24b17bef3e26@github.com>
 <bN_f8H0x-KxHCQss51F7z2HufNfdxMmrt7eeGpR3Dk0=.bfbb377e-5d82-4324-bb06-02effd27702b@github.com>
Message-ID: <df17939d-fc60-48af-a4d5-9b82e04a1081@oracle.com>

Hi,

This change was already proposed (by myself):

https://bugs.openjdk.org/browse/JDK-8289253

but it cannot be done as it will break source compatibility.

We will just have to live with this historical oddity.

Cheers,
David

On 31/03/2025 12:46 pm, tison wrote:
> On Mon, 31 Mar 2025 02:08:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
> 
>>> retest?
>>
>> Hello @tisonkun, is there an issue created for this? https://bugs.openjdk.org/browse/JDK-8304674 against which this PR is linked is for something else. The PR description too isn't clear what this change is about.
> 
> @jaikiran not yet. How can I create an issue for this PR? I don't find some instructions :/
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/21658#issuecomment-2764963574


From dholmes at openjdk.org  Mon Mar 31 04:51:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 04:51:21 GMT
Subject: RFR: 8353190: Use "/native" Run Option for TestAvailableProcessors
 Execution
In-Reply-To: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
References: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
Message-ID: <jnT48m90-yrQnKS8FkRzMcOwrFofFl90IDAN8WnA7Sw=.9dfec2ee-ef72-47e6-95e2-c8cc3c2af4e2@github.com>

On Wed, 26 Feb 2025 14:17:31 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

> Currently, the test executes the program using `test.nativepath`, but it relies on path resolution. I propose following standard conventions in this case and running the test with the `/native` option instead.
> 
> With this change:
> - Path resolution is no longer required.
> - If `nativepath` is not specified at runtime, a standard error message will be printed to the console.
> 
> This improves consistency and simplifies the test execution process.
> 
> I kindly ask the original author of the test @swesonga and those who reviewed the original pull request  #17576 for this test to take a look at this PR: @jdksjolen and @dholmes

test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 34:

> 32:  * @library /test/lib
> 33:  * @compile GetAvailableProcessors.java
> 34:  * @run testng/othervm/native --enable-native-access=ALL-UNNAMED TestAvailableProcessors

It is a good catch that this test needs to declare it needs the native image to have been built - though `native` is not listed as a valid sub-option for `testng`. 

Why do you need the `--enable-native-access` here?

test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 171:

> 169:     @Test
> 170:     private static void testProcessorAvailability() throws IOException {
> 171:         // Launch "<nativepath>/GetProcessorInfo.exe" to gather processor counts

How does this launch the executable in the way you describe? I am not aware that the `native` directive puts the `<nativepath>` directory into the PATH. From what I can see from an existing jtr file the PATH used for executing the test is unchanged.  ??

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23803#discussion_r2020368426
PR Review Comment: https://git.openjdk.org/jdk/pull/23803#discussion_r2020369071

From iklam at openjdk.org  Mon Mar 31 05:21:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Mar 2025 05:21:15 GMT
Subject: RFR: 8352768: CDS test MethodHandleTest.java failed in -Xcomp mode
Message-ID: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>

The failure happens because `java/lang/invoke/VarHandleGuards` is missing from the list of AOT-initialized classes. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8352768) for details.

-------------

Commit messages:
 - 8352768: CDS test MethodHandleTest.java failed in -Xcomp mode

Changes: https://git.openjdk.org/jdk/pull/24321/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24321&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352768
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24321.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24321/head:pull/24321

PR: https://git.openjdk.org/jdk/pull/24321

From dholmes at openjdk.org  Mon Mar 31 06:33:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 06:33:35 GMT
Subject: RFR: 8352768: CDS test MethodHandleTest.java failed in -Xcomp mode
In-Reply-To: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
References: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
Message-ID: <F0B1s486Dlp48qqUbPjDwoKepS7ARatkJ91-qS1Yjuk=.e3811faa-635a-4360-9764-3bfa018f4950@github.com>

On Mon, 31 Mar 2025 05:15:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The failure happens because `java/lang/invoke/VarHandleGuards` is missing from the list of AOT-initialized classes. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8352768) for details.

Okay - seems trivial. Ship it!

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24321#pullrequestreview-2728336254

From mdoerr at openjdk.org  Mon Mar 31 08:39:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 31 Mar 2025 08:39:22 GMT
Subject: RFR: 8352114: New test runtime/interpreter/CountBytecodesTest.java
 is failing
In-Reply-To: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
References: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
Message-ID: <r8M-bJZL9C14WgXEC1J4lum3G_WsnyjlBK7WqQsFgZo=.8218b991-3ebb-466f-b753-227e53999db3@github.com>

On Thu, 27 Mar 2025 15:19:43 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> 8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24281#pullrequestreview-2728569386

From duke at openjdk.org  Mon Mar 31 08:53:08 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 31 Mar 2025 08:53:08 GMT
Subject: RFR: 8352114: New test runtime/interpreter/CountBytecodesTest.java
 is failing
In-Reply-To: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
References: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
Message-ID: <CdlTQ2y0C_PddCp07xt2ta3Ok59SGtkMJLxKr685IfE=.5c7e5456-119e-4b11-abd4-c017f9eddb64@github.com>

On Thu, 27 Mar 2025 15:19:43 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> 8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

Thank you for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24281#issuecomment-2765563952

From duke at openjdk.org  Mon Mar 31 08:53:09 2025
From: duke at openjdk.org (duke)
Date: Mon, 31 Mar 2025 08:53:09 GMT
Subject: RFR: 8352114: New test runtime/interpreter/CountBytecodesTest.java
 is failing
In-Reply-To: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
References: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
Message-ID: <tnrfuIKBTF2bPEYk00RsXCIUlXb2mpqshoxYdBmNJ6I=.8547ff2c-a41e-47b4-b026-2011ca3d1d9f@github.com>

On Thu, 27 Mar 2025 15:19:43 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> 8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

@dbriemann 
Your change (at version a5c6ece15cc846a007336def0beb438535191dea) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24281#issuecomment-2765565681

From shade at openjdk.org  Mon Mar 31 08:57:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 31 Mar 2025 08:57:12 GMT
Subject: RFR: 8352768: CDS test MethodHandleTest.java failed in -Xcomp mode
In-Reply-To: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
References: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
Message-ID: <jwld4JL8SUIGDhc2qbvNvdeu9D8-_YbwyiaRqH--IZo=.9ed9d5e5-24bc-4237-a2f6-80801c460a66@github.com>

On Mon, 31 Mar 2025 05:15:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The failure happens because `java/lang/invoke/VarHandleGuards` is missing from the list of AOT-initialized classes. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8352768) for details.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/24321#pullrequestreview-2728610409

From duke at openjdk.org  Mon Mar 31 08:57:16 2025
From: duke at openjdk.org (David Linus Briemann)
Date: Mon, 31 Mar 2025 08:57:16 GMT
Subject: Integrated: 8352114: New test
 runtime/interpreter/CountBytecodesTest.java is failing
In-Reply-To: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
References: <EnNQPtRjRlpwAS8rq9rlnpFTQwcaSSLIYPnnBaVkTBg=.1233e693-924c-4ad2-ab37-4410145dfab8@github.com>
Message-ID: <jqcRf29GQDDIj2VoG8t-i16K7k_bMma9QPzpq9CZCnc=.f06c8a64-e81d-48e7-a1ea-6a3bf86f8d6c@github.com>

On Thu, 27 Mar 2025 15:19:43 GMT, David Linus Briemann <duke at openjdk.org> wrote:

> 8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

This pull request has now been integrated.

Changeset: 79d0c94b
Author:    David Linus Briemann <david.briemann at sap.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79d0c94b5c915b4be32e5febf90a148e20f3c112
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8352114: New test runtime/interpreter/CountBytecodesTest.java is failing

Reviewed-by: dholmes, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/24281

From mdoerr at openjdk.org  Mon Mar 31 10:21:20 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 31 Mar 2025 10:21:20 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
 [v3]
In-Reply-To: <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
 <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
Message-ID: <ydGbLAEY5w_ctvhNUo3MRCBlLnpR_nKt_Ebl8bgt9s4=.172711d4-cc4a-4d4c-9164-519e8060b7b6@github.com>

On Fri, 28 Mar 2025 09:01:26 GMT, Varada M <varadam at openjdk.org> wrote:

>> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
>> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
>> 
>> tier1, tier2 and tier3 testing is successful with fastdebug level
>> 
>> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)
>
> Varada M has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated copyright header
>  - removed StreamingOutputTest.java from problem list

I think this is good. @JoKern65: Do you also want to review it?

src/hotspot/os/aix/attachListener_aix.cpp line 119:

> 117:   void close() {
> 118:     if (opened()) {
> 119:       ::shutdown(_socket, 2);

If there is no macro like `SHUT_RDWR` available, maybe add it as a comment?

src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 125:

> 123:              } finally {
> 124:                  close(s);
> 125:              }

Indentation is off by 1 in this hunk.

src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 196:

> 194:          }
> 195:      }
> 196: 

Same here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/24177#pullrequestreview-2728824060
PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2020765326
PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2020767818
PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2020768721

From jsjolen at openjdk.org  Mon Mar 31 11:39:21 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 31 Mar 2025 11:39:21 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v2]
In-Reply-To: <SOHQgPFIQSVbOrp3EagaPuCJP-lgncn_L1kYr3RdM60=.706cef5f-3f96-4473-a684-7c8b11dfb229@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
 <SOHQgPFIQSVbOrp3EagaPuCJP-lgncn_L1kYr3RdM60=.706cef5f-3f96-4473-a684-7c8b11dfb229@github.com>
Message-ID: <Kwm-cWsQIWd8R2-wW9rbRML_2QxielnEfFIKUaNTLSA=.fa08ce59-03ea-4432-981d-f02e31807905@github.com>

On Fri, 28 Mar 2025 14:33:55 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
>> 
>> proposed:
>> 
>> time:72,642,827[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> existing code:
>> 
>> time:73,085,446[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
>> 
>> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
>> 
>> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
>> 
>> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.
>
> Gerard Ziemski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8301404
>  - work
>  - work
>  - work
>  - work
>  - work:
>  - work
>  - work
>  - work
>  - work
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/d9f39f91...01470b34

Hi Gerard!

Does the split into `pre_` and `post_` alloc really help with legibility when reading the code? To me, it doesn't.

What I mean by that is: If I read `os::malloc` for the first time, then `os::pre_alloc` and `os::post_alloc` just looks like magic to me. They don't actually say what they do. If I want to understand `os::malloc` I have to go into both `pre_` and `post_` alloc and read the code anyway. Then, I also have the issue that I need to remember exactly what the arguments were for those two functions, because the behavior changes depending on what's passed in.

We essentially have *two* functions for both pre and post, actually. Here're our pre calls:

```c++
680:  size_t outer_size = os::pre_alloc(&rc, nullptr, size, true, mem_tag);
712:  size_t outer_size = os::pre_alloc(&rc, memblock, size, false, mem_tag);


And here are our post calls:

```c++
693:  return post_alloc(outer_ptr, size, 0, mem_tag, stack);
754:    rc = post_alloc(outer_ptr, size, old_size, mem_tag, stack);


If we were to partially apply these, we have:

```c++
680:  size_t outer_size = os::pre_alloc_nullptr_true(&rc, mem_tag);
712:  size_t outer_size = os::pre_alloc_memblock_false(&rc, mem_tag);


And we have:

```c++
693:  return post_alloc_0(outer_ptr, size, mem_tag, stack);
754:    rc = post_alloc_old_size(outer_ptr, size, mem_tag, stack);


This, in combination with the non-obvious names, makes this harder to understand for me. It also doesn't actually save any lines of code.

Cheers,
Johan

-------------

PR Review: https://git.openjdk.org/jdk/pull/24189#pullrequestreview-2729012535

From dholmes at openjdk.org  Mon Mar 31 12:11:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 12:11:30 GMT
Subject: RFR: 8353190: Use "/native" Run Option for TestAvailableProcessors
 Execution
In-Reply-To: <jnT48m90-yrQnKS8FkRzMcOwrFofFl90IDAN8WnA7Sw=.9dfec2ee-ef72-47e6-95e2-c8cc3c2af4e2@github.com>
References: <cBmIXbO8UEgwkSLfhY7U0JCYOjpsnvLa5p7AHMOC5u4=.2be7cc78-c2e3-402e-aac3-4d350ad3d3a4@github.com>
 <jnT48m90-yrQnKS8FkRzMcOwrFofFl90IDAN8WnA7Sw=.9dfec2ee-ef72-47e6-95e2-c8cc3c2af4e2@github.com>
Message-ID: <XRncxZlaxEgv6zvpP831QCoZxWGN3jU-7fbBRY1NhSY=.04fe78e4-6275-403e-bc52-d9b3ccecc9df@github.com>

On Mon, 31 Mar 2025 03:18:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Currently, the test executes the program using `test.nativepath`, but it relies on path resolution. I propose following standard conventions in this case and running the test with the `/native` option instead.
>> 
>> With this change:
>> - Path resolution is no longer required.
>> - If `nativepath` is not specified at runtime, a standard error message will be printed to the console.
>> 
>> This improves consistency and simplifies the test execution process.
>> 
>> I kindly ask the original author of the test @swesonga and those who reviewed the original pull request  #17576 for this test to take a look at this PR: @jdksjolen and @dholmes
>
> test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 171:
> 
>> 169:     @Test
>> 170:     private static void testProcessorAvailability() throws IOException {
>> 171:         // Launch "<nativepath>/GetProcessorInfo.exe" to gather processor counts
> 
> How does this launch the executable in the way you describe? I am not aware that the `native` directive puts the `<nativepath>` directory into the PATH. From what I can see from an existing jtr file the PATH used for executing the test is unchanged.  ??

I discovered that the PATH is only updated when `othervm` and `native` appear together.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23803#discussion_r2020918509

From gziemski at openjdk.org  Mon Mar 31 15:36:47 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 31 Mar 2025 15:36:47 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v3]
In-Reply-To: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
Message-ID: <5mpuIQ89UAWL4UAPBz9Q3gHwRxNB49dqDeSgTglJ6xg=.604fa12f-dc7e-4de1-957b-6d9ff9b8589b@github.com>

> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
> 
> proposed:
> 
> time:72,642,827[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> existing code:
> 
> time:73,085,446[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
> 
> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
> 
> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
> 
> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  use better names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24189/files
  - new: https://git.openjdk.org/jdk/pull/24189/files/01470b34..5629932c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=01-02

  Stats: 24 lines in 2 files changed: 4 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24189/head:pull/24189

PR: https://git.openjdk.org/jdk/pull/24189

From gziemski at openjdk.org  Mon Mar 31 15:43:16 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 31 Mar 2025 15:43:16 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v3]
In-Reply-To: <5mpuIQ89UAWL4UAPBz9Q3gHwRxNB49dqDeSgTglJ6xg=.604fa12f-dc7e-4de1-957b-6d9ff9b8589b@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
 <5mpuIQ89UAWL4UAPBz9Q3gHwRxNB49dqDeSgTglJ6xg=.604fa12f-dc7e-4de1-957b-6d9ff9b8589b@github.com>
Message-ID: <Ad0QHMj4bCsXWTKD4RdYzMpOiC0oS9YR6CdsEDihYQM=.65d56e93-cdf6-476e-93dd-018523495207@github.com>

On Mon, 31 Mar 2025 15:36:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
>> 
>> proposed:
>> 
>> time:72,642,827[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> existing code:
>> 
>> time:73,085,446[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
>> 
>> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
>> 
>> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
>> 
>> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use better names

Thank you for the review Johan,

Instead of generic `pre_alloc`, `post_alloc` names, which explain nothing I am now using `pre_init_and_check_size` and `record_and_clear_bits`

I think that makes the code more readable and explains their functionality without having to read their implementation, unless you are very curious or need to.

We now use `ptr` instead of the old `rc`, which I have no idea what it stood for.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2766626116

From iklam at openjdk.org  Mon Mar 31 15:44:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Mar 2025 15:44:36 GMT
Subject: RFR: 8353225: Add a way to iterate Klass inside the loaded CDS
 archive
In-Reply-To: <brAzvbymuYfkdhJv6ldG9_ZPvq-GBvXhoRNs1ELcqCQ=.87d40500-de5a-4690-bd78-f8c576456611@github.com>
References: <brAzvbymuYfkdhJv6ldG9_ZPvq-GBvXhoRNs1ELcqCQ=.87d40500-de5a-4690-bd78-f8c576456611@github.com>
Message-ID: <5SQE8CXHZkXpbYd006rb3kM7244sq0g3tGPFK5IN0KY=.65290934-acaf-4cce-847d-a53d1a09d073@github.com>

On Sat, 29 Mar 2025 07:53:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Please consider.
> 
> This patch adds a way to iterate all Klass structures in the loaded CDS archive (`SystemDictionaryShared::iterate_klasses_in_shared_archive(ConstKlassClosure* klassClosure, bool is_static);`). This uses the same mechanism that `PrintSharedArchiveAndExit` uses. I  need this mechanism for some future GC work.
> 
> Then, it re-implements `PrintSharedArchiveAndExit` to reuse the new iteration API instead. This also serves as a way to test, since there are pre-existing tests for this flag.
> 
> It also adds a new, rather basic, gtest.
> 
> Finally, the new gtest picked up a small pre-existing bug in the implementation of `PrintSharedArchiveAndExit`: it prints all array classes of all InstanceKlass inside the archive, for all dimensions, without testing if that array class is part of the archive. The array class may have been created dynamically, however. The patch fixes that.
> 
> ----
> 
> Testing:
> - I ensured that the output of `PrintSharedArchiveAndExit`, before and after this patch, are identical apart from the small error fix concerning array classes
> - I ran all runtime/cds tests on Linux x64
> - GHAs

src/hotspot/share/cds/lambdaProxyClassDictionary.cpp line 93:

> 91:     while (k != nullptr) {
> 92:       cl->do_klass(k);
> 93:       k = k->next_link();

When do you plan to use this API? `k->next_link()` will change if `k` has been loaded in runtime, so you can no longer use it to find other archived lambda proxy classes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24311#discussion_r2021290384

From gziemski at openjdk.org  Mon Mar 31 15:47:31 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 31 Mar 2025 15:47:31 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v3]
In-Reply-To: <5mpuIQ89UAWL4UAPBz9Q3gHwRxNB49dqDeSgTglJ6xg=.604fa12f-dc7e-4de1-957b-6d9ff9b8589b@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
 <5mpuIQ89UAWL4UAPBz9Q3gHwRxNB49dqDeSgTglJ6xg=.604fa12f-dc7e-4de1-957b-6d9ff9b8589b@github.com>
Message-ID: <znyUVlm6quYwuSCM91OP7elcfVrDo3Pyk_UUhw-oFho=.9801e225-6996-4041-84a4-26f38ec21844@github.com>

On Mon, 31 Mar 2025 15:36:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
>> 
>> proposed:
>> 
>> time:72,642,827[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> existing code:
>> 
>> time:73,085,446[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
>> 
>> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
>> 
>> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
>> 
>> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use better names

To me it never was about saving the lines of code, which it still does - I will calculate that in a bit.

The malloc and realloc are so similar that I in fact what to know exactly where the differences were and saw the opportunity to understand and clean it up.

I personally think that we have achieved that here. I still think we can do more here, it's not perfect, but for now I am personally happy with this refactoring.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2766640712

From gziemski at openjdk.org  Mon Mar 31 15:54:33 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 31 Mar 2025 15:54:33 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v4]
In-Reply-To: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
Message-ID: <WKjRULtbcu-94e2TmsT3GuqIRuUsq5BK-v7RksMvugo=.69aa16f9-d961-4550-aa99-4c2d4ae73ad3@github.com>

> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
> 
> proposed:
> 
> time:72,642,827[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> existing code:
> 
> time:73,085,446[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
> 
> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
> 
> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
> 
> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  white space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24189/files
  - new: https://git.openjdk.org/jdk/pull/24189/files/5629932c..127b4d7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24189/head:pull/24189

PR: https://git.openjdk.org/jdk/pull/24189

From vlivanov at openjdk.org  Mon Mar 31 16:11:21 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 31 Mar 2025 16:11:21 GMT
Subject: RFR: 8352768: CDS test MethodHandleTest.java failed in -Xcomp mode
In-Reply-To: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
References: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
Message-ID: <Xw31CilI5JH01ASeGyhTruZioRxwfQrUoXbk8vzr8LU=.1cb8242b-20dd-4b97-b08e-a9024de8629a@github.com>

On Mon, 31 Mar 2025 05:15:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The failure happens because `java/lang/invoke/VarHandleGuards` is missing from the list of AOT-initialized classes. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8352768) for details.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24321#pullrequestreview-2729809401

From gziemski at openjdk.org  Mon Mar 31 16:11:21 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 31 Mar 2025 16:11:21 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v4]
In-Reply-To: <WKjRULtbcu-94e2TmsT3GuqIRuUsq5BK-v7RksMvugo=.69aa16f9-d961-4550-aa99-4c2d4ae73ad3@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
 <WKjRULtbcu-94e2TmsT3GuqIRuUsq5BK-v7RksMvugo=.69aa16f9-d961-4550-aa99-4c2d4ae73ad3@github.com>
Message-ID: <A05hcGzD2B14wfxTNJqhA9R3PJi1E-H-xKJSyO9wKmM=.0f274596-837d-4687-b7d1-86142a56edc4@github.com>

On Mon, 31 Mar 2025 15:54:33 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
>> 
>> proposed:
>> 
>> time:72,642,827[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> existing code:
>> 
>> time:73,085,446[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
>> 
>> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
>> 
>> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
>> 
>> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   white space

@stefank To answer Stefan's question from Slack channel - `NMTPreInit::handle_realloc()` takes handle and returns bool, so I was trying to stay consistent, which is why `os::pre_init_and_check_size()` takes handle and returns size.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2766711623

From coleenp at openjdk.org  Mon Mar 31 16:39:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 31 Mar 2025 16:39:07 GMT
Subject: RFR: 8351654: Agent transformer bytecodes should be verified
Message-ID: <lRs9T0aaLgl-_abHM-kWvlvxYiTTrPnRw041hkIgHXk=.9d051399-f431-4ec8-b25f-a13934497565@github.com>

This change enables verification for classes provided with the JVMTI ClassFileLoadHook.  The test was adapted from the one sent by the submitter @rjernst.
Tested with tier1-4.

-------------

Commit messages:
 - 8351654: Agent transformer bytecodes should be verified

Changes: https://git.openjdk.org/jdk/pull/24333/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24333&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351654
  Stats: 305 lines in 7 files changed: 296 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/24333.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24333/head:pull/24333

PR: https://git.openjdk.org/jdk/pull/24333

From stefank at openjdk.org  Mon Mar 31 17:00:13 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 31 Mar 2025 17:00:13 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v4]
In-Reply-To: <A05hcGzD2B14wfxTNJqhA9R3PJi1E-H-xKJSyO9wKmM=.0f274596-837d-4687-b7d1-86142a56edc4@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
 <WKjRULtbcu-94e2TmsT3GuqIRuUsq5BK-v7RksMvugo=.69aa16f9-d961-4550-aa99-4c2d4ae73ad3@github.com>
 <A05hcGzD2B14wfxTNJqhA9R3PJi1E-H-xKJSyO9wKmM=.0f274596-837d-4687-b7d1-86142a56edc4@github.com>
Message-ID: <EwgRm6mwL_kbuA7p-qrAGoYdl_5EtfjizPGtsY2KtI0=.016afba3-a2a0-4c41-841c-bd20a5474163@github.com>

On Mon, 31 Mar 2025 16:08:20 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> @stefank To answer Stefan's question from Slack channel - `NMTPreInit::handle_realloc()` takes handle and returns bool, so I was trying to stay consistent, which is why `os::pre_init_and_check_size()` takes handle and returns size.

My comment was along the lines that I thought it would probably be clearer if os::pre_alloc returned a pointer and let the returned size_t be an output parameter instead. Given that the function allocates memory, I'm still not convinced that returning size_t is beneficial for the readability here.

I posted that comment in the Slack channel because couldn't prioritize looking at this today, but wanted to give a quick answer to the direct ping in that channel.

Now that you got my attention I think that the rename to `pre_init_and_check_size` lost the hint that it was performing "pre init *allocation*". The "*and* check size" is also an indication that the function does two different, unrelated(?) things. I would need to look closer to give suggestions for cleanups.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2766830287

From gziemski at openjdk.org  Mon Mar 31 17:31:57 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 31 Mar 2025 17:31:57 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v5]
In-Reply-To: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
Message-ID: <c18nbznw6sp4uMRHt5NlBLbKuJ2wQMQo-XA168dEOhM=.13e081fc-feb1-482a-a02d-76e73576762e@github.com>

> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
> 
> proposed:
> 
> time:72,642,827[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> existing code:
> 
> time:73,085,446[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
> 
> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
> 
> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
> 
> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  tighten up common code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24189/files
  - new: https://git.openjdk.org/jdk/pull/24189/files/127b4d7b..7fbc1b52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=03-04

  Stats: 12 lines in 1 file changed: 0 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/24189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24189/head:pull/24189

PR: https://git.openjdk.org/jdk/pull/24189

From gziemski at openjdk.org  Mon Mar 31 17:36:14 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 31 Mar 2025 17:36:14 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v4]
In-Reply-To: <EwgRm6mwL_kbuA7p-qrAGoYdl_5EtfjizPGtsY2KtI0=.016afba3-a2a0-4c41-841c-bd20a5474163@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
 <WKjRULtbcu-94e2TmsT3GuqIRuUsq5BK-v7RksMvugo=.69aa16f9-d961-4550-aa99-4c2d4ae73ad3@github.com>
 <A05hcGzD2B14wfxTNJqhA9R3PJi1E-H-xKJSyO9wKmM=.0f274596-837d-4687-b7d1-86142a56edc4@github.com>
 <EwgRm6mwL_kbuA7p-qrAGoYdl_5EtfjizPGtsY2KtI0=.016afba3-a2a0-4c41-841c-bd20a5474163@github.com>
Message-ID: <v8eqy5dkLwa37k_RgntMunZqM-nOgIh0spM_2jOmwCI=.7f4ef9e5-0966-4a8c-91f2-30d0e9781ea8@github.com>

On Mon, 31 Mar 2025 16:57:36 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> @stefank To answer Stefan's question from Slack channel - `NMTPreInit::handle_realloc()` takes handle and returns bool, so I was trying to stay consistent, which is why `os::pre_init_and_check_size()` takes handle and returns size.
>
>> @stefank To answer Stefan's question from Slack channel - `NMTPreInit::handle_realloc()` takes handle and returns bool, so I was trying to stay consistent, which is why `os::pre_init_and_check_size()` takes handle and returns size.
> 
> My comment was along the lines that I thought it would probably be clearer if os::pre_alloc returned a pointer and let the returned size_t be an output parameter instead. Given that the function allocates memory, I'm still not convinced that returning size_t is beneficial for the readability here.
> 
> I posted that comment in the Slack channel because couldn't prioritize looking at this today, but wanted to give a quick answer to the direct ping in that channel.
> 
> Now that you got my attention I think that the rename to `pre_init_and_check_size` lost the hint that it was performing "pre init *allocation*". The "*and* check size" is also an indication that the function does two different, unrelated(?) things. I would need to look closer to give suggestions for cleanups.

> > @stefank To answer Stefan's question from Slack channel - `NMTPreInit::handle_realloc()` takes handle and returns bool, so I was trying to stay consistent, which is why `os::pre_init_and_check_size()` takes handle and returns size.
> 
> My comment was along the lines that I thought it would probably be clearer if os::pre_alloc returned a pointer and let the returned size_t be an output parameter instead. Given that the function allocates memory, I'm still not convinced that returning size_t is beneficial for the readability here.
> 
> I posted that comment in the Slack channel because couldn't prioritize looking at this today, but wanted to give a quick answer to the direct ping in that channel.
> 
> Now that you got my attention I think that the rename to `pre_init_and_check_size` lost the hint that it was performing "pre init _allocation_". The "_and_ check size" is also an indication that the function does two different, unrelated(?) things. I would need to look closer to give suggestions for cleanups.

I see your point, but then we should touch `NMTPreInit::handle_realloc()` as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2766910380

From clanger at openjdk.org  Mon Mar 31 18:58:20 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 31 Mar 2025 18:58:20 GMT
Subject: RFR: 8352046: Test testEcoFriendly() in jdk tools launcher
 ExecutionEnvironment.java for AIX and Linux/musl is brittle [v6]
In-Reply-To: <pi7W0uNdHZUr-LPysc5qg_JluSTMgx5gC4HP4bBNgwM=.b23e2eb1-a4f2-4be5-b93a-5e66feca9a70@github.com>
References: <Ff0XheeagvoJIB3AKLyqUt2JSZO3O3ojAu7OJnCq1Nc=.eecd4935-b700-4f66-81db-ae999e0ba437@github.com>
 <pi7W0uNdHZUr-LPysc5qg_JluSTMgx5gC4HP4bBNgwM=.b23e2eb1-a4f2-4be5-b93a-5e66feca9a70@github.com>
Message-ID: <9VUZmQh8krQ7ADVsygmQKjKbsOX8WbTCy_f_YVk_x4Y=.d07086e2-8eba-4874-83c8-b7d9e922ada3@github.com>

On Fri, 28 Mar 2025 17:04:03 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
>> 
>> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
>> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
>> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
>> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
>> 
>> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
>> So my proposal is to skip this sub test for aix and musl.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add symlink comment again, but without solaris

Still looks good and passes on all platforms in SAP nightlies.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24055#pullrequestreview-2730245425

From iklam at openjdk.org  Mon Mar 31 20:30:17 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Mar 2025 20:30:17 GMT
Subject: RFR: 8352768: CDS test MethodHandleTest.java failed in -Xcomp mode
In-Reply-To: <F0B1s486Dlp48qqUbPjDwoKepS7ARatkJ91-qS1Yjuk=.e3811faa-635a-4360-9764-3bfa018f4950@github.com>
References: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
 <F0B1s486Dlp48qqUbPjDwoKepS7ARatkJ91-qS1Yjuk=.e3811faa-635a-4360-9764-3bfa018f4950@github.com>
Message-ID: <_3JNfFdy-C_9WuJOhzx_iQs-YEpK5pnvttea7S2E5D4=.4877d5d0-184d-46be-8e2b-9d27bcb8e377@github.com>

On Mon, 31 Mar 2025 06:31:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The failure happens because `java/lang/invoke/VarHandleGuards` is missing from the list of AOT-initialized classes. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8352768) for details.
>
> Okay - seems trivial. Ship it!
> 
> Thanks

Thanks @dholmes-ora @shipilev @iwanowww for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24321#issuecomment-2767324419

From coleenp at openjdk.org  Mon Mar 31 20:36:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 31 Mar 2025 20:36:09 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state [v2]
In-Reply-To: <NQ8P7WHCn3AgNJxy8rCHrlVM6ul1Ct_dzuhFw-7AUOA=.cf22e030-8812-4f42-999f-caf50613e384@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <NQ8P7WHCn3AgNJxy8rCHrlVM6ul1Ct_dzuhFw-7AUOA=.cf22e030-8812-4f42-999f-caf50613e384@github.com>
Message-ID: <0_ZovcLnGbAMobVab2ZEQYcABqFEEuCH4z7ovOJMbY8=.e9c33f7e-0aa7-491b-930f-9f3ac7604748@github.com>

On Thu, 27 Mar 2025 14:32:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
>> 
>> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move CollectClassesForLinking inside while loop to see classes loaded as side effect of linking
>  - @coleenp comments - use ClassLoaderDataGraph::loaded_classes_do_keepalive()

One small comment, but looks good!

src/hotspot/share/cds/metaspaceShared.cpp line 690:

> 688: 
> 689: public:
> 690:   CollectClassesForLinking() {}

Do you need this empty constructor?  _mirrors is initialized by default initializer to a small array, or should you give this a length?

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24172#pullrequestreview-2730444367
PR Review Comment: https://git.openjdk.org/jdk/pull/24172#discussion_r2021727431

From gziemski at openjdk.org  Mon Mar 31 20:44:25 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 31 Mar 2025 20:44:25 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v6]
In-Reply-To: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
Message-ID: <jnZE896VOJ25KSt25JcDtJ6y9cEaXULlkvBCGtTyOy4=.14451828-1aa0-4e70-a3a7-934c4620c1bf@github.com>

> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
> 
> proposed:
> 
> time:72,642,827[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> existing code:
> 
> time:73,085,446[ns]
> [samples:807,804] [NMT headers:382,064]
> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
> 
> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
> 
> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
> 
> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  pass explicit mem_tag value, skip exec parameter when false

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24189/files
  - new: https://git.openjdk.org/jdk/pull/24189/files/7fbc1b52..c224bfeb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24189&range=04-05

  Stats: 32 lines in 18 files changed: 0 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/24189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24189/head:pull/24189

PR: https://git.openjdk.org/jdk/pull/24189

From iklam at openjdk.org  Mon Mar 31 20:46:22 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Mar 2025 20:46:22 GMT
Subject: Integrated: 8352768: CDS test MethodHandleTest.java failed in -Xcomp
 mode
In-Reply-To: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
References: <8IXdmGtzPmhcjkcGgJwmYT2XHF9dTWKXwZpsP62AQc8=.e55e799c-1765-401a-ac96-7b56613a1c6a@github.com>
Message-ID: <EO7h515Y9QV1mic3nPXLg3jjMJ0Mv1oXttAXnM5R6jQ=.566fa017-ee5f-4367-913b-3c8430a22866@github.com>

On Mon, 31 Mar 2025 05:15:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The failure happens because `java/lang/invoke/VarHandleGuards` is missing from the list of AOT-initialized classes. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8352768) for details.

This pull request has now been integrated.

Changeset: 5eee32d0
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5eee32d04b6f4c4bf0de78c295d6d6feab523ea3
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8352768: CDS test MethodHandleTest.java failed in -Xcomp mode

Reviewed-by: dholmes, shade, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/24321

From iklam at openjdk.org  Mon Mar 31 20:48:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Mar 2025 20:48:48 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state [v2]
In-Reply-To: <0_ZovcLnGbAMobVab2ZEQYcABqFEEuCH4z7ovOJMbY8=.e9c33f7e-0aa7-491b-930f-9f3ac7604748@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <NQ8P7WHCn3AgNJxy8rCHrlVM6ul1Ct_dzuhFw-7AUOA=.cf22e030-8812-4f42-999f-caf50613e384@github.com>
 <0_ZovcLnGbAMobVab2ZEQYcABqFEEuCH4z7ovOJMbY8=.e9c33f7e-0aa7-491b-930f-9f3ac7604748@github.com>
Message-ID: <UW-KrXQPealonIsqlIYGmIjWPXRcpBDHfIv45qnWHjc=.33fc7a64-c5cf-4a90-b132-1af6a552766d@github.com>

On Mon, 31 Mar 2025 20:32:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Move CollectClassesForLinking inside while loop to see classes loaded as side effect of linking
>>  - @coleenp comments - use ClassLoaderDataGraph::loaded_classes_do_keepalive()
>
> src/hotspot/share/cds/metaspaceShared.cpp line 690:
> 
>> 688: 
>> 689: public:
>> 690:   CollectClassesForLinking() {}
> 
> Do you need this empty constructor?  _mirrors is initialized by default initializer to a small array, or should you give this a length?

I've removed the default constructor. I'll leave `_mirrors` as is as this code is not performance critical and the expansion overhead would be negligible .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24172#discussion_r2021741417

From iklam at openjdk.org  Mon Mar 31 20:48:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Mar 2025 20:48:48 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state [v3]
In-Reply-To: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
Message-ID: <dtLhABW0ZH1jTwiaEdPrpl2GJjGpnGQopWT24htqalM=.8babd09f-ffca-4638-a6e3-f19ca99c7e6b@github.com>

> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
> 
> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Removed empty constructor, as the default constructor is already public

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/24172/files
  - new: https://git.openjdk.org/jdk/pull/24172/files/ae23a56d..45a52fee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24172&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24172&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24172/head:pull/24172

PR: https://git.openjdk.org/jdk/pull/24172

From stefank at openjdk.org  Mon Mar 31 20:49:11 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 31 Mar 2025 20:49:11 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v6]
In-Reply-To: <jnZE896VOJ25KSt25JcDtJ6y9cEaXULlkvBCGtTyOy4=.14451828-1aa0-4e70-a3a7-934c4620c1bf@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
 <jnZE896VOJ25KSt25JcDtJ6y9cEaXULlkvBCGtTyOy4=.14451828-1aa0-4e70-a3a7-934c4620c1bf@github.com>
Message-ID: <Xpjlf5GgdtOKw6tP0HsoI25_vdjcx4Dgqn23lZXxYiM=.96164cbb-9b3b-4937-b84e-55b0176ca5b0@github.com>

On Mon, 31 Mar 2025 20:44:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
>> 
>> proposed:
>> 
>> time:72,642,827[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> existing code:
>> 
>> time:73,085,446[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
>> 
>> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
>> 
>> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
>> 
>> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pass explicit mem_tag value, skip exec parameter when false

> [pass explicit mem_tag value, skip exec parameter when false](https://github.com/openjdk/jdk/pull/24189/commits/c224bfebab69e572aeacbffb86db51baa8ba8978)

I think this went to the wrong PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2767358562

From stefank at openjdk.org  Mon Mar 31 21:05:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 31 Mar 2025 21:05:37 GMT
Subject: RFR: 8301404: Factor out os::malloc with os::realloc common code, 
 so that we only have 1 code path [v6]
In-Reply-To: <jnZE896VOJ25KSt25JcDtJ6y9cEaXULlkvBCGtTyOy4=.14451828-1aa0-4e70-a3a7-934c4620c1bf@github.com>
References: <j9DfHdNZ-8T5zhPscO1NDuuN9yU4PbxtqW9BRlUVrpI=.60dd654d-f0bc-4cf9-a657-fc579ecc6a70@github.com>
 <jnZE896VOJ25KSt25JcDtJ6y9cEaXULlkvBCGtTyOy4=.14451828-1aa0-4e70-a3a7-934c4620c1bf@github.com>
Message-ID: <nBPaai9ob_5jErTzEh-ZJaBx7ls-W834skviAWsIW1c=.51fd0cd7-3583-45ec-8023-1b8a40698a5d@github.com>

On Mon, 31 Mar 2025 20:44:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is the 2nd time I am proposing this (controversial?) change, but this time I do have performance numbers, which indicate no change in speed (using NMTBenchmark from #23786):
>> 
>> proposed:
>> 
>> time:72,642,827[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> existing code:
>> 
>> time:73,085,446[ns]
>> [samples:807,804] [NMT headers:382,064]
>> [malloc#:588,703] [realloc#:12,462] [free#:206,639]
>> memory requested:57,274,288 bytes, allocated:69,004,800 bytes
>> malloc overhead:4,853,360 bytes [8.47%], NMT headers overhead:6,877,152 bytes [12.01%]
>> Note: the NMTBenchmark reports realloc(nullptr) as mallocs(), which is why both versions show the same count for mallocs/reallocs.
>> 
>> The performance is virtually the same where I sampled each test 30 times and took the best (the shortest).
>> 
>> This proposed change factors out the common code and simplifies both os::malloc and os::realloc. We were able to reduce malloc from 44 lines down to 8 (saving of 36 lines) and realloc from 84 to 55 (29 lines).
>> 
>> To me the most important part here is that we reduce the number of times that NMT has to interact with the native allocation code.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pass explicit mem_tag value, skip exec parameter when false

I took a deeper look at the proposed patch and I'm still not convinced that this is a net positive cleanup. The added shared code now contains new branches to sort out the difference between malloc and realloc.

FWIW, I poked around at the original code to see what it would look to go the other way. Push NMT-specific code deeper down so that the higher-level functions get clearer and maybe easier to maintain. If you want to take a look, I've a branch for that here:
https://github.com/openjdk/jdk/compare/master...stefank:jdk:24189_alternative

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24189#issuecomment-2767390978

From dholmes at openjdk.org  Mon Mar 31 21:35:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 21:35:22 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state [v3]
In-Reply-To: <dtLhABW0ZH1jTwiaEdPrpl2GJjGpnGQopWT24htqalM=.8babd09f-ffca-4638-a6e3-f19ca99c7e6b@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <dtLhABW0ZH1jTwiaEdPrpl2GJjGpnGQopWT24htqalM=.8babd09f-ffca-4638-a6e3-f19ca99c7e6b@github.com>
Message-ID: <YbO6sVJNd449L_C3dddCLngZtd8ivC2xodWCQPe6emY=.ac33bb32-f492-40bb-85cc-d8d3ab5f8818@github.com>

On Mon, 31 Mar 2025 20:48:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
>> 
>> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed empty constructor, as the default constructor is already public

Looks good. Thanks for the offline explanations about why this is a preferred way to walk the classes.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24172#pullrequestreview-2730552649

From cushon at openjdk.org  Mon Mar 31 21:39:34 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 31 Mar 2025 21:39:34 GMT
Subject: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe [v2]
In-Reply-To: <0Y8uHktq6uDbnT2Pydvzi0Ighxuvqw4Rajix5G9ZoAs=.cb0be1e7-594b-4886-8fed-a717e44e4e1f@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
 <VmpiFkcEOcruxC9BSd0xV0HYnR5QKjvMilyrr4Cc73Y=.b4536bf7-61e5-4a11-ba46-1017f19a0d10@github.com>
 <v596TlVCfNtjrGUEXtFItD4xTol9OIECCs2ABgsKUAw=.2ac68717-ed86-4700-afdd-b66e8c46fae1@github.com>
 <0Y8uHktq6uDbnT2Pydvzi0Ighxuvqw4Rajix5G9ZoAs=.cb0be1e7-594b-4886-8fed-a717e44e4e1f@github.com>
Message-ID: <cid95S4Z39Ry07OISaLiKflWJdTqiEmAs0FvIefHx8E=.4e4f0ae8-89a3-4eaa-a35d-fc99694ee0dd@github.com>

On Fri, 28 Mar 2025 09:26:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman Can you review this if this patch looks good in principle?
> 
> It needs confirmation that it doesn't break the build, I haven't looked into which parts of Liam's change weren't backed out. So if there are no build issues then it should be okay to integrate.

All of the functional changes from JDK-8331081 and the redo got backed out, the only thing that stayed was test coverage, so I wouldn't expect this to break anything today.

Are the microbenchmarks built by CI? They weren't when JDK-8331081 originally happened, which was what led to it getting backed out the first time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2767461270

From iklam at openjdk.org  Mon Mar 31 23:38:23 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Mar 2025 23:38:23 GMT
Subject: Integrated: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state
In-Reply-To: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
Message-ID: <p4yEb6CVNhwopB7bFljdK9OLkBXUkezEihu7mQlAqLw=.fdc3179f-9e6e-4598-a9ef-ea3c25c22369@github.com>

On Sat, 22 Mar 2025 04:39:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small fix for a crash that can be caused only with JNI `DefineClass()` calls, which can leave a class in the `allocated` state inside a `ClassLoaderData` when the class is in a prohibited package such as `java/foo`.
> 
> The bug was found when running the JCK with an AOT cache. I tried to write a jtreg regression test but it's not possible to use pure Java code to reproduce this condition -- attempts by Java code to define classes in a prohibited package will be blocked from entering the ClassFileParser.

This pull request has now been integrated.

Changeset: a83760a6
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a83760a6f204837b737b82801ee9eca2988317cf
Stats:     48 lines in 1 file changed: 17 ins; 17 del; 14 mod

8352092: -XX:AOTMode=record crashes with InstanceKlass in allocated state

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/24172

From iklam at openjdk.org  Mon Mar 31 23:38:23 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 31 Mar 2025 23:38:23 GMT
Subject: RFR: 8352092: -XX:AOTMode=record crashes with InstanceKlass in
 allocated state [v2]
In-Reply-To: <0_ZovcLnGbAMobVab2ZEQYcABqFEEuCH4z7ovOJMbY8=.e9c33f7e-0aa7-491b-930f-9f3ac7604748@github.com>
References: <fcYHLYRaGl4h8jjRT3SV4oz8nz_A49LVUf0ICHoUoJA=.8ac25a85-e6ea-4c44-9a44-f0618389c1de@github.com>
 <NQ8P7WHCn3AgNJxy8rCHrlVM6ul1Ct_dzuhFw-7AUOA=.cf22e030-8812-4f42-999f-caf50613e384@github.com>
 <0_ZovcLnGbAMobVab2ZEQYcABqFEEuCH4z7ovOJMbY8=.e9c33f7e-0aa7-491b-930f-9f3ac7604748@github.com>
Message-ID: <11xOJtjs3na8xIaa_jbK-SGu7hK3GjSVY342Ecj-4rY=.af6f7c36-e6c6-4644-b023-bdf949411f8e@github.com>

On Mon, 31 Mar 2025 20:33:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Move CollectClassesForLinking inside while loop to see classes loaded as side effect of linking
>>  - @coleenp comments - use ClassLoaderDataGraph::loaded_classes_do_keepalive()
>
> One small comment, but looks good!

Thanks @coleenp and @dholmes-ora for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24172#issuecomment-2767651051