From amitkumar at openjdk.org  Wed Jan  1 06:08:37 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 1 Jan 2025 06:08:37 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v4]
In-Reply-To: <NyBWsSdfXlu4YI_lYkuN-XU0wPP7VPhGY5IqBAPmQv8=.ac4e0727-2e27-4960-81a9-482a20b4410c@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <NyBWsSdfXlu4YI_lYkuN-XU0wPP7VPhGY5IqBAPmQv8=.ac4e0727-2e27-4960-81a9-482a20b4410c@github.com>
Message-ID: <8ZLXJHWH9KeWVerM_NCTlU_h-ySgd0cbhp2GvhboT5I=.1dbe18d7-1e04-42f4-b5ec-387bc644b198@github.com>

On Tue, 31 Dec 2024 10:41:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use guarantee(!CrashGCForDumpingJavaThread, "") to generate jvm crash

I think this will also fix the ubsan error I am getting with `runtime/ErrorHandling/TestDwarf.java` test case: 


 stderr: [/home/amit/ubsan/jdk/src/hotspot/share/runtime/frame.cpp:1167:8: runtime error: store to null pointer of type 'char'
    #0 0x3ff8e74c3af in frame::oops_do_internal(OopClosure*, NMethodClosure*, DerivedOopClosure*, DerivedPointerIterationMode, RegisterMap const*,          bool) const /home/amit/ubsan/jdk/src/hotspot/share/runtime/frame.cpp:1167
    #1 0x3ff8eda2523 in frame::oops_do(OopClosure*, NMethodClosure*, RegisterMap const*) /home/amit/ubsan/jdk/src/hotspot/share/runtime/frame.hpp:483
    #2 0x3ff8eda2523 in JavaThread::oops_do_frames(OopClosure*, NMethodClosure*) /home/amit/ubsan/jdk/src/hotspot/share/runtime/javaThread.cpp:1458
    #3 0x3ff901f1611 in Thread::oops_do(OopClosure*, NMethodClosure*) /home/amit/ubsan/jdk/src/hotspot/share/runtime/thread.cpp:447
    #4 0x3ff8edabbd1 in JavaThread::verify() /home/amit/ubsan/jdk/src/hotspot/share/runtime/javaThread.cpp:1622
    #5 0x3ff90233d9f in Threads::verify() /home/amit/ubsan/jdk/src/hotspot/share/runtime/threads.cpp:1489
    #6 0x3ff902bcc45 in Universe::verify(VerifyOption, char const*) /home/amit/ubsan/jdk/src/hotspot/share/memory/universe.cpp:1244
    #7 0x3ff904847ad in Universe::verify(char const*) /home/amit/ubsan/jdk/src/hotspot/share/memory/universe.hpp:348
    #8 0x3ff904847ad in Universe::verify() /home/amit/ubsan/jdk/src/hotspot/share/memory/universe.hpp:351
    #9 0x3ff904847ad in VMThread::run() /home/amit/ubsan/jdk/src/hotspot/share/runtime/vmThread.cpp:200
    #10 0x3ff901f2c99 in Thread::call_run() /home/amit/ubsan/jdk/src/hotspot/share/runtime/thread.cpp:232
    #11 0x3ff8fad890f in thread_native_entry /home/amit/ubsan/jdk/src/hotspot/os/linux/os_linux.cpp:860
    #12 0x3ff93496295 in start_thread nptl/pthread_create.c:442
    #13 0x3ff9350ff8d  (/lib/s390x-linux-gnu/libc.so.6+0x10ff8d)


Thanks @sendaoYan for looking into it.

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

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2566865070

From kbarrett at openjdk.org  Wed Jan  1 07:47:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 1 Jan 2025 07:47:48 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v4]
In-Reply-To: <NyBWsSdfXlu4YI_lYkuN-XU0wPP7VPhGY5IqBAPmQv8=.ac4e0727-2e27-4960-81a9-482a20b4410c@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <NyBWsSdfXlu4YI_lYkuN-XU0wPP7VPhGY5IqBAPmQv8=.ac4e0727-2e27-4960-81a9-482a20b4410c@github.com>
Message-ID: <ud1QlERp7cMhH6n-bEWlRTW-868orgyMaMF1C81y_QY=.6f294448-0aca-4692-8215-e7c512984c5a@github.com>

On Tue, 31 Dec 2024 10:41:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use guarantee(!CrashGCForDumpingJavaThread, "") to generate jvm crash

src/hotspot/share/runtime/frame.cpp line 1166:

> 1164:   // simulate GC crash here to dump java thread in error report
> 1165:   if (CrashGCForDumpingJavaThread) {
> 1166:     guarantee(!CrashGCForDumpingJavaThread, "");

The surrounding `if` is no longer needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900342411

From syan at openjdk.org  Thu Jan  2 02:43:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 2 Jan 2025 02:43:01 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v5]
In-Reply-To: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
Message-ID: <9Px9bo84N_mlfN_wh9lOavf4TeEtUCTLr588biaaEjw=.e0bea88a-4290-45c8-8e07-4a800bf7a7da@github.com>

> Hi all,
> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
> 
> Here is the example explain the "dead code" elimination.
> 
> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
> 
> 
>> cat demo.c 
> int main() { char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> 0
> 
> 
> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
> 
>> cat demo.c 
> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139

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

  Delete curly braces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22757/files
  - new: https://git.openjdk.org/jdk/pull/22757/files/12515205..f216aa6f

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

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

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

From syan at openjdk.org  Thu Jan  2 02:43:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 2 Jan 2025 02:43:02 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v4]
In-Reply-To: <ud1QlERp7cMhH6n-bEWlRTW-868orgyMaMF1C81y_QY=.6f294448-0aca-4692-8215-e7c512984c5a@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <NyBWsSdfXlu4YI_lYkuN-XU0wPP7VPhGY5IqBAPmQv8=.ac4e0727-2e27-4960-81a9-482a20b4410c@github.com>
 <ud1QlERp7cMhH6n-bEWlRTW-868orgyMaMF1C81y_QY=.6f294448-0aca-4692-8215-e7c512984c5a@github.com>
Message-ID: <_YUY2L4clhCjNbNr9hZgAVupMk6ZJufaYJEkmlXFh-U=.2895cf4e-948b-4962-ae1a-26118be6c077@github.com>

On Wed, 1 Jan 2025 07:44:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use guarantee(!CrashGCForDumpingJavaThread, "") to generate jvm crash
>
> src/hotspot/share/runtime/frame.cpp line 1166:
> 
>> 1164:   // simulate GC crash here to dump java thread in error report
>> 1165:   if (CrashGCForDumpingJavaThread) {
>> 1166:     guarantee(!CrashGCForDumpingJavaThread, "");
> 
> The surrounding `if` is no longer needed.

Thanks, the curly braces has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900506079

From kbarrett at openjdk.org  Thu Jan  2 02:51:54 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Jan 2025 02:51:54 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v5]
In-Reply-To: <9Px9bo84N_mlfN_wh9lOavf4TeEtUCTLr588biaaEjw=.e0bea88a-4290-45c8-8e07-4a800bf7a7da@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <9Px9bo84N_mlfN_wh9lOavf4TeEtUCTLr588biaaEjw=.e0bea88a-4290-45c8-8e07-4a800bf7a7da@github.com>
Message-ID: <BADhfFCMWiTsew8fiG3hWvw0gswHFpzJ_0H3_e7jw3I=.7b48819c-535c-4e87-be27-c5ea49cdab57@github.com>

On Thu, 2 Jan 2025 02:43:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR use function `guarantee` instead of 'write a byte to nullptr' to trigger the expected jvm crash, risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete curly braces

Changes requested by kbarrett (Reviewer).

src/hotspot/share/runtime/frame.cpp line 1166:

> 1164:   // simulate GC crash here to dump java thread in error report
> 1165:   if (CrashGCForDumpingJavaThread)
> 1166:     guarantee(!CrashGCForDumpingJavaThread, "");

Besides being contrary to the HotSpot Style Guide, that isn't at all what I
meant.  We don't need to test CrashGCForDumpingJavaThread before testing it
again int the guarantee.

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

PR Review: https://git.openjdk.org/jdk/pull/22757#pullrequestreview-2526981587
PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900508321

From syan at openjdk.org  Thu Jan  2 03:11:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 2 Jan 2025 03:11:08 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v6]
In-Reply-To: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
Message-ID: <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>

> Hi all,
> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR use function `guarantee` instead of 'write a byte to nullptr' to trigger the expected jvm crash, risk is low.
> 
> Here is the example explain the "dead code" elimination.
> 
> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
> 
> 
>> cat demo.c 
> int main() { char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> 0
> 
> 
> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
> 
>> cat demo.c 
> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139

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

  Remove duplicate CrashGCForDumpingJavaThread check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22757/files
  - new: https://git.openjdk.org/jdk/pull/22757/files/f216aa6f..12242b2b

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

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

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

From syan at openjdk.org  Thu Jan  2 03:11:09 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 2 Jan 2025 03:11:09 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v5]
In-Reply-To: <BADhfFCMWiTsew8fiG3hWvw0gswHFpzJ_0H3_e7jw3I=.7b48819c-535c-4e87-be27-c5ea49cdab57@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <9Px9bo84N_mlfN_wh9lOavf4TeEtUCTLr588biaaEjw=.e0bea88a-4290-45c8-8e07-4a800bf7a7da@github.com>
 <BADhfFCMWiTsew8fiG3hWvw0gswHFpzJ_0H3_e7jw3I=.7b48819c-535c-4e87-be27-c5ea49cdab57@github.com>
Message-ID: <44ZPuC40iM7jM2ZMytpV_2xN9dSFXNa2dpASyDCX4oI=.4e82b5d6-0277-404b-a9e0-dd6bc6171ed9@github.com>

On Thu, 2 Jan 2025 02:48:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Delete curly braces
>
> src/hotspot/share/runtime/frame.cpp line 1166:
> 
>> 1164:   // simulate GC crash here to dump java thread in error report
>> 1165:   if (CrashGCForDumpingJavaThread)
>> 1166:     guarantee(!CrashGCForDumpingJavaThread, "");
> 
> Besides being contrary to the HotSpot Style Guide, that isn't at all what I
> meant.  We don't need to test CrashGCForDumpingJavaThread before testing it
> again int the guarantee.

Sorry, got it now.
The duplicate `CrashGCForDumpingJavaThread` check has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900512597

From syan at openjdk.org  Thu Jan  2 03:21:35 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 2 Jan 2025 03:21:35 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v5]
In-Reply-To: <44ZPuC40iM7jM2ZMytpV_2xN9dSFXNa2dpASyDCX4oI=.4e82b5d6-0277-404b-a9e0-dd6bc6171ed9@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <9Px9bo84N_mlfN_wh9lOavf4TeEtUCTLr588biaaEjw=.e0bea88a-4290-45c8-8e07-4a800bf7a7da@github.com>
 <BADhfFCMWiTsew8fiG3hWvw0gswHFpzJ_0H3_e7jw3I=.7b48819c-535c-4e87-be27-c5ea49cdab57@github.com>
 <44ZPuC40iM7jM2ZMytpV_2xN9dSFXNa2dpASyDCX4oI=.4e82b5d6-0277-404b-a9e0-dd6bc6171ed9@github.com>
Message-ID: <lGqfaBSWNyAwFDJ28Ck2BAR4L1J802dxY8Zc0Gi_9vI=.99c30d0c-e312-4a51-bef0-dd42cc2a067c@github.com>

On Thu, 2 Jan 2025 03:07:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> src/hotspot/share/runtime/frame.cpp line 1166:
>> 
>>> 1164:   // simulate GC crash here to dump java thread in error report
>>> 1165:   if (CrashGCForDumpingJavaThread)
>>> 1166:     guarantee(!CrashGCForDumpingJavaThread, "");
>> 
>> Besides being contrary to the HotSpot Style Guide, that isn't at all what I
>> meant.  We don't need to test CrashGCForDumpingJavaThread before testing it
>> again int the guarantee.
>
> Sorry, got it now.
> The duplicate `CrashGCForDumpingJavaThread` check has been removed.

1. --with-debug-level=optimized: `java -XX:+CrashGCForDumpingJavaThread -version` do not trigger jvm crash and print version meaasge.
2. --with-debug-level=release: `java -XX:+CrashGCForDumpingJavaThread -version` report VM option 'CrashGCForDumpingJavaThread' is develop and is available only in debug version of VM.
3. --with-debug-level=fastdebug: `java -XX:+CrashGCForDumpingJavaThread -version` trigger jvm crash correctly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900515180

From kbarrett at openjdk.org  Thu Jan  2 05:22:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Jan 2025 05:22:35 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v6]
In-Reply-To: <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
Message-ID: <WySDpjy8Zx2tKoxoPY_nTG8gO-v-pMKtlxA_mr3IPB8=.167a87bc-0de9-46ba-8835-f70fa006cf3d@github.com>

On Thu, 2 Jan 2025 03:11:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR use function `guarantee` instead of 'write a byte to nullptr' to trigger the expected jvm crash, risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate CrashGCForDumpingJavaThread check

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22757#pullrequestreview-2527034313

From kbarrett at openjdk.org  Thu Jan  2 05:22:36 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Jan 2025 05:22:36 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v5]
In-Reply-To: <lGqfaBSWNyAwFDJ28Ck2BAR4L1J802dxY8Zc0Gi_9vI=.99c30d0c-e312-4a51-bef0-dd42cc2a067c@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <9Px9bo84N_mlfN_wh9lOavf4TeEtUCTLr588biaaEjw=.e0bea88a-4290-45c8-8e07-4a800bf7a7da@github.com>
 <BADhfFCMWiTsew8fiG3hWvw0gswHFpzJ_0H3_e7jw3I=.7b48819c-535c-4e87-be27-c5ea49cdab57@github.com>
 <44ZPuC40iM7jM2ZMytpV_2xN9dSFXNa2dpASyDCX4oI=.4e82b5d6-0277-404b-a9e0-dd6bc6171ed9@github.com>
 <lGqfaBSWNyAwFDJ28Ck2BAR4L1J802dxY8Zc0Gi_9vI=.99c30d0c-e312-4a51-bef0-dd42cc2a067c@github.com>
Message-ID: <VrBMGBXEYfoCgGgHZ166c2T7tpmsM1F5vwTz_kT3ZyQ=.e65d618d-8e11-4749-9d09-78b26143c828@github.com>

On Thu, 2 Jan 2025 03:18:35 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Sorry, got it now.
>> The duplicate `CrashGCForDumpingJavaThread` check has been removed.
>
> 1. --with-debug-level=optimized: `java -XX:+CrashGCForDumpingJavaThread -version` do not trigger jvm crash and print version meaasge.
> 2. --with-debug-level=release: `java -XX:+CrashGCForDumpingJavaThread -version` report VM option 'CrashGCForDumpingJavaThread' is develop and is available only in debug version of VM.
> 3. --with-debug-level=fastdebug: `java -XX:+CrashGCForDumpingJavaThread -version` trigger jvm crash correctly.

Good.  Those results are as expected.  In case it isn't clear, the reason for the difference between optimized
(no crash) and fastdebug (crash) is that optimized defaults VerifyBeforeExit to false, while for fastdebug it
defaults to true.  Enabling that option in an optimized build will crash in the same manner as fastdebug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900547348

From amitkumar at openjdk.org  Thu Jan  2 05:32:44 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 2 Jan 2025 05:32:44 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v6]
In-Reply-To: <WySDpjy8Zx2tKoxoPY_nTG8gO-v-pMKtlxA_mr3IPB8=.167a87bc-0de9-46ba-8835-f70fa006cf3d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
 <WySDpjy8Zx2tKoxoPY_nTG8gO-v-pMKtlxA_mr3IPB8=.167a87bc-0de9-46ba-8835-f70fa006cf3d@github.com>
Message-ID: <ROW5XPUvFPSR1x10WBsZ6NwgcHo7unuS-5CM0k8IW38=.0e2e472f-8f46-429a-a66e-9b10151e195c@github.com>

On Thu, 2 Jan 2025 05:20:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate CrashGCForDumpingJavaThread check
>
> Looks good.

@kimbarrett just for my understanding, 
Can't we do something like this: 

  if (CrashGCForDumpingJavaThread) {
    raise(SIGSEGV);
  }

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

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2567300729

From syan at openjdk.org  Thu Jan  2 06:08:41 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 2 Jan 2025 06:08:41 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v5]
In-Reply-To: <VrBMGBXEYfoCgGgHZ166c2T7tpmsM1F5vwTz_kT3ZyQ=.e65d618d-8e11-4749-9d09-78b26143c828@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <9Px9bo84N_mlfN_wh9lOavf4TeEtUCTLr588biaaEjw=.e0bea88a-4290-45c8-8e07-4a800bf7a7da@github.com>
 <BADhfFCMWiTsew8fiG3hWvw0gswHFpzJ_0H3_e7jw3I=.7b48819c-535c-4e87-be27-c5ea49cdab57@github.com>
 <44ZPuC40iM7jM2ZMytpV_2xN9dSFXNa2dpASyDCX4oI=.4e82b5d6-0277-404b-a9e0-dd6bc6171ed9@github.com>
 <lGqfaBSWNyAwFDJ28Ck2BAR4L1J802dxY8Zc0Gi_9vI=.99c30d0c-e312-4a51-bef0-dd42cc2a067c@github.com>
 <VrBMGBXEYfoCgGgHZ166c2T7tpmsM1F5vwTz_kT3ZyQ=.e65d618d-8e11-4749-9d09-78b26143c828@github.com>
Message-ID: <OUfKs0m_UUCqXgSTWhcrVHdsePluGs1kdbvNaTBCE2k=.cb797270-0146-435c-9deb-39831445d6de@github.com>

On Thu, 2 Jan 2025 05:20:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 1. --with-debug-level=optimized: `java -XX:+CrashGCForDumpingJavaThread -version` do not trigger jvm crash and print version meaasge.
>> 2. --with-debug-level=release: `java -XX:+CrashGCForDumpingJavaThread -version` report VM option 'CrashGCForDumpingJavaThread' is develop and is available only in debug version of VM.
>> 3. --with-debug-level=fastdebug: `java -XX:+CrashGCForDumpingJavaThread -version` trigger jvm crash correctly.
>
> Good.  Those results are as expected.  In case it isn't clear, the reason for the difference between optimized
> (no crash) and fastdebug (crash) is that optimized defaults VerifyBeforeExit to false, while for fastdebug it
> defaults to true.  Enabling that option in an optimized build will crash in the same manner as fastdebug.

Thanks for the detail explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900564049

From ayang at openjdk.org  Thu Jan  2 06:49:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 2 Jan 2025 06:49:05 GMT
Subject: RFR: 8346921: Remove unused arg in markWord::must_be_preserved
Message-ID: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>

Trivial removing unused method arg.

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

Commit messages:
 - trivial

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

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

From dskantz at openjdk.org  Thu Jan  2 07:12:35 2025
From: dskantz at openjdk.org (Daniel Skantz)
Date: Thu, 2 Jan 2025 07:12:35 GMT
Subject: RFR: 8346288: WB_IsIntrinsicAvailable fails if called with wrong
 compilation level
In-Reply-To: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
References: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
Message-ID: <pHAOu-PpQ_ULzY7ZYKxoCyrDdiDbzAxuB2QBbIksKVw=.d8465025-c9a2-46d0-b9ba-c0a48d1eafff@github.com>

On Thu, 19 Dec 2024 07:25:15 GMT, Daniel Skantz <dskantz at openjdk.org> wrote:

> Fixes crashes when calling isIntrinsicAvailable with an incorrect compilation level or incompatible VM flag values.
> 
> Testing: T1-3.
> Extra testing: called isIntrinsicAvailable with compLevel={-2, -1, ..., 5) without extra flags, and with -XX:-TieredCompilation -XX:TieredStopAtLevel={0, 1, ..., 4} and observed no crashes after the fix.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22823#issuecomment-2567357320

From duke at openjdk.org  Thu Jan  2 07:12:35 2025
From: duke at openjdk.org (duke)
Date: Thu, 2 Jan 2025 07:12:35 GMT
Subject: RFR: 8346288: WB_IsIntrinsicAvailable fails if called with wrong
 compilation level
In-Reply-To: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
References: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
Message-ID: <LpJ1JdSe6f-lf59OdfrFOUQP93RJC5KQ1Pq6J-iDJZY=.87bfb667-d001-47f6-b1e7-312ebbb01069@github.com>

On Thu, 19 Dec 2024 07:25:15 GMT, Daniel Skantz <dskantz at openjdk.org> wrote:

> Fixes crashes when calling isIntrinsicAvailable with an incorrect compilation level or incompatible VM flag values.
> 
> Testing: T1-3.
> Extra testing: called isIntrinsicAvailable with compLevel={-2, -1, ..., 5) without extra flags, and with -XX:-TieredCompilation -XX:TieredStopAtLevel={0, 1, ..., 4} and observed no crashes after the fix.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/22823#issuecomment-2567357943

From kbarrett at openjdk.org  Thu Jan  2 07:45:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Jan 2025 07:45:38 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v6]
In-Reply-To: <WySDpjy8Zx2tKoxoPY_nTG8gO-v-pMKtlxA_mr3IPB8=.167a87bc-0de9-46ba-8835-f70fa006cf3d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
 <WySDpjy8Zx2tKoxoPY_nTG8gO-v-pMKtlxA_mr3IPB8=.167a87bc-0de9-46ba-8835-f70fa006cf3d@github.com>
Message-ID: <8Y_PP2D8rSY88kKOxAkO4XcSjGtNXqPBMa-0qSoa9xw=.4e690611-020b-4fb6-9b71-3343b4c7ea54@github.com>

On Thu, 2 Jan 2025 05:20:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate CrashGCForDumpingJavaThread check
>
> Looks good.

> @kimbarrett just for my understanding, Can't we do something like this:
> 
> ```c++
>   if (CrashGCForDumpingJavaThread) {
>     raise(SIGSEGV);
>   }
> ```

I think that would also work, but has to go through the complexities of signal handling and reporting, and doesn't
provide any useful context in the error message, only in the hs_err stack trace.  So I think the proposed use of
`guarantee` is better.

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

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2567382372

From kbarrett at openjdk.org  Thu Jan  2 08:30:34 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Jan 2025 08:30:34 GMT
Subject: RFR: 8346921: Remove unused arg in markWord::must_be_preserved
In-Reply-To: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>
References: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>
Message-ID: <HNVbdxui8YXjlRwVdXQswGf_mG7U_JB5NudmCTY4HbI=.248c606d-9bb0-4e13-8f7c-e0080dfbe58a@github.com>

On Thu, 2 Jan 2025 06:44:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused method arg.

Looks good, and trivial.

Appears to be a leftover from the removal of biased locking.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22900#pullrequestreview-2527179415

From amitkumar at openjdk.org  Thu Jan  2 08:30:44 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 2 Jan 2025 08:30:44 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v6]
In-Reply-To: <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
Message-ID: <Xv0qlhSs_eHAcS8IShv0x01MHqbV72MNQ0SvvO79KiY=.dd0d1529-de08-455b-9162-ef0fbd06e4d2@github.com>

On Thu, 2 Jan 2025 03:11:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR use function `guarantee` instead of 'write a byte to nullptr' to trigger the expected jvm crash, risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate CrashGCForDumpingJavaThread check

Marked as reviewed by amitkumar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22757#pullrequestreview-2527179005

From tschatzl at openjdk.org  Thu Jan  2 08:33:34 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 2 Jan 2025 08:33:34 GMT
Subject: RFR: 8346921: Remove unused arg in markWord::must_be_preserved
In-Reply-To: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>
References: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>
Message-ID: <Y6RtTos1QDz36SpGThHRUT5GLoXIcdQ4V5eBwEbgMkk=.12079e07-05df-43de-8180-1af7d6cee40a@github.com>

On Thu, 2 Jan 2025 06:44:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused method arg.

lgtm

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22900#pullrequestreview-2527182433

From syan at openjdk.org  Thu Jan  2 09:12:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 2 Jan 2025 09:12:39 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v6]
In-Reply-To: <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
Message-ID: <OQbS6k95hcHJRLM1YMpA0fPjiO1Psqlk-fkrcS1CiNs=.df7c69ef-7ea3-4108-a029-51459995fb9a@github.com>

On Thu, 2 Jan 2025 03:11:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR use function `guarantee` instead of 'write a byte to nullptr' to trigger the expected jvm crash, risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate CrashGCForDumpingJavaThread check

Thanks all for the advices and reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2567462918

From syan at openjdk.org  Thu Jan  2 09:12:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 2 Jan 2025 09:12:40 GMT
Subject: Integrated: 8346193: CrashGCForDumpingJavaThread do not trigger
 expected crash build with clang17
In-Reply-To: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
Message-ID: <yIC_zWbFAzin40HDMHlXPvwvgAUYU8-LjWzGIKMMz6I=.498ce734-9b14-4fa5-b967-41266b54bd2f@github.com>

On Mon, 16 Dec 2024 09:53:08 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR use function `guarantee` instead of 'write a byte to nullptr' to trigger the expected jvm crash, risk is low.
> 
> Here is the example explain the "dead code" elimination.
> 
> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
> 
> 
>> cat demo.c 
> int main() { char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> 0
> 
> 
> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
> 
>> cat demo.c 
> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139

This pull request has now been integrated.

Changeset: e769b536
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e769b53614b13e09ea575558be687607549f700b
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8346193: CrashGCForDumpingJavaThread do not trigger expected crash build with clang17

Reviewed-by: kbarrett, amitkumar

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

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

From coleenp at openjdk.org  Thu Jan  2 12:37:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 12:37:39 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <a-vdtKR9hAh_fOS3EVjIT_pmb-3ZG2-mKAskG-9ufh0=.a101141b-12b8-4723-aa8d-d2aaf11b9cc3@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
 <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@github.com>
 <a-vdtKR9hAh_fOS3EVjIT_pmb-3ZG2-mKAskG-9ufh0=.a101141b-12b8-4723-aa8d-d2aaf11b9cc3@github.com>
Message-ID: <MT8uIXYGd9piv0ucdKYoMMaiDT_ovxFP-5olTVO8x_0=.bcc94c19-c75a-4fd6-be33-bca4e75bc491@github.com>

On Wed, 25 Dec 2024 16:34:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> It wasn't the logic.  When I went through I didn't know if this instruction needed fixing because we loaded an unsigned short instead of an int.  So I left myself a note to look at it again that you noticed and I didn't in my final walk through.  It seems right but maybe someone with ppc knowledge can answer this.
>> 
>> 
>>     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.
>
> The instruction looks still correct. We are checking the same bit of the 64 bit register as before. (Using `testbitdi` would also work.)

I changed this to testbitdi.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900836026

From mdoerr at openjdk.org  Thu Jan  2 12:55:37 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Jan 2025 12:55:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <MT8uIXYGd9piv0ucdKYoMMaiDT_ovxFP-5olTVO8x_0=.bcc94c19-c75a-4fd6-be33-bca4e75bc491@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
 <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@github.com>
 <a-vdtKR9hAh_fOS3EVjIT_pmb-3ZG2-mKAskG-9ufh0=.a101141b-12b8-4723-aa8d-d2aaf11b9cc3@github.com>
 <MT8uIXYGd9piv0ucdKYoMMaiDT_ovxFP-5olTVO8x_0=.bcc94c19-c75a-4fd6-be33-bca4e75bc491@github.com>
Message-ID: <BFtXal4fiYWTbisCegWXYTMkWf0Kn-TTQfSQeZrxByU=.819f4cf0-df56-4b53-8f10-c9b5050c09d5@github.com>

On Thu, 2 Jan 2025 12:34:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The instruction looks still correct. We are checking the same bit of the 64 bit register as before. (Using `testbitdi` would also work.)
>
> I changed this to testbitdi.

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900849068

From coleenp at openjdk.org  Thu Jan  2 12:59:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 12:59:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <IniXsCjoGi3TxdIGl2LPkyhWAc6xSSPJgvqrFp7GQu0=.f32a6d18-7c9b-4e04-9502-dbfb2bee13b2@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <IniXsCjoGi3TxdIGl2LPkyhWAc6xSSPJgvqrFp7GQu0=.f32a6d18-7c9b-4e04-9502-dbfb2bee13b2@github.com>
Message-ID: <XTG5K61GEgvZcGXyO5aczl07jaWjyFYeT6DRp5aJMac=.29b8719c-c3a9-47e7-b76e-3d45da536a02@github.com>

On Fri, 20 Dec 2024 21:34:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore ACC in comment.
>
> src/hotspot/share/oops/method.cpp line 1655:
> 
>> 1653:     return;
>> 1654:   }
>> 1655:   jshort flags = checked_cast<jshort>(access_flags().as_unsigned_short());
> 
> Can we cleanup the intrinsics code next, to stop using jshort for flags?

I was going to file a new issue but this is really easy to fix, so I added this fix to this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900852859

From coleenp at openjdk.org  Thu Jan  2 13:04:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:04:18 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v6]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <f3Ndp77aLf69daUZUm1bHYShhmJKJONEDywZPRY7rMY=.7c07db10-26d0-4eb7-82b0-c447ae899ed6@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

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

  Make vmIntrinsics::find_id() take u2 not jshort.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/4faf19ba..df95d447

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

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

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

From coleenp at openjdk.org  Thu Jan  2 13:08:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:08:12 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <RuiVOVzj252-iXUbhhY2PNiIHzQdxUCaBD6IRbxouI4=.df35fa01-1ce0-44e4-b6db-b4bc3476792f@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <RuiVOVzj252-iXUbhhY2PNiIHzQdxUCaBD6IRbxouI4=.df35fa01-1ce0-44e4-b6db-b4bc3476792f@github.com>
Message-ID: <cVdgOEAgUWp259UB3t_g5vCp3pZ9do1JvV6aHZqBGRA=.817ec1c2-36b7-4d27-9249-2c4c7284effb@github.com>

On Wed, 25 Dec 2024 16:40:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore ACC in comment.
>
> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 149:
> 
>> 147:     // _access_flags must be a 16 bit value.
>> 148:     assert(sizeof(AccessFlags) == 2, "wrong size");
>> 149:     __ lha(R11_scratch1/*access_flags*/, method_(access_flags));
> 
> Using `lhz` would be more consistent. `lha` uses sign extend instead of zero extend. Feel free to clean this up if you want. Both instructions should work.

I fixed this - it was the only one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900858739

From coleenp at openjdk.org  Thu Jan  2 13:08:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:08:12 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v7]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <LN8OLYpL7jLG920ljVWhyG4SWFIn9x2o_Iqrx91fx6Q=.997e0efb-2041-4b27-a2f6-36788ff2c18e@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

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

  Fix lhz in ppc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/df95d447..5a84b139

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

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

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

From coleenp at openjdk.org  Thu Jan  2 13:14:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:14:14 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v8]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <67hlSAvg5aEfWNhl2tj2Fe5FKNNXsJ8TsOCUe10KRQg=.54a14494-af1f-4bd0-a7dc-b5ece84ecd97@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

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

  Import @offamitkumar patch for s390.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/5a84b139..8cafd452

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

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

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

From coleenp at openjdk.org  Thu Jan  2 13:14:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:14:15 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v7]
In-Reply-To: <LN8OLYpL7jLG920ljVWhyG4SWFIn9x2o_Iqrx91fx6Q=.997e0efb-2041-4b27-a2f6-36788ff2c18e@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <LN8OLYpL7jLG920ljVWhyG4SWFIn9x2o_Iqrx91fx6Q=.997e0efb-2041-4b27-a2f6-36788ff2c18e@github.com>
Message-ID: <PfmZdTt-EA4Ly2yj5wmjB8seJ66hod1qVRIfvQJOr_k=.b3d9653e-3c2e-4cc9-9b3b-076cb066883b@github.com>

On Thu, 2 Jan 2025 13:08:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix lhz in ppc

Thank you for the patch Amit.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2567753064

From coleenp at openjdk.org  Thu Jan  2 13:20:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:20:20 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v9]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

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

  Happy New Year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/8cafd452..c60e96b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=07-08

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

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

From mdoerr at openjdk.org  Thu Jan  2 13:55:36 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Jan 2025 13:55:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <cVdgOEAgUWp259UB3t_g5vCp3pZ9do1JvV6aHZqBGRA=.817ec1c2-36b7-4d27-9249-2c4c7284effb@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <RuiVOVzj252-iXUbhhY2PNiIHzQdxUCaBD6IRbxouI4=.df35fa01-1ce0-44e4-b6db-b4bc3476792f@github.com>
 <cVdgOEAgUWp259UB3t_g5vCp3pZ9do1JvV6aHZqBGRA=.817ec1c2-36b7-4d27-9249-2c4c7284effb@github.com>
Message-ID: <9uPHxBroRJc6lcPjNOMALruNbfomUw-zG3oxYJg_N10=.9b3e439b-d3ff-4092-a205-699e5f9921b9@github.com>

On Thu, 2 Jan 2025 13:05:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 149:
>> 
>>> 147:     // _access_flags must be a 16 bit value.
>>> 148:     assert(sizeof(AccessFlags) == 2, "wrong size");
>>> 149:     __ lha(R11_scratch1/*access_flags*/, method_(access_flags));
>> 
>> Using `lhz` would be more consistent. `lha` uses sign extend instead of zero extend. Feel free to clean this up if you want. Both instructions should work.
>
> I fixed this - it was the only one.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900899700

From rriggs at openjdk.org  Thu Jan  2 18:34:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 2 Jan 2025 18:34:38 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <dr1_0pthFJtf_cDfhekixQSS2XOPM92JjX3vT763Ne8=.3e52b7b1-3420-4e7c-9c35-3fe8b1335eab@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2528039527

From stooke at openjdk.org  Thu Jan  2 19:14:56 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 2 Jan 2025 19:14:56 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v2]
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <fiZAIh_ms_gL7r5_KClBPISG-OE2CQI0MRivcZDVi3Y=.b5b443a2-3e83-4b9b-b1ad-c33f4c538e74@github.com>

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  refine jtreg tags per review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22870/files
  - new: https://git.openjdk.org/jdk/pull/22870/files/1da4240d..9819f027

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

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

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

From dskantz at openjdk.org  Thu Jan  2 22:15:50 2025
From: dskantz at openjdk.org (Daniel Skantz)
Date: Thu, 2 Jan 2025 22:15:50 GMT
Subject: Integrated: 8346288: WB_IsIntrinsicAvailable fails if called with
 wrong compilation level
In-Reply-To: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
References: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
Message-ID: <jBrTY1fsGXnI988k7mkuxW-JWRS4cOHnQ2JD4SsGgEU=.98700cba-de23-47dc-bf10-d1b176f2712d@github.com>

On Thu, 19 Dec 2024 07:25:15 GMT, Daniel Skantz <dskantz at openjdk.org> wrote:

> Fixes crashes when calling isIntrinsicAvailable with an incorrect compilation level or incompatible VM flag values.
> 
> Testing: T1-3.
> Extra testing: called isIntrinsicAvailable with compLevel={-2, -1, ..., 5) without extra flags, and with -XX:-TieredCompilation -XX:TieredStopAtLevel={0, 1, ..., 4} and observed no crashes after the fix.

This pull request has now been integrated.

Changeset: 84e6432b
Author:    Daniel Skantz <dskantz at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84e6432bb73e35b32f12cdc0e1a172b7c973e618
Stats:     9 lines in 1 file changed: 7 ins; 2 del; 0 mod

8346288: WB_IsIntrinsicAvailable fails if called with wrong compilation level

Reviewed-by: kvn, rcastanedalo

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

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

From mdoerr at openjdk.org  Thu Jan  2 22:21:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Jan 2025 22:21:51 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
Message-ID: <12-_FKsXl3OOujKaHQewgKdDUi95q9M0fSmuLeo6_Wg=.1ec72306-698f-42f8-86b7-e53bc711fde6@github.com>

On Tue, 31 Dec 2024 06:42:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forbid windows _snprintf

Unfortunately, this doesn't compile on AIX:

globalDefinitions_gcc.hpp:42:
In file included from /opt/IBM/openxlC/17.1.1/bin/../include/c++/v1/stdlib.h:93:
/usr/include/stdlib.h:304:18: error: 'noreturn' attribute does not appear on the first declaration
        extern _NOTHROW(_NORETURN(void, exit), (int));
                        ^
/usr/include/comp_macros.h:30:35: note: expanded from macro '_NORETURN'
#define _NORETURN(_T, _F) _T _F [[noreturn]]
                                  ^
   ... (rest of output omitted)

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2568451299

From sspitsyn at openjdk.org  Thu Jan  2 23:36:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 Jan 2025 23:36:41 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v9]
In-Reply-To: <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
Message-ID: <Ukn4bU2zbBzr7L7sQkE_E5LCyLIjBa2vWQrsO0Fj114=.8531d459-2666-41d1-b702-b798c5d3f670@github.com>

On Thu, 2 Jan 2025 13:20:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Happy New Year

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1151:

> 1149:       // methods match, be sure modifiers do too
> 1150:       old_flags = k_old_method->access_flags().as_unsigned_short();
> 1151:       new_flags = k_new_method->access_flags().as_unsigned_short();

Nit: I'd suggest to use `as_method_flags()` and `as_class_flags()` at lines 1008-1009 to make it consistent with the lines 1043-1044. Good example is `jvmtiClassFileReconstituter.cpp`. Also, it would make sense to expend this rule to some other files, e.g.:
 `methodHandles.cpp`, `jvmtiEnv.cpp`, `jvm.cpp`, instanceClass.cpp`, `fieldInfo.inline.hpp`, `fieldInfo.cpp

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1901371957

From kbarrett at openjdk.org  Thu Jan  2 23:37:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 2 Jan 2025 23:37:39 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <12-_FKsXl3OOujKaHQewgKdDUi95q9M0fSmuLeo6_Wg=.1ec72306-698f-42f8-86b7-e53bc711fde6@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <12-_FKsXl3OOujKaHQewgKdDUi95q9M0fSmuLeo6_Wg=.1ec72306-698f-42f8-86b7-e53bc711fde6@github.com>
Message-ID: <8M7tvmDz6F63ehnC7efuV98IwRwOYUEq5K2wXPiepCI=.a187f96b-6a2a-4044-bd18-4152584dcf9a@github.com>

On Thu, 2 Jan 2025 22:19:00 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Unfortunately, this doesn't compile on AIX: [...]

Ugh!  The clang workaround  for noreturn handling is going to need to be more extensive.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2568520652

From qxing at openjdk.org  Fri Jan  3 01:36:51 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Fri, 3 Jan 2025 01:36:51 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <7dv3Q8SJD7soOx8rgXMB2_ZOf3RbwtcI7zuzybFjJoQ=.b875ea95-9e62-41b8-9898-0d7d21a14b5e@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Thank you all for your suggestions and reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2568590393

From duke at openjdk.org  Fri Jan  3 01:36:51 2025
From: duke at openjdk.org (duke)
Date: Fri, 3 Jan 2025 01:36:51 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <6jso7rCfR9hvxiCw9z222ueaJQxQol9ELecOcr5BQxQ=.d399c10e-79bd-4f4f-9ed1-91f777c3cb8a@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

@MaxXSoft 
Your change (at version 7f85c5e30ab69fe2f94d4604073eb8e610bfc6c2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2568591104

From amitkumar at openjdk.org  Fri Jan  3 07:49:43 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 3 Jan 2025 07:49:43 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v9]
In-Reply-To: <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
Message-ID: <wnb5Aet32sQo0Qb7r7NI7FYyGwRuaNVVZL8vRe-JkeE=.3e546c1f-f800-47b6-9346-5d260a87d44e@github.com>

On Thu, 2 Jan 2025 13:20:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Happy New Year

Thanks for adding the patch Coleen :-) 

 I did another test-run and s390x looks fine now.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2568808253

From stuefe at openjdk.org  Fri Jan  3 08:08:41 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 3 Jan 2025 08:08:41 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v2]
In-Reply-To: <WAMtcxIBp_Fi5EK_ZQbMjnIEUpriSdO5ZsHurJuTvWw=.c421321c-9141-4560-88c3-4b5b3cba03b9@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <1un8gWR4Ybo3CMB4xNWk2OI6IsJyeeukIyqhfR708z8=.aa45ffdc-baa7-406a-a284-040f72dcbdab@github.com>
 <3cxwvvQ_z9o4uDtyqrxNB7-9_7v7_Ufz8iE61ZXPxl0=.a0f13fa3-64fa-4f13-9e5e-717e31c177b7@github.com>
 <YsA_I2Lriaap_xT_9yk921RCQv-OKXbeIVr016Li1aw=.5e7f057f-8bbc-47dc-9b96-dde8df9a0973@github.com>
 <WAMtcxIBp_Fi5EK_ZQbMjnIEUpriSdO5ZsHurJuTvWw=.c421321c-9141-4560-88c3-4b5b3cba03b9@github.com>
Message-ID: <HAnR_El28_aFzA-poQBSq9-MhGZrDXqPEwBF-vFby4s=.2e040fcf-91cb-407e-9185-b7faf9d6152a@github.com>

On Tue, 31 Dec 2024 10:40:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Or do we really need to support this in "optimized" builds?  I'm not sure who uses this.
>
>> OTOH, based on the comment's description of what this is needed for, why not just `guarantee(!CrashGCForDumpingJavaThread, "")` ?
> 
> Previously I am not quite sure that use `ShouldNotReachHere()` instead of `*t = 'c'` could break the original test intention or not. Use `guarantee(!CrashGCForDumpingJavaThread, "")` make the original test [check](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java#L103) success. So I think use `guarantee(!CrashGCForDumpingJavaThread, "")` will acceptable. The code has been changed. Thanks your advices.

> Or do we really need to support this in "optimized" builds? I'm not sure who uses this.

I thought we wanted to remove it (https://bugs.openjdk.org/browse/JDK-8183287)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1901549131

From stuefe at openjdk.org  Fri Jan  3 08:18:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 3 Jan 2025 08:18:38 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v6]
In-Reply-To: <8Y_PP2D8rSY88kKOxAkO4XcSjGtNXqPBMa-0qSoa9xw=.4e690611-020b-4fb6-9b71-3343b4c7ea54@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
 <WySDpjy8Zx2tKoxoPY_nTG8gO-v-pMKtlxA_mr3IPB8=.167a87bc-0de9-46ba-8835-f70fa006cf3d@github.com>
 <8Y_PP2D8rSY88kKOxAkO4XcSjGtNXqPBMa-0qSoa9xw=.4e690611-020b-4fb6-9b71-3343b4c7ea54@github.com>
Message-ID: <4nPa9mrhJh2r7qjGzt9puzg14h32wdiuhsUO9Vh-aDQ=.5a5c03c4-a684-419e-8d00-667eb0f85add@github.com>

On Thu, 2 Jan 2025 07:42:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > @kimbarrett just for my understanding, Can't we do something like this:
> > ```c++
> >   if (CrashGCForDumpingJavaThread) {
> >     raise(SIGSEGV);
> >   }
> > ```
> 
> I think that would also work, but has to go through the complexities of signal handling and reporting, and doesn't provide any useful context in the error message, only in the hs_err stack trace. So I think the proposed use of `guarantee` is better.

To extend on @kimbarrett's answer: In some (few) crash tests we need real signals, in order to test detailed signal printing. But in those cases `raise` is also a poor choice, since it changes the signal details we get from the kernel. When we don't need to test signal handling, guarantee or assert are sufficient.

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

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2568834885

From epeter at openjdk.org  Fri Jan  3 08:51:37 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 3 Jan 2025 08:51:37 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v6]
In-Reply-To: <JOUCPakioJEQD8AVPnDAw51sFAk6qYADITVo-fEsZxk=.8d6dc3d6-0838-490a-b2e6-8a78cb1f6afb@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <BmcBU2NE8-d1Zaz8mM6oPw5VY--4lPsn8aX9pL7hJ0Y=.e2d62858-a0da-4f69-845a-7cbd8897dd30@github.com>
 <9uGYNmVdvCXvyYSOAfwmvD70nWkimOFIlQJolQWa_Z4=.c6ffbfa0-5eb1-40a4-83a4-b657f57c9836@github.com>
 <JOUCPakioJEQD8AVPnDAw51sFAk6qYADITVo-fEsZxk=.8d6dc3d6-0838-490a-b2e6-8a78cb1f6afb@github.com>
Message-ID: <AE1cy_IT7B9BapAUJ9iQs-U1r-gtyYee-UAQaiShDcE=.7f82bd1a-0e14-4bef-bff9-7d43563ff1b8@github.com>

On Fri, 20 Dec 2024 16:08:51 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 135:
>> 
>>> 133:     @IR(applyIf = {"SuperWordReductions", "true"},
>>> 134:         applyIfCPUFeatureOr = { "avx512", "true" },
>>> 135:         counts = {IRNode.MIN_REDUCTION_V, " > 0"})
>> 
>>> @eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further.
>> 
>> Hi @galderz , may I ask if these long-reduction cases can't work even with `sve`? It might be related with the limitation [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566). Some `sve` machines have only 128 bits.
>
> That's right. Neoverse V2 is 4 pipes of 128 bits, V1 is 2 pipes of 256 bits.
> That comment is "interesting". Maybe it should be tunable by the back end. Given that Neoverse V2 can issue 4 SVE operations per clock cycle, it might still be a win.
> 
> Galder, how about you disable that line and give it another try?

FYI: I'm working on removing the line [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566).

The issue is that on some platforms 2-element vectors are somehow really slower, and we need a cost-model to give us a better heuristic, rather than the hard "no". See my draft https://github.com/openjdk/jdk/pull/20964.

But yes: why don't you remove the line, and see if that makes it work. If so, then don't worry about this case for now, and maybe leave a comment in the test. We can then fix that later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1901576209

From epeter at openjdk.org  Fri Jan  3 09:01:57 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 3 Jan 2025 09:01:57 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v7]
In-Reply-To: <Pfc5OL7VuwoN5XcngckPx0FSdT9wU-y9sGnb1esBmMo=.8be153ea-60d9-49ca-b17e-a7164e98a73b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <Pfc5OL7VuwoN5XcngckPx0FSdT9wU-y9sGnb1esBmMo=.8be153ea-60d9-49ca-b17e-a7164e98a73b@github.com>
Message-ID: <iBC_B4BahgqB8_-0rxsoH4NXNQPdHYanccx146OyLcc=.473f79b5-0962-45f2-80de-9b29e34323dd@github.com>

On Mon, 23 Dec 2024 06:54:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Review comments resolutions

src/hotspot/share/opto/type.cpp line 1465:

> 1463: //------------------------------meet-------------------------------------------
> 1464: // Compute the MEET of two types.  It returns a new Type object.
> 1465: const Type *TypeH::xmeet( const Type *t ) const {

Suggestion:

const Type* TypeH::xmeet( const Type* t ) const {

Please check all other occurances.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1901578736

From ayang at openjdk.org  Fri Jan  3 11:48:49 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Jan 2025 11:48:49 GMT
Subject: RFR: 8346921: Remove unused arg in markWord::must_be_preserved
In-Reply-To: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>
References: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>
Message-ID: <4x1_gu_n6f_Xb_Sb9-P9sXQGsxg_1UDSEQV_8844Omo=.d4eadf9a-aab5-4d30-a56c-0e69a3c34f7f@github.com>

On Thu, 2 Jan 2025 06:44:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused method arg.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/22900#issuecomment-2569100873

From ayang at openjdk.org  Fri Jan  3 11:48:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 3 Jan 2025 11:48:50 GMT
Subject: Integrated: 8346921: Remove unused arg in markWord::must_be_preserved
In-Reply-To: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>
References: <1ByXRqDGmkl8NStv7dzRHFjFjYDon0kVQsAWnbMrQ3E=.c99ce288-b14d-456e-87c5-c2956cdd7420@github.com>
Message-ID: <Ys8pwddnQrkc1bxGcqft4efMxutrhofqX9IR3I0YE1c=.a212484e-0019-48b1-8d18-4011d316c414@github.com>

On Thu, 2 Jan 2025 06:44:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused method arg.

This pull request has now been integrated.

Changeset: 07c9f713
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07c9f7138affdf0d42ecdc30adcb854515569985
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8346921: Remove unused arg in markWord::must_be_preserved

Reviewed-by: kbarrett, tschatzl

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

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

From jsjolen at openjdk.org  Fri Jan  3 13:27:50 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 3 Jan 2025 13:27:50 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
Message-ID: <5JjsCtkAmOXUdGJjqvcgsek8ft_XlaIw2iLM_mgqFj8=.16d96a5f-a005-4340-81a9-653b52572a8a@github.com>

On Tue, 31 Dec 2024 06:42:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forbid windows _snprintf

Hi, 

I really like the syntactic change of this feature, and it's very nice that we get to have working auto-complete (makes it easier to find out that a specific function isn't forbidden). The syntactic change isn't shown in the PR description, isn't that useful to add?

I have a bike shedding request: Could we skip the S at the end and have it be `permit_forbidden_function::free(my_ptr);`? We only allow one forbidden function in that call, so this reads neater.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2569218247

From coleenp at openjdk.org  Fri Jan  3 14:38:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 14:38:22 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
Message-ID: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>

There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.

Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

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

Commit messages:
 - 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros

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

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

From jwaters at openjdk.org  Fri Jan  3 15:43:41 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Jan 2025 15:43:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <GB7FT__OPX76lA3Ch8Uwjb5So6JcI-K4ZFQ2ox3uC38=.d2072422-4281-418d-beff-cbb16c1afdcb@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Speaking of %z, there is a non Standard %Ix in os_windows.cpp


tty->print_cr("reserve_memory of %Ix bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,
                    reserveTimer.milliseconds(), reserveTimer.ticks());


Could changing that to %zu be trivial enough to fit into this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2569435948

From jwaters at openjdk.org  Fri Jan  3 15:45:43 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Jan 2025 15:45:43 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
Message-ID: <-Yq74ZD6bE9umMSXPGo0Ko9ZkKAQC5K5dpnYMjTxXvQ=.5e657584-6734-4cca-956e-e2a99449861a@github.com>

On Tue, 31 Dec 2024 06:42:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forbid windows _snprintf

Hi Johan, which syntactic change are you referring to?

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2569437739

From coleenp at openjdk.org  Fri Jan  3 16:23:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 16:23:31 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

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

  Fix %Ix to %zx.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/6d6fbfa7..1748797a

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

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

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

From coleenp at openjdk.org  Fri Jan  3 16:23:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 16:23:32 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <PqP9LcFOEMsX5bVeywyEEEdBVvHSp7y6axjHAOgCYIw=.24eb6982-7cb1-4686-a2ba-a6fc0500f80a@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

I was going to take on the other FORMAT ones in separate PRs.
Sorry I see what you're saying.  yes, I'll fix that too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2569484010

From coleenp at openjdk.org  Fri Jan  3 19:22:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 19:22:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v9]
In-Reply-To: <Ukn4bU2zbBzr7L7sQkE_E5LCyLIjBa2vWQrsO0Fj114=.8531d459-2666-41d1-b702-b798c5d3f670@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
 <Ukn4bU2zbBzr7L7sQkE_E5LCyLIjBa2vWQrsO0Fj114=.8531d459-2666-41d1-b702-b798c5d3f670@github.com>
Message-ID: <5-GUDe1mvBa86obIcZdPrzFkXtrXU7Epn9ol6pxfHbE=.a90acfed-bece-4d9d-a56b-6981a52cbbb0@github.com>

On Thu, 2 Jan 2025 23:33:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Happy New Year
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1151:
> 
>> 1149:       // methods match, be sure modifiers do too
>> 1150:       old_flags = k_old_method->access_flags().as_unsigned_short();
>> 1151:       new_flags = k_new_method->access_flags().as_unsigned_short();
> 
> Nit: I'd suggest to use `as_method_flags()` and `as_class_flags()` at lines 1008-1009 to make it consistent with the lines 1043-1044. Good example is `jvmtiClassFileReconstituter.cpp`. Also, it would make sense to expend this rule to some other files, e.g.: `method.cpp`, `methodHandles.cpp`, `jvmtiEnv.cpp`, `jvm.cpp`, `instanceClass.cpp`, `fieldInfo.inline.hpp`, `fieldInfo.cpp`

This is a good suggestion.  I strengthened the as_{field|method|class}_flags functions because they should be stored with only their recognized modifiers in the appropriate place.  Retesting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1902091752

From stooke at openjdk.org  Fri Jan  3 20:10:35 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Fri, 3 Jan 2025 20:10:35 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v2]
In-Reply-To: <vVnDBpaQPPLgUr42_r3PhIstcOymm6wxlBADbPkLhWs=.671f5826-1a21-4cb6-9500-61357cf4b3ed@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <vVnDBpaQPPLgUr42_r3PhIstcOymm6wxlBADbPkLhWs=.671f5826-1a21-4cb6-9500-61357cf4b3ed@github.com>
Message-ID: <TvCaB-h4ouwH0lAcEhVWa5NYdGQjkD5zAOjZlUiWlA4=.b9956a7f-0dd7-4742-af07-e4aa1e0f6a90@github.com>

On Wed, 25 Dec 2024 00:26:30 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine jtreg tags per review
>
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 39:
> 
>> 37:  *          java.management
>> 38:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
>> 39:  * @run testng/othervm -XX:+UsePerfData -XX:+UseZGC SystemMapTest
> 
> No need to add separate testcase for ZGC. It is expected that  hotspot tests are usually executed to ensure that all functionality works with any GC.
> If you want to add it to ensure that  regression testcase is always executed even no ZGC is set then please 
> 1) add
> `* @requires vm.gc.Z`
> So testcase is not executed if non-ZGC GC (Parallel/Serial etc) is set explicitly.
> 2) Add 
> ` * @bug 8346717`
> 3) Add id like
> `* @test id=zgc`
> to make testcase name clearer.

@lmesnik thank you for the review!  I have updated the jtreg tags as suggested.  My intent is to ensure this test is run with and without ZGC as the expected results differ.  I believe I can accomplish this with these two test definitions?  I've seen similar test definitions elsewhere in the jdk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1902126817

From jbhateja at openjdk.org  Fri Jan  3 20:36:21 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 3 Jan 2025 20:36:21 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v8]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <EKxPmKlinKZV5nPSVsa935cOw1QTGno7dJ70j2LkoRI=.c0823831-7db4-410e-a644-cbea69d32faf@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja 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 nine additional commits since the last revision:

 - Updating copyright year of modified files.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103
 - Review suggestions incorporated.
 - Review comments resolutions
 - Addressing review comments
 - Fixing obfuscation due to intrinsic entries
 - Adding more test points
 - Adding missed check in container type detection.
 - C2 compiler support for float16 scalar operations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/dd444c44..d3cbf2c4

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

  Stats: 17820 lines in 567 files changed: 13308 ins; 2583 del; 1929 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

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

From jbhateja at openjdk.org  Fri Jan  3 20:42:15 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 3 Jan 2025 20:42:15 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Updating copyright year of modified files.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/d3cbf2c4..175f4ed2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=07-08

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

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

From jsjolen at openjdk.org  Fri Jan  3 20:47:34 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 3 Jan 2025 20:47:34 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <-Yq74ZD6bE9umMSXPGo0Ko9ZkKAQC5K5dpnYMjTxXvQ=.5e657584-6734-4cca-956e-e2a99449861a@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <-Yq74ZD6bE9umMSXPGo0Ko9ZkKAQC5K5dpnYMjTxXvQ=.5e657584-6734-4cca-956e-e2a99449861a@github.com>
Message-ID: <BeaVNs4twNSm-ZXh971HPev9fh6ZEPkyBgRyhtkmGMc=.f07e8c8b-f819-4d09-959f-9109d01f0d35@github.com>

On Fri, 3 Jan 2025 15:42:52 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Hi Johan, which syntactic change are you referring to?

Oh, just that we don't have to repeat the name of the function we want to use. No more macro, just a namespace and a function!

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2569793807

From jsjolen at openjdk.org  Fri Jan  3 21:31:45 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 3 Jan 2025 21:31:45 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
Message-ID: <C7MN7vMR_wOnEA4Ja1Rqb8D5Q1VNavFvP8VQ9duOdQI=.e05b1faf-228e-4c6e-aba2-c6c7b33f280e@github.com>

On Tue, 31 Dec 2024 06:42:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forbid windows _snprintf

I've read through it all, and it seems like good code to me. I like the change in syntax a lot. I've one nit regarding comment style.

src/hotspot/share/utilities/compilerWarnings.hpp line 89:

> 87: #endif
> 88: 
> 89: //////////////////////////////////////////////////////////////////////////////

This doesn't adhere to the style of the file AFAICS and is unnecessary, can we remove it?

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

PR Review: https://git.openjdk.org/jdk/pull/22890#pullrequestreview-2529737692
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1902178578

From coleenp at openjdk.org  Fri Jan  3 21:54:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 21:54:26 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v10]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <X28oWuUDJ1j-p0Gds7qSo7MMgBLry1CZPORSWexezYQ=.a4a3021d-639e-40a4-a1cb-8bceff542bb3@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

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

  Adopt @sspitsyn suggestion and strengthen field/method/class flag retrieval.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/c60e96b4..8682a778

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=08-09

  Stats: 36 lines in 9 files changed: 11 ins; 5 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

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

From coleenp at openjdk.org  Fri Jan  3 22:00:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 22:00:34 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

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

  Fix more copyrights.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/8682a778..82bd1a24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=09-10

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

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

From coleenp at openjdk.org  Fri Jan  3 22:45:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 22:45:40 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
Message-ID: <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>

On Tue, 31 Dec 2024 06:42:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forbid windows _snprintf

This is very nice, now that I've navigated to all the pieces and see how it works.  I would rather see #ifdef include the posix file rather than the dispatch header files which would help finding all the bits again.

src/hotspot/share/utilities/forbiddenFunctions.hpp line 33:

> 31: #include <stddef.h> // for size_t
> 32: 
> 33: #include OS_HEADER(forbiddenFunctions)

I thought there was an OS_VARIANT_HEADER to dispatch directly to the posix variant, but I guess it doesn't exist.  Using the semaphore example, this could save your dispatch header files, at the cost of an #ifdef.  Not sure which is worse:


#if defined(LINUX) || defined(AIX)
# include "semaphore_posix.hpp"
#else
# include OS_HEADER(semaphore)
#endif

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

PR Review: https://git.openjdk.org/jdk/pull/22890#pullrequestreview-2529794425
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1902213295

From coleenp at openjdk.org  Fri Jan  3 22:45:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 22:45:41 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
Message-ID: <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>

On Fri, 3 Jan 2025 22:31:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   forbid windows _snprintf
>
> src/hotspot/share/utilities/forbiddenFunctions.hpp line 33:
> 
>> 31: #include <stddef.h> // for size_t
>> 32: 
>> 33: #include OS_HEADER(forbiddenFunctions)
> 
> I thought there was an OS_VARIANT_HEADER to dispatch directly to the posix variant, but I guess it doesn't exist.  Using the semaphore example, this could save your dispatch header files, at the cost of an #ifdef.  Not sure which is worse:
> 
> 
> #if defined(LINUX) || defined(AIX)
> # include "semaphore_posix.hpp"
> #else
> # include OS_HEADER(semaphore)
> #endif

park.hpp has the same:


#if defined(LINUX) || defined(AIX) || defined(BSD)
# include "park_posix.hpp"
#else
# include OS_HEADER(park)
#endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1902218159

From kbarrett at openjdk.org  Sat Jan  4 10:04:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Jan 2025 10:04:46 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
Message-ID: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>

On Fri, 3 Jan 2025 16:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix %Ix to %zx.

Uses of `[U]INTX_FORMAT_X` have been replaced with `0x%zx`.  I mentioned the
possibility of instead using `%#zx`.  I don't know if we really want to use some of
the (to me) more obscure flag options though.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1725:

> 1723:         ArrayOperationPartialInlineSize = MaxVectorSize >= 16 ? MaxVectorSize : 0;
> 1724:         if (ArrayOperationPartialInlineSize) {
> 1725:           warning("Setting ArrayOperationPartialInlineSize as MaxVectorSize%zd)", MaxVectorSize);

pre-existing: seems like there should be a separator of some kind between "MaxVectorSize" and the
value, either a space or an "=" would be okay.

src/hotspot/os/linux/os_linux.cpp line 1370:

> 1368: 
> 1369: #define _UFM "%zu"
> 1370: #define _DFM "%zd"

Why not get rid of these?

src/hotspot/share/ci/ciMethodData.cpp line 788:

> 786:     // which makes comparing it with the SA version of this output
> 787:     // harder. data()'s element type is intptr_t.
> 788:     out->print(" 0x%zx", data()[i]);

Could instead use " %#zx".

src/hotspot/share/compiler/disassembler.cpp line 600:

> 598:         st->print("Stub::%s", desc->name());
> 599:         if (desc->begin() != adr) {
> 600:           st->print("%+zd " PTR_FORMAT, adr - desc->begin(), p2i(adr));

Oh, that's an interesting "abuse" of the `_W` variant.

src/hotspot/share/gc/shared/ageTable.cpp line 38:

> 36: #include "logging/logStream.hpp"
> 37: 
> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.

Well this is weird.  An atypical copyright down inside the file?

src/hotspot/share/oops/instanceKlass.cpp line 3695:

> 3693: 
> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();

Should be using "zx" rather than "zu".   I think this could be written as 
`"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
That's looking a lot like line noise though.  I think this and ones like it probably ought not be
changed at all.

src/hotspot/share/oops/klass.cpp line 1308:

> 1306:   if (secondary_supers() != nullptr) {
> 1307:     st->print("  - "); st->print("%d elements;", _secondary_supers->length());
> 1308:     st->print_cr(" bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap);

Same as in instanceKlass - maybe this shouldn't be changed at all.

src/hotspot/share/utilities/globalDefinitions.hpp line 156:

> 154: #define UINTX_FORMAT_X_0         "0x%016"     PRIxPTR
> 155: #else
> 156: #define UINTX_FORMAT_X_0         "0x%08"      PRIxPTR

As noted in places where it's used, I'm not sure we should remove and replace UINTX_FORMAT_X_0.

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:

> 279: 
> 280:   check_format("%zd",                  (intx)123,         "123");
> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");

Could be "%#zx".

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 286:

> 284: 
> 285:   check_format("%zu",                  (uintx)123u,       "123");
> 286:   check_format("0x%zx",                (uintx)0x123u,     "0x123");

Could be "%#zx".

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2530503795
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902879593
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902886743
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902972028
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902912020
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902916165
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902944144
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902945394
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902960940
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902965078
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902966477

From kbarrett at openjdk.org  Sat Jan  4 10:17:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Jan 2025 10:17:35 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v3]
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <Bi4JLgn18QAQThG8Qd1JHD9UQ7Svb2atztDP3ayR67s=.46ba7346-58b0-4775-9784-e5b7d3d97b00@github.com>

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into new-poison
 - update copyrights
 - tidy comment
 - drop plural in permit_forbidden_functions namespace
 - new workarounds for platform issues
 - forbid windows _snprintf
 - new poisoning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22890/files
  - new: https://git.openjdk.org/jdk/pull/22890/files/e2a63247..77a80170

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

  Stats: 450 lines in 48 files changed: 135 ins; 175 del; 140 mod
  Patch: https://git.openjdk.org/jdk/pull/22890.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22890/head:pull/22890

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

From kbarrett at openjdk.org  Sat Jan  4 10:22:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Jan 2025 10:22:35 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <12-_FKsXl3OOujKaHQewgKdDUi95q9M0fSmuLeo6_Wg=.1ec72306-698f-42f8-86b7-e53bc711fde6@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <12-_FKsXl3OOujKaHQewgKdDUi95q9M0fSmuLeo6_Wg=.1ec72306-698f-42f8-86b7-e53bc711fde6@github.com>
Message-ID: <WycXWrpkTQZ0R8uZFiPv-9WAauOMx_1QZ2i4n4Sreyw=.0d68a0f6-eddf-4902-b052-ffcdeefa6ed6@github.com>

On Thu, 2 Jan 2025 22:19:00 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Unfortunately, this doesn't compile on AIX:
> 
> ```
> globalDefinitions_gcc.hpp:42:
> In file included from /opt/IBM/openxlC/17.1.1/bin/../include/c++/v1/stdlib.h:93:
> /usr/include/stdlib.h:304:18: error: 'noreturn' attribute does not appear on the first declaration
>         extern _NOTHROW(_NORETURN(void, exit), (int));
>                         ^
> /usr/include/comp_macros.h:30:35: note: expanded from macro '_NORETURN'
> #define _NORETURN(_T, _F) _T _F [[noreturn]]
>                                   ^
>    ... (rest of output omitted)
> ```

Thanks for testing that port.

I restructured the implementation of FORBID_C_FUNCTION, and added more commentary about the clang issue.
I think that didn't change the resulting expansion, but I think made it easier to describe how I tried to address this
problem.  The actual "solution" (I hope) is to ensure that <stdlib.h> is included before the forbidding declarations
for the noreturn functions.  Please try an aix build again.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2571149222

From kbarrett at openjdk.org  Sat Jan  4 10:28:36 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Jan 2025 10:28:36 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <5JjsCtkAmOXUdGJjqvcgsek8ft_XlaIw2iLM_mgqFj8=.16d96a5f-a005-4340-81a9-653b52572a8a@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <5JjsCtkAmOXUdGJjqvcgsek8ft_XlaIw2iLM_mgqFj8=.16d96a5f-a005-4340-81a9-653b52572a8a@github.com>
Message-ID: <PuuQ6dLar1EO0HWQfRT3kF5hcMX4GKtwO-LoMOhC5eU=.04566f6d-a27f-4a28-b0b5-bc7f5eda6c48@github.com>

On Fri, 3 Jan 2025 13:24:53 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> I really like the syntactic change of this feature, and it's very nice that we get to have working auto-complete (makes it easier to find out that a specific function isn't forbidden). The syntactic change isn't shown in the PR description, isn't that useful to add?

Isn't the last paragraph of the PR description (beginning with "Some of the poisoned functions...") what your are
looking for?  Admittedly I didn't mention working with auto-complete as one of the benefits.

> I have a bike shedding request: Could we skip the S at the end and have it be `permit_forbidden_function::free(my_ptr);`? We only allow one forbidden function in that call, so this reads neater.

I named it as a collection of forbidden functions.  But I agree it reads better without the plural, so I've removed the S.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2571175973

From kbarrett at openjdk.org  Sat Jan  4 10:36:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Jan 2025 10:36:35 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
Message-ID: <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>

On Fri, 3 Jan 2025 22:42:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/forbiddenFunctions.hpp line 33:
>> 
>>> 31: #include <stddef.h> // for size_t
>>> 32: 
>>> 33: #include OS_HEADER(forbiddenFunctions)
>> 
>> I thought there was an OS_VARIANT_HEADER to dispatch directly to the posix variant, but I guess it doesn't exist.  Using the semaphore example, this could save your dispatch header files, at the cost of an #ifdef.  Not sure which is worse:
>> 
>> 
>> #if defined(LINUX) || defined(AIX)
>> # include "semaphore_posix.hpp"
>> #else
>> # include OS_HEADER(semaphore)
>> #endif
>
> park.hpp has the same:
> 
> 
> #if defined(LINUX) || defined(AIX) || defined(BSD)
> # include "park_posix.hpp"
> #else
> # include OS_HEADER(park)
> #endif

If I was going to go that route, I'd be more inclined toward

#if !define(_WINDOWS)
#include "forbiddenFunctions_windows.hpp"
#else
#include "forbiddenFunctions_posix.hpp"
#endif

rather than list all (or maybe just a subset) of the posix-like ports.  My
inclination is to leave it as-is with OS_HEADERS, since I think that's the
"intended" idiom.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1903054016

From mdoerr at openjdk.org  Sun Jan  5 14:55:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sun, 5 Jan 2025 14:55:38 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <WycXWrpkTQZ0R8uZFiPv-9WAauOMx_1QZ2i4n4Sreyw=.0d68a0f6-eddf-4902-b052-ffcdeefa6ed6@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <12-_FKsXl3OOujKaHQewgKdDUi95q9M0fSmuLeo6_Wg=.1ec72306-698f-42f8-86b7-e53bc711fde6@github.com>
 <WycXWrpkTQZ0R8uZFiPv-9WAauOMx_1QZ2i4n4Sreyw=.0d68a0f6-eddf-4902-b052-ffcdeefa6ed6@github.com>
Message-ID: <RSDGosec3ekGX_EoXtcR8PNxRtFRS4Miw166vDIOioQ=.3f3b8753-d961-4cd8-ac26-33bc6016e816@github.com>

On Sat, 4 Jan 2025 10:19:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Unfortunately, this doesn't compile on AIX:
> > ```
> > globalDefinitions_gcc.hpp:42:
> > In file included from /opt/IBM/openxlC/17.1.1/bin/../include/c++/v1/stdlib.h:93:
> > /usr/include/stdlib.h:304:18: error: 'noreturn' attribute does not appear on the first declaration
> >         extern _NOTHROW(_NORETURN(void, exit), (int));
> >                         ^
> > /usr/include/comp_macros.h:30:35: note: expanded from macro '_NORETURN'
> > #define _NORETURN(_T, _F) _T _F [[noreturn]]
> >                                   ^
> >    ... (rest of output omitted)
> > ```
> 
> Thanks for testing that port.
> 
> I restructured the implementation of FORBID_C_FUNCTION, and added more commentary about the clang issue. I think that didn't change the resulting expansion, but I think made it easier to describe how I tried to address this problem. The actual "solution" (I hope) is to ensure that <stdlib.h> is included before the forbidding declarations for the noreturn functions. Please try an aix build again.

Thanks! This has solved one of the problems, but not all. The next one is:

globalDefinitions_gcc.hpp:55:
In file included from /usr/include/fcntl.h:242:
/usr/include/unistd.h:181:8: error: 'noreturn' attribute does not appear on the first declaration
extern _NORETURN(void, _exit)(int);
       ^
/usr/include/comp_macros.h:30:35: note: expanded from macro '_NORETURN'
#define _NORETURN(_T, _F) _T _F [[noreturn]]

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2571652508

From kbarrett at openjdk.org  Sun Jan  5 22:16:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 5 Jan 2025 22:16:35 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <RSDGosec3ekGX_EoXtcR8PNxRtFRS4Miw166vDIOioQ=.3f3b8753-d961-4cd8-ac26-33bc6016e816@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <12-_FKsXl3OOujKaHQewgKdDUi95q9M0fSmuLeo6_Wg=.1ec72306-698f-42f8-86b7-e53bc711fde6@github.com>
 <WycXWrpkTQZ0R8uZFiPv-9WAauOMx_1QZ2i4n4Sreyw=.0d68a0f6-eddf-4902-b052-ffcdeefa6ed6@github.com>
 <RSDGosec3ekGX_EoXtcR8PNxRtFRS4Miw166vDIOioQ=.3f3b8753-d961-4cd8-ac26-33bc6016e816@github.com>
Message-ID: <pR3PxkPq2G2sA-VWvtznTFFEEbH0bKGvX6Pu1cpUdxs=.135d0207-8a53-45de-bbeb-19e48d91e80c@github.com>

On Sun, 5 Jan 2025 14:53:01 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks! This has solved one of the problems, but not all. The next one is:
> 
> ```
> globalDefinitions_gcc.hpp:55:
> In file included from /usr/include/fcntl.h:242:
> /usr/include/unistd.h:181:8: error: 'noreturn' attribute does not appear on the first declaration
> extern _NORETURN(void, _exit)(int);
>        ^

Drat.  I forgot that posix _exit comes from unistd.h.  Back to work...

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2571767901

From dholmes at openjdk.org  Mon Jan  6 01:38:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 01:38:47 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
Message-ID: <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>

On Sat, 4 Jan 2025 10:33:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> park.hpp has the same:
>> 
>> 
>> #if defined(LINUX) || defined(AIX) || defined(BSD)
>> # include "park_posix.hpp"
>> #else
>> # include OS_HEADER(park)
>> #endif
>
> If I was going to go that route, I'd be more inclined toward
> 
> #if !define(_WINDOWS)
> #include "forbiddenFunctions_windows.hpp"
> #else
> #include "forbiddenFunctions_posix.hpp"
> #endif
> 
> rather than list all (or maybe just a subset) of the posix-like ports.  My
> inclination is to leave it as-is with OS_HEADERS, since I think that's the
> "intended" idiom.

Overall I like this change. I appreciate the effort that has been put in to try and find an elegant solution to this problem.

but having OS specific files created just to include the posix version runs counter to why we have the posix variants in the first place IMO. Please select one of the above approaches so that the new aix/bsd/linux specific files can be removed in favour of the posix one. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1903399996

From dholmes at openjdk.org  Mon Jan  6 04:00:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 04:00:39 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
Message-ID: <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>

On Fri, 3 Jan 2025 22:00:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix more copyrights.

src/hotspot/share/ci/ciFlags.cpp line 95:

> 93: // ciFlags::print
> 94: void ciFlags::print(outputStream* st) {
> 95:   st->print(" flags=%x", _flags.as_unsigned_short());

Here, and elsewhere, are we relying on an implicit widening of the u2 result to int so that the format specifier is correct?

src/hotspot/share/ci/ciFlags.hpp line 71:

> 69: 
> 70:   // Conversion
> 71:   jint   as_int()                      { return _flags.as_unsigned_short(); }

It is unclear to me whether the fact we are dealing with u2 should be exposed in this API as well.

src/hotspot/share/ci/ciKlass.cpp line 225:

> 223:   assert(is_loaded(), "not loaded");
> 224:   GUARDED_VM_ENTRY(
> 225:     return get_Klass()->access_flags().as_unsigned_short();

Again it is unclear to me whether this API should also now return u2.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1003:

> 1001:     JVMCI_ERROR_NULL("info must not be null and have a length of 4");
> 1002:   }
> 1003:   JVMCIENV->put_int_at(info, 0, fd.access_flags().as_unsigned_short());

Again are we relying on implicit widening from u2 to int?

It really isn't clear to me whether the only thing we should have changed here is the actual type of the `_flags` field and let everything else continue to represent flags as int, so we don't get these transitions from u2 to int  in these higher level APIs.

src/hotspot/share/jvmci/jvmciEnv.cpp line 1595:

> 1593:     HotSpotJVMCI::FieldInfo::set_signatureIndex(JVMCIENV, obj_h(), (jint)fieldinfo->signature_index());
> 1594:     HotSpotJVMCI::FieldInfo::set_offset(JVMCIENV, obj_h(), (jint)fieldinfo->offset());
> 1595:     HotSpotJVMCI::FieldInfo::set_classfileFlags(JVMCIENV, obj_h(), (jint)fieldinfo->access_flags().as_unsigned_short());

I'm curious why we need the explicit cast here - is it because we are going from unsigned to signed?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/AccessFlags.java line 82:

> 80:   public int getStandardFlags() {
> 81:     return (int)flags;
> 82:   }

This function seems unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903619988
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903621196
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903621733
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903624061
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903624365
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903619429

From dholmes at openjdk.org  Mon Jan  6 05:02:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 05:02:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
Message-ID: <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>

On Mon, 23 Dec 2024 15:26:13 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments, remove unneeded ifdef, remove typo

In case my comment within the existing conversations gets missed I will re-state that I don't think you need any new "is bootstrapping" logic because you can just use `Threads::number_of_threads() > 0` to tell you if you need to acquire the NMT lock. Though that assumes that the `WatcherThread` does not use NMT ... but in that case you can use `WatcherThread::watcher_thread() != nullptr` as the bootstrap condition instead.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2531327078

From dholmes at openjdk.org  Mon Jan  6 06:21:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 06:21:37 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v2]
In-Reply-To: <fiZAIh_ms_gL7r5_KClBPISG-OE2CQI0MRivcZDVi3Y=.b5b443a2-3e83-4b9b-b1ad-c33f4c538e74@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <fiZAIh_ms_gL7r5_KClBPISG-OE2CQI0MRivcZDVi3Y=.b5b443a2-3e83-4b9b-b1ad-c33f4c538e74@github.com>
Message-ID: <vI9uVfk-fbBeeh-qRip2v6hGVyNjnINVWBoPGuu-gMg=.274f3c10-a650-416a-857b-ec3681aad19e@github.com>

On Thu, 2 Jan 2025 19:14:56 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine jtreg tags per review

Changes requested by dholmes (Reviewer).

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 45:

> 43: 
> 44: /*
> 45:  * @test id=normal

The normal test should be for non-ZGC otherwise in a test config that runs everything with ZGC you will run them both when only one is needed

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

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2531420841
PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1903716217

From dholmes at openjdk.org  Mon Jan  6 06:26:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 06:26:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <Sku5_RiFCfq5hUWlIPyPuShlTEkUjy1puhFyRXD-3PM=.22b1336d-2876-41dd-bb9e-8384c84983ba@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

LGTM2.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2531429430

From qxing at openjdk.org  Mon Jan  6 06:26:47 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Mon, 6 Jan 2025 06:26:47 GMT
Subject: Integrated: 8346773: Fix unmatched brackets in some misc files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <MGlZQfhGaTFiQzpqY86SF5FGLMjKbQ9ibj_l678R8Os=.25c31ede-ade3-4e04-ace9-f69db071d95a@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.

This pull request has now been integrated.

Changeset: f1d85ab3
Author:    Qizheng Xing <qxing at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1d85ab3e61f923b4e120cf30e16109e04505b53
Stats:     10 lines in 7 files changed: 0 ins; 0 del; 10 mod

8346773: Fix unmatched brackets in some misc files

Reviewed-by: kbarrett, alanb, rriggs, dholmes, erikj, liach

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

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

From chagedorn at openjdk.org  Mon Jan  6 08:04:41 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 6 Jan 2025 08:04:41 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v6]
In-Reply-To: <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <cXdpBgPRQxzwpFQSEuZ0rAUAaVulvZrj-zvDQ6VPnA0=.467ae22b-5407-4d7a-8f19-b99913e76436@github.com>
Message-ID: <9ogW7JTivr-VWBsUsdnewxvlixsPxS87eL17mOvAVVY=.513f6aa3-5afd-4c65-b07d-5c9ea9fc6396@github.com>

On Thu, 2 Jan 2025 03:11:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR use function `guarantee` instead of 'write a byte to nullptr' to trigger the expected jvm crash, risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate CrashGCForDumpingJavaThread check

Just as a side note, the idea of `TestDwarf.java` was to reliably crash the VM with as many different stack traces as possible - it does not really matter how the VM crashes.This gets us some sanity testing for the DWARF parser.

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

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2572509002

From shade at openjdk.org  Mon Jan  6 12:05:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 6 Jan 2025 12:05:12 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
Message-ID: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>

**NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**

My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.

This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.

Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.

The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.

x86_32 is the only platform that has special cases for x87 FPU.

C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.

Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.

x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.

The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainline, so I would like to do it separately as the follow-up.

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

Commit messages:
 - More cleanups/reversals
 - More FPU cleanups in C1 regalloc
 - More touchups
 - Fix more backsliding LP64 in Assembler
 - Revert accidental removal in C1 regalloc
 - C1: Cleanup dead lir_f stack ops
 - Cleanup more FPU-related stuff
 - Remove rounding code from C1 and template interpreter
 - Purge 32-bit specific rounding mode
 - OS cleanup
 - ... and 9 more: https://git.openjdk.org/jdk/compare/f1d85ab3...b55fc750

Changes: https://git.openjdk.org/jdk/pull/22567/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345169
  Stats: 40692 lines in 213 files changed: 33 ins; 39906 del; 753 mod
  Patch: https://git.openjdk.org/jdk/pull/22567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22567/head:pull/22567

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

From coleenp at openjdk.org  Mon Jan  6 13:46:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 13:46:40 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
 <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
Message-ID: <kz-6hL6KLP6tRXZWVBrhM5d3cOXmx5GhJOTqDpLR6po=.37fedf6e-85de-4553-b2cc-b1862b01e896@github.com>

On Mon, 6 Jan 2025 03:44:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix more copyrights.
>
> src/hotspot/share/ci/ciFlags.cpp line 95:
> 
>> 93: // ciFlags::print
>> 94: void ciFlags::print(outputStream* st) {
>> 95:   st->print(" flags=%x", _flags.as_unsigned_short());
> 
> Here, and elsewhere, are we relying on an implicit widening of the u2 result to int so that the format specifier is correct?

Yes, we are.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904168828

From sroy at openjdk.org  Mon Jan  6 13:49:37 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Jan 2025 13:49:37 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm
In-Reply-To: <Q0Gew_GeNQLcwFQAZ3eiisUOCBMaAv8mHLpQOvSHSsM=.142a184c-5b17-4eef-8c74-497cb26c4635@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <Q0Gew_GeNQLcwFQAZ3eiisUOCBMaAv8mHLpQOvSHSsM=.142a184c-5b17-4eef-8c74-497cb26c4635@github.com>
Message-ID: <OLTgdc5PHMOe6eHPcYEnoWwDs9M-7GNrjECmO-KeKuA=.bf2a5bd0-5067-471a-8a00-01527af1931b@github.com>

On Fri, 20 Dec 2024 17:14:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 686:
> 
>> 684:   Label L_end, L_aligned;
>> 685: 
>> 686:   static const unsigned char perm_pattern[16] __attribute__((aligned(16))) = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15};
> 
> This pattern can be produced by `lvsl`. Loading it from memory is not needed.

Hi @TheRealMDoerr  

I had tried something like 
 __ lvsl(loadOrder, 0);
 
 This generated a pattern as below 
 {0xf, 0xe, 0xd, 0xc, 0xb, 0xa, 0x9, 0x8, 0x7, 0x6, 0x5, 0x4, 0x3, 
    0x2, 0x1, 0x0}}
 This causes the the data to be loaded into vector in wrong order. 
 
 The desired pattern is    {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15} 
 
 Since the data is stored in bytes and we don't have lxvb16x in power8, the pattern has to be enforced. 
 
 Is there a better way  to do this ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1904171740

From coleenp at openjdk.org  Mon Jan  6 14:12:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 14:12:57 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
 <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
Message-ID: <Smg6Y1T71YK2CbadjB67kWZS05cXCecGZFCI2KZmbOY=.04893819-ba04-482f-826b-04ddd7381cce@github.com>

On Mon, 6 Jan 2025 03:47:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix more copyrights.
>
> src/hotspot/share/ci/ciFlags.hpp line 71:
> 
>> 69: 
>> 70:   // Conversion
>> 71:   jint   as_int()                      { return _flags.as_unsigned_short(); }
> 
> It is unclear to me whether the fact we are dealing with u2 should be exposed in this API as well.

I don't think it should be.

> src/hotspot/share/ci/ciKlass.cpp line 225:
> 
>> 223:   assert(is_loaded(), "not loaded");
>> 224:   GUARDED_VM_ENTRY(
>> 225:     return get_Klass()->access_flags().as_unsigned_short();
> 
> Again it is unclear to me whether this API should also now return u2.

I don't think it should.  I think the boundary of where we promote the u2 to int should be at this API.  If those working on the compiler code would like to propagate the size of the storage (u2) around, they can decide to do that.

> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1003:
> 
>> 1001:     JVMCI_ERROR_NULL("info must not be null and have a length of 4");
>> 1002:   }
>> 1003:   JVMCIENV->put_int_at(info, 0, fd.access_flags().as_unsigned_short());
> 
> Again are we relying on implicit widening from u2 to int?
> 
> It really isn't clear to me whether the only thing we should have changed here is the actual type of the `_flags` field and let everything else continue to represent flags as int, so we don't get these transitions from u2 to int  in these higher level APIs.

Yes, we can widen u2 to int.  See above.  The ci code represents the integral value of access flags as jint.  I am leaving that API in place.  For this, the widening happens when fetching the u2 field.  The conversion is implicit.  If this field were to be stored back to a u2 somewhere, all the code in the compiler should change but the current code doesn't do that.

> src/hotspot/share/jvmci/jvmciEnv.cpp line 1595:
> 
>> 1593:     HotSpotJVMCI::FieldInfo::set_signatureIndex(JVMCIENV, obj_h(), (jint)fieldinfo->signature_index());
>> 1594:     HotSpotJVMCI::FieldInfo::set_offset(JVMCIENV, obj_h(), (jint)fieldinfo->offset());
>> 1595:     HotSpotJVMCI::FieldInfo::set_classfileFlags(JVMCIENV, obj_h(), (jint)fieldinfo->access_flags().as_unsigned_short());
> 
> I'm curious why we need the explicit cast here - is it because we are going from unsigned to signed?

The casts were all there for all these fields, so I left it.  It is unnecessary but matches the style of the preceding lines.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/AccessFlags.java line 82:
> 
>> 80:   public int getStandardFlags() {
>> 81:     return (int)flags;
>> 82:   }
> 
> This function seems unused.

Ah thanks.  Another SA function to remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904197071
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904190829
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904193482
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904194643
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904195078

From coleenp at openjdk.org  Mon Jan  6 14:12:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 14:12:56 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <kz-6hL6KLP6tRXZWVBrhM5d3cOXmx5GhJOTqDpLR6po=.37fedf6e-85de-4553-b2cc-b1862b01e896@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
 <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
 <kz-6hL6KLP6tRXZWVBrhM5d3cOXmx5GhJOTqDpLR6po=.37fedf6e-85de-4553-b2cc-b1862b01e896@github.com>
Message-ID: <iPmg1WAKVjyUS87dsewJWb5nsEOkb5RelyO1O5Q7qn8=.bf2049d0-4fae-4364-91c7-463acdeefc5c@github.com>

On Mon, 6 Jan 2025 13:44:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/ci/ciFlags.cpp line 95:
>> 
>>> 93: // ciFlags::print
>>> 94: void ciFlags::print(outputStream* st) {
>>> 95:   st->print(" flags=%x", _flags.as_unsigned_short());
>> 
>> Here, and elsewhere, are we relying on an implicit widening of the u2 result to int so that the format specifier is correct?
>
> Yes, we are.

I had a little experiment.

extern "C" int printf(const char *,...);
int main() {
  unsigned short ss = 0x8000;
  printf("does unsigned sign extend to int? %d\n", int(ss));
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904172191

From coleenp at openjdk.org  Mon Jan  6 14:12:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 14:12:56 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v12]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

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

  Remove unused SA function.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/82bd1a24..d43b2fac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=10-11

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

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

From coleenp at openjdk.org  Mon Jan  6 15:09:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:18 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v3]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <v-l_S89jSVDIGrgoEHbJG3MGPELL_w4CYjPS2vE7lFc=.6a1fb33c-f2ba-48c6-a3d1-fe4463a492dd@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

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

  Fixed some code review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/1748797a..15b1052a

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

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

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

From coleenp at openjdk.org  Mon Jan  6 15:09:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
Message-ID: <3vQ-kxRahCEhGLRshu6KE_0ZkWCnrgtnyx8cbXsPIeE=.24a34a54-28b0-4202-8ea3-6bd2b7325ce3@github.com>

On Fri, 3 Jan 2025 16:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix %Ix to %zx.

Kim, thanks for slogging through this change.  I've updated the patch with your suggested changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2573301941

From coleenp at openjdk.org  Mon Jan  6 15:09:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>

On Sat, 4 Jan 2025 09:02:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> src/hotspot/os/linux/os_linux.cpp line 1370:
> 
>> 1368: 
>> 1369: #define _UFM "%zu"
>> 1370: #define _DFM "%zd"
> 
> Why not get rid of these?

Fixed.

> src/hotspot/share/gc/shared/ageTable.cpp line 38:
> 
>> 36: #include "logging/logStream.hpp"
>> 37: 
>> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.
> 
> Well this is weird.  An atypical copyright down inside the file?

This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.

> src/hotspot/share/oops/instanceKlass.cpp line 3695:
> 
>> 3693: 
>> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
>> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();
> 
> Should be using "zx" rather than "zu".   I think this could be written as 
> `"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
> That's looking a lot like line noise though.  I think this and ones like it probably ought not be
> changed at all.

I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904264225
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904264062
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904263162

From coleenp at openjdk.org  Mon Jan  6 15:24:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:24:18 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v4]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <TL-PdaGpWb-cAJFmKJrMKkNy1L5wkbFZFxU1Kt0_KkY=.d541d19d-0014-4be1-88c5-fab6e1f76c3b@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

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

  Use INTPTR_FORMAT instead of zu for secondary_supers_bitmap.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/15b1052a..6e8b2702

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

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

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

From coleenp at openjdk.org  Mon Jan  6 15:24:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:24:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
Message-ID: <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>

On Mon, 6 Jan 2025 15:03:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 3695:
>> 
>>> 3693: 
>>> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
>>> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();
>> 
>> Should be using "zx" rather than "zu".   I think this could be written as 
>> `"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
>> That's looking a lot like line noise though.  I think this and ones like it probably ought not be
>> changed at all.
>
> I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.

@theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904284828

From coleenp at openjdk.org  Mon Jan  6 16:02:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 16:02:36 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <XNMHk0Rh8KL4VxuqCHjK7agSagK9tG2hgXWm1_l8lEg=.72ef1aa2-5d33-4add-93af-291c969c418f@github.com>

On Sat, 4 Jan 2025 09:52:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:
> 
>> 279: 
>> 280:   check_format("%zd",                  (intx)123,         "123");
>> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");
> 
> Could be "%#zx".

I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904331779

From coleenp at openjdk.org  Mon Jan  6 16:14:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 16:14:45 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER
Message-ID: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>

This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
GHA tested.

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

Commit messages:
 - Maybe this is better.
 - 8329549: Remove FORMAT64_MODIFIER

Changes: https://git.openjdk.org/jdk/pull/22918/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22918&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329549
  Stats: 27 lines in 5 files changed: 6 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22918/head:pull/22918

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

From sspitsyn at openjdk.org  Mon Jan  6 17:10:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 6 Jan 2025 17:10:39 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v12]
In-Reply-To: <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
Message-ID: <dpp8tNlLHaGLazlY_aNMZoTltHm0ESrZHqTs8ONilRE=.fffcccd5-65a8-4a6a-8289-b1784c7e4862@github.com>

On Mon, 6 Jan 2025 14:12:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused SA function.

Thank you for update with this an unification!
I've posted a couple of comments with similar nits.

src/hotspot/share/interpreter/linkResolver.cpp line 586:

> 584:     // We need to change "protected" to "public".
> 585:     assert(flags.is_protected(), "clone not protected?");
> 586:     u2 new_flags = flags.as_unsigned_short();

Nit: Should this also be replaced with `as_method_flags()`?

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

> 1983:     // The field is Klass::_access_flags.  Return its (constant) value.
> 1984:     // (Folds up the 2nd indirection in Reflection.getClassAccessFlags(aClassConstant).)
> 1985:     assert(this->Opcode() == Op_LoadUS, "must load an unsigned short from _access_flags");

Nit: This can be unified with line 1979 and also get rid of `this->`.

src/hotspot/share/prims/jvm.cpp line 2472:

> 2470:   u2 field_access_flags = InstanceKlass::cast(k)->field_access_flags(field_index);
> 2471:   // This & should be unnecessary.
> 2472:   assert((field_access_flags & JVM_RECOGNIZED_FIELD_MODIFIERS) == field_access_flags, "already masked");

Nit: Yes, it is better to remove the lines: 2471-2472.

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

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2532540668
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904386978
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904405970
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904404626

From pchilanomate at openjdk.org  Mon Jan  6 17:42:09 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 6 Jan 2025 17:42:09 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() || stub_caller)
 failed: expected a stub-caller
Message-ID: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>

Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.

Thanks,
Patricio

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

Commit messages:
 - v1

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

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

From kvn at openjdk.org  Mon Jan  6 17:49:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 6 Jan 2025 17:49:41 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <OqTXjfuLeIUD5nqAmvpWrg9j3BeoiEYIDYo6eLRXNOw=.ac26d63d-2b17-4922-86d3-611e89d357df@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

> The one thing I deliberately avoided doing is merging x86.ad and x86_64.ad.

I think we can keep them separate (big .ad files is difficult to navigate). `x86.ad` is mostly used for vector instructions. We can rename it to ``x86_vect.ad`. And `x86_64.ad` to `x86.ad`. As followup changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2573606824

From kvn at openjdk.org  Mon Jan  6 17:53:35 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 6 Jan 2025 17:53:35 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <dBWI2eJzlouB0kRQK7prMGpBggiV4qoVyHWt5GEW5Wo=.4667adc1-75f9-41b3-bd9e-193cfb6fb186@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

I don't see make files changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2573613772

From kvn at openjdk.org  Mon Jan  6 18:01:50 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 6 Jan 2025 18:01:50 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <go_2UNDvI1vayb7ZtNRLArUlXTunyywmKuwG0PeqGuY=.d922b540-7ef6-486a-8a4b-18accf6d2176@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

It would be nice to split this into separate PRs for easy review. Removing "rounding of x87 FPU" could be definitely done separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2573626448

From duke at openjdk.org  Mon Jan  6 19:21:38 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 6 Jan 2025 19:21:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
 <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
Message-ID: <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>

On Mon, 6 Jan 2025 05:00:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> In case my comment within the existing conversations gets missed I will re-state that I don't think you need any new "is bootstrapping" logic because you can just use `Threads::number_of_threads() > 0` to tell you if you need to acquire the NMT lock. Though that assumes that the `WatcherThread` does not use NMT ... but in that case you can use `WatcherThread::watcher_thread() != nullptr` as the bootstrap condition instead.

I think that the `WatcherThread` does use NMT (at least upon starting), since `Thread::call_run() ` calls `register_thread_stack_with_NMT()`. However, it looks like `WatcherThread::stop()` is called early in `before_exit` -- after which point NMT can still  be used. So checking `WatcherThread::watcher_thread() != nullptr` may not work in this case as it could be set back to nullptr too early.

Another solution might be to introduce something like `Threads::is_single_threaded()` which checks for  `WatcherThread`, `Threads::number_of_threads()`, and any other threads that fall outside this set. I'm not sure whether that would be better than the current approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2573756615

From dholmes at openjdk.org  Mon Jan  6 21:22:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 21:22:36 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <txGcUNxJa5bkZiI8TOKjaTPY02FVBbXXd27l9X7IDeg=.5958522a-4bed-4faa-b452-0e6ab63093aa@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

Looks good to me. Thanks for the detailed analysis.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22931#pullrequestreview-2532992481

From dholmes at openjdk.org  Mon Jan  6 21:33:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 21:33:36 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER
In-Reply-To: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
Message-ID: <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>

On Fri, 3 Jan 2025 17:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
> GHA tested.

src/hotspot/share/utilities/globalDefinitions.hpp line 136:

> 134: 
> 135: // Format without leading 0x
> 136: #define INT64_FORMAT_X_0_        "%016"       PRIx64

Why the trailing underscore?

The name doesn't make sense to me given we have UINT64_FORMAT_X_0 and the only difference here is the leading `0x` which doesn't really have anything to do with signed-ness. Maybe `RAW_UINT64_FORMAT_X_0` to indicate the dropped `0x` prefix ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1904656899

From amenkov at openjdk.org  Tue Jan  7 01:08:34 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 7 Jan 2025 01:08:34 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <0mDCq1sgRxClxhFMlEaMQ7gGS3FYpdE0YG8gFx8o-pY=.09ca389d-c5bc-4412-bb86-23072b03b72c@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22931#pullrequestreview-2533212184

From dholmes at openjdk.org  Tue Jan  7 02:20:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 02:20:40 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v12]
In-Reply-To: <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
Message-ID: <ecI3DkqeGCxK7E_fIxTgB7xliqBShOXxu_5zHUMCB6g=.699b4ece-9bd1-46e4-af78-483b901792d4@github.com>

On Mon, 6 Jan 2025 14:12:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused SA function.

I can't say that I really understand which API's are fine with flags-as-int and which need to care about the actual flag storage size. but I'll leave it at that. I will tick approve for the shared code portion of the change.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2533262347

From coleenp at openjdk.org  Tue Jan  7 02:30:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 02:30:49 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v12]
In-Reply-To: <dpp8tNlLHaGLazlY_aNMZoTltHm0ESrZHqTs8ONilRE=.fffcccd5-65a8-4a6a-8289-b1784c7e4862@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
 <dpp8tNlLHaGLazlY_aNMZoTltHm0ESrZHqTs8ONilRE=.fffcccd5-65a8-4a6a-8289-b1784c7e4862@github.com>
Message-ID: <ptC2BTpeVx3DHvfoMtnSF27uw7ar8xNz9fN3wty8z3o=.6e33f566-2ee8-4381-a430-e473c3eea65a@github.com>

On Mon, 6 Jan 2025 16:46:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused SA function.
>
> src/hotspot/share/interpreter/linkResolver.cpp line 586:
> 
>> 584:     // We need to change "protected" to "public".
>> 585:     assert(flags.is_protected(), "clone not protected?");
>> 586:     u2 new_flags = flags.as_unsigned_short();
> 
> Nit: Should this also be replaced with `as_method_flags()`?

Thanks Serguei, I replaced this one and a couple of as_field_flags() so that as_unsigned_short() is more limited to the cases where we don't want masking.

> src/hotspot/share/opto/memnode.cpp line 1985:
> 
>> 1983:     // The field is Klass::_access_flags.  Return its (constant) value.
>> 1984:     // (Folds up the 2nd indirection in Reflection.getClassAccessFlags(aClassConstant).)
>> 1985:     assert(this->Opcode() == Op_LoadUS, "must load an unsigned short from _access_flags");
> 
> Nit: This can be unified with line 1979 and also get rid of `this->`.

1979 and 1985 are in different branches of an if statement (address of modifier flags vs access flags) so needs to be repeated.  But I did remove the this->

> src/hotspot/share/prims/jvm.cpp line 2472:
> 
>> 2470:   u2 field_access_flags = InstanceKlass::cast(k)->field_access_flags(field_index);
>> 2471:   // This & should be unnecessary.
>> 2472:   assert((field_access_flags & JVM_RECOGNIZED_FIELD_MODIFIERS) == field_access_flags, "already masked");
> 
> Nit: Yes, it is better to remove the lines: 2471-2472.

fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904829376
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904830369
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904829864

From coleenp at openjdk.org  Tue Jan  7 02:36:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 02:36:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

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

  Make more AccessFlags fetches more specific and remove an assert and remove this->s.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/d43b2fac..35784c70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=11-12

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

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

From coleenp at openjdk.org  Tue Jan  7 02:39:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 02:39:34 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER
In-Reply-To: <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>
Message-ID: <COjHd9W5K-B7s2wF2IVGT_YiuLj4_ak1egEOcRdIC48=.4aff405a-1e9b-46c7-8679-6c24eaac89b7@github.com>

On Mon, 6 Jan 2025 21:30:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
>> GHA tested.
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 136:
> 
>> 134: 
>> 135: // Format without leading 0x
>> 136: #define INT64_FORMAT_X_0_        "%016"       PRIx64
> 
> Why the trailing underscore?
> 
> The name doesn't make sense to me given we have UINT64_FORMAT_X_0 and the only difference here is the leading `0x` which doesn't really have anything to do with signed-ness. Maybe `RAW_UINT64_FORMAT_X_0` to indicate the dropped `0x` prefix ?

Thanks for the suggestion.  All the macros start with UINT64_FORMAT though.  How about UINT64_FORMAT_RAW_X_0 ?  or UINT64_FORMAT_X_0_RAW ?  Still not great.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1904834800

From coleenp at openjdk.org  Tue Jan  7 02:47:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 02:47:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <NsIbHdXDhv6qsSp8Lt0S1hIMNipKFRDNCQ_8NI6SBBc=.bcfbec8c-9f81-4cc2-a1d9-327b7d274da2@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Thanks David.  I'm hoping @iwanowww or @dean-long  can review the compiler parts.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2574287163

From dlong at openjdk.org  Tue Jan  7 03:20:38 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Jan 2025 03:20:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <7RpN7gvi4yXmEGG03o8JTg68OzymPhL76j6ndM4JPe8=.f5bcf133-ae7f-4efb-8df4-f8f9d6423b2d@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Sure, I'll try to take a look at it tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2574313889

From dholmes at openjdk.org  Tue Jan  7 04:38:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 04:38:34 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER
In-Reply-To: <COjHd9W5K-B7s2wF2IVGT_YiuLj4_ak1egEOcRdIC48=.4aff405a-1e9b-46c7-8679-6c24eaac89b7@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>
 <COjHd9W5K-B7s2wF2IVGT_YiuLj4_ak1egEOcRdIC48=.4aff405a-1e9b-46c7-8679-6c24eaac89b7@github.com>
Message-ID: <WTkzmdbkAd7ihhWqfYi4rsEVjxBsf4GGGLMQV0s0Lq8=.c58e1323-e57a-4eeb-b197-6b08053dd010@github.com>

On Tue, 7 Jan 2025 02:37:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions.hpp line 136:
>> 
>>> 134: 
>>> 135: // Format without leading 0x
>>> 136: #define INT64_FORMAT_X_0_        "%016"       PRIx64
>> 
>> Why the trailing underscore?
>> 
>> The name doesn't make sense to me given we have UINT64_FORMAT_X_0 and the only difference here is the leading `0x` which doesn't really have anything to do with signed-ness. Maybe `RAW_UINT64_FORMAT_X_0` to indicate the dropped `0x` prefix ?
>
> Thanks for the suggestion.  All the macros start with UINT64_FORMAT though.  How about UINT64_FORMAT_RAW_X_0 ?  or UINT64_FORMAT_X_0_RAW ?  Still not great.

UINT64_FORMAT_RAW_X_0  is not terrible. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1904894822

From dholmes at openjdk.org  Tue Jan  7 04:38:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 04:38:35 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER
In-Reply-To: <WTkzmdbkAd7ihhWqfYi4rsEVjxBsf4GGGLMQV0s0Lq8=.c58e1323-e57a-4eeb-b197-6b08053dd010@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>
 <COjHd9W5K-B7s2wF2IVGT_YiuLj4_ak1egEOcRdIC48=.4aff405a-1e9b-46c7-8679-6c24eaac89b7@github.com>
 <WTkzmdbkAd7ihhWqfYi4rsEVjxBsf4GGGLMQV0s0Lq8=.c58e1323-e57a-4eeb-b197-6b08053dd010@github.com>
Message-ID: <xhg_uFNDY7rzIK0EL13nI-64mbTR6Bu0SbRgld9AZgk=.a0bcc2fd-1e58-46fb-b665-376092bc0db3@github.com>

On Tue, 7 Jan 2025 04:34:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks for the suggestion.  All the macros start with UINT64_FORMAT though.  How about UINT64_FORMAT_RAW_X_0 ?  or UINT64_FORMAT_X_0_RAW ?  Still not great.
>
> UINT64_FORMAT_RAW_X_0  is not terrible. :)

To be honest though I don't know why we want hexadecimal output without the leading 0x ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1904895282

From dholmes at openjdk.org  Tue Jan  7 04:43:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 04:43:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
 <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
 <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>
Message-ID: <BlJktc_h0m47MDOqZ47OOYX1fQmJTVfqQXE3ahJGcHI=.142785d4-cfb0-4a5a-935c-dcdff26bc8b9@github.com>

On Mon, 6 Jan 2025 19:19:23 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> However, it looks like `WatcherThread::stop()` is called early in `before_exit` -- after which point NMT can still be used. 

Yeah good catch. I just find it frustrating that we already have so many initialization-progress markers but we are looking at adding yet-another-one. Also I'm not sure this is really relevant to mutex itself per-se it is rather about whether mutexes are needed - to that end I don't find `Threads::is_single_threaded() ` a terrible suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2574379871

From vlivanov at openjdk.org  Tue Jan  7 06:13:48 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 7 Jan 2025 06:13:48 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <rm5SvqORaYvN5ulwdWzJYyZQn0NxO_EPZ0XMiLX3WKU=.4c834cf7-8195-49fd-882b-f68c0a0605ad@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2533455739

From vlivanov at openjdk.org  Tue Jan  7 06:13:48 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 7 Jan 2025 06:13:48 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <iPmg1WAKVjyUS87dsewJWb5nsEOkb5RelyO1O5Q7qn8=.bf2049d0-4fae-4364-91c7-463acdeefc5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
 <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
 <kz-6hL6KLP6tRXZWVBrhM5d3cOXmx5GhJOTqDpLR6po=.37fedf6e-85de-4553-b2cc-b1862b01e896@github.com>
 <iPmg1WAKVjyUS87dsewJWb5nsEOkb5RelyO1O5Q7qn8=.bf2049d0-4fae-4364-91c7-463acdeefc5c@github.com>
Message-ID: <Mzfi_xXZcz9uycuSgiIdkk42MB-oMgUY1d8qg0G0SSc=.b13cec7d-a742-4934-b393-13f31c01d191@github.com>

On Mon, 6 Jan 2025 13:47:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, we are.
>
> I had a little experiment.
> 
> extern "C" int printf(const char *,...);
> int main() {
>   unsigned short ss = 0x8000;
>   printf("does unsigned sign extend to int? %d\n", int(ss));
> }

IMO you could just call `as_int()` here. All other usages of `ciFlags::as_int()` are in printing code. 

Ideally, `ciField::print()` could use `ciFlags::print()`, but such cleanup can be done separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904950560

From dholmes at openjdk.org  Tue Jan  7 06:24:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 06:24:41 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

src/hotspot/share/interpreter/abstractInterpreter.cpp line 137:

> 135:       case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits;
> 136:       case vmIntrinsics::_longBitsToDouble:  return java_lang_Double_longBitsToDouble;
> 137:       case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits;

Why are these intrinsics for the Java methods disappearing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1904957718

From amitkumar at openjdk.org  Tue Jan  7 06:50:40 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 7 Jan 2025 06:50:40 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <H6U-zbxZRFs4GJGz2skoxWTtl4-QDbuLP_4E1XH2Qyc=.879a18fd-a950-4793-804b-d3c2831e4454@github.com>

On Wed, 25 Dec 2024 15:40:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

Looks good. Maybe update copyright header year.

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

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22881#pullrequestreview-2533502235

From kbarrett at openjdk.org  Tue Jan  7 08:34:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:34:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
Message-ID: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>

On Mon, 6 Jan 2025 15:04:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/ageTable.cpp line 38:
>> 
>>> 36: #include "logging/logStream.hpp"
>>> 37: 
>>> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.
>> 
>> Well this is weird.  An atypical copyright down inside the file?
>
> This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.

Not sure we're allowed to remove a copyright statement, even if not in the usual place.

>> test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:
>> 
>>> 279: 
>>> 280:   check_format("%zd",                  (intx)123,         "123");
>>> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");
>> 
>> Could be "%#zx".
>
> I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?

I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
prefix gets included in the width when dealing with field width, which might not be great either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905081061
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905079637

From kbarrett at openjdk.org  Tue Jan  7 08:34:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:34:42 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
Message-ID: <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>

On Mon, 6 Jan 2025 15:21:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.
>
> @theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.

I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
format directives that resemble line noise, or ugly conditionals like that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905076840

From lliu at openjdk.org  Tue Jan  7 08:50:41 2025
From: lliu at openjdk.org (Liming Liu)
Date: Tue, 7 Jan 2025 08:50:41 GMT
Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for
 Ampere-1A and 1B
In-Reply-To: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
References: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
Message-ID: <oYwuFwPFhKHdpGHpgk0bcIkk6CSRBItwLnZouku7UGs=.fdc4685f-feb1-429c-8340-1a164735f416@github.com>

On Fri, 15 Nov 2024 07:01:23 GMT, Liming Liu <lliu at openjdk.org> wrote:

> This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128.
> 
> Ran JTReg tier1 on Ampere-1A and no new issues were found.

Hi, @TobiHartmann, @vnkozlov, @dean-long,

Could you please take a look? Thanks in advance!

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

PR Comment: https://git.openjdk.org/jdk/pull/22134#issuecomment-2574711196

From kbarrett at openjdk.org  Tue Jan  7 08:52:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:52:42 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
 <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
Message-ID: <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>

On Tue, 7 Jan 2025 08:28:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.
>
> I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
> I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
> format directives that resemble line noise, or ugly conditionals like that.

Improving on my prior suggestion
`"%#.*zx", (2 * BytesPerWord), _secondary_supers_bitmap`
Using precision rather than field width, to avoid needing to account for the prefix in the width calculation.
But still looking a lot like line noise, and still think it shouldn't be changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905101674

From kbarrett at openjdk.org  Tue Jan  7 08:52:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:52:43 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
Message-ID: <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>

On Tue, 7 Jan 2025 08:31:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?
>
> I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
> prefix gets included in the width when dealing with field width, which might not be great either.

The problem of accounting for the prefix in the field width calculation can be dealt with by using precision
rather than field width.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905104428

From kbarrett at openjdk.org  Tue Jan  7 09:09:16 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 09:09:16 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v4]
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <mgaIxADi54AaczgDWzqFm3WUzMu2tqApcxrZ2oh_4Mc=.1e792b0f-89a8-460e-a96b-6cb0f6f74a3a@github.com>

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  more fixes for clang noreturn issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22890/files
  - new: https://git.openjdk.org/jdk/pull/22890/files/77a80170..c478bda1

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

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

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

From shade at openjdk.org  Tue Jan  7 09:15:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 7 Jan 2025 09:15:41 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
Message-ID: <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>

On Tue, 7 Jan 2025 06:21:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
>> 
>> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
>> 
>> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
>> 
>> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
>> 
>> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
>> 
>> x86_32 is the only platform that has special cases for x87 FPU.
>> 
>> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
>> 
>> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
>> 
>> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
>> 
>> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of...
>
> src/hotspot/share/interpreter/abstractInterpreter.cpp line 137:
> 
>> 135:       case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits;
>> 136:       case vmIntrinsics::_longBitsToDouble:  return java_lang_Double_longBitsToDouble;
>> 137:       case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits;
> 
> Why are these intrinsics for the Java methods disappearing?

These are interpreter "intrinsics" that are only implemented on x86_32 to handle x87 FPU pecularities. Look around for `TemplateInterpreterGenerator::generate_Float_intBitsToFloat_entry`, for example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1905134973

From jwaters at openjdk.org  Tue Jan  7 09:33:44 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Jan 2025 09:33:44 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v15]
In-Reply-To: <V6_HK5nJ3toWNn4G3tC0vbnuGSh-3H9GvJmbsNNcW58=.fc7dc3ce-dd04-4e2f-8750-f17e00864764@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <V6_HK5nJ3toWNn4G3tC0vbnuGSh-3H9GvJmbsNNcW58=.fc7dc3ce-dd04-4e2f-8750-f17e00864764@github.com>
Message-ID: <cwusoKYlA-PQJKzcr5qF09YpVfTfNPI9GHu08jTyGCY=.00023f5f-b115-427a-9862-fe0a77a84388@github.com>

On Tue, 10 Dec 2024 06:10:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into hotspot
>  - _WINDOWS && AARCH64 in sharedRuntime.hpp
>  - AARCH64 in sharedRuntimeRem.cpp
>  - Refactor sharedRuntime.cpp
>  - CAST_FROM_FN_PTR in os_windows.cpp
>  - Merge branch 'openjdk:master' into hotspot
>  - fmod_winarm64 in sharedRuntime.cpp
>  - fmod_winarm64 in sharedRuntimeRem.cpp
>  - fmod_winarm64 in sharedRuntime.hpp
>  - Typo in sharedRuntimeRem.cpp
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/c43498b1...ff1c4664

Keep open please

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

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2574801814

From kbarrett at openjdk.org  Tue Jan  7 09:34:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 09:34:38 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <pR3PxkPq2G2sA-VWvtznTFFEEbH0bKGvX6Pu1cpUdxs=.135d0207-8a53-45de-bbeb-19e48d91e80c@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <12-_FKsXl3OOujKaHQewgKdDUi95q9M0fSmuLeo6_Wg=.1ec72306-698f-42f8-86b7-e53bc711fde6@github.com>
 <WycXWrpkTQZ0R8uZFiPv-9WAauOMx_1QZ2i4n4Sreyw=.0d68a0f6-eddf-4902-b052-ffcdeefa6ed6@github.com>
 <RSDGosec3ekGX_EoXtcR8PNxRtFRS4Miw166vDIOioQ=.3f3b8753-d961-4cd8-ac26-33bc6016e816@github.com>
 <pR3PxkPq2G2sA-VWvtznTFFEEbH0bKGvX6Pu1cpUdxs=.135d0207-8a53-45de-bbeb-19e48d91e80c@github.com>
Message-ID: <rLr0m_kze7f6K60n9tYe_dlo8AyAnhbMaznmCwfmTqk=.af8abf03-229e-4808-8d68-495b39a1d8b5@github.com>

On Sun, 5 Jan 2025 22:14:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Thanks! This has solved one of the problems, but not all. The next one is:
> > ```
> > globalDefinitions_gcc.hpp:55:
> > In file included from /usr/include/fcntl.h:242:
> > /usr/include/unistd.h:181:8: error: 'noreturn' attribute does not appear on the first declaration
> > extern _NORETURN(void, _exit)(int);
> >        ^
> > ```
> 
> Drat. I forgot that posix _exit comes from unistd.h. Back to work...

Hopefully that's fixed now too, and there won't be any more.
I also added _Exit to the forbidden set.

I looked into the more robust / less kludgy approaches, but they are more work than I want to do as part of this PR.
Maybe in a followup.  And I wonder if someone might file a bug about the clang weirdness?

This might be related, but seems kind of different:
https://github.com/llvm/llvm-project/issues/113511

Test case:

__attribute__((__noreturn__)) void frob(int);
[[noreturn]] void frob(int);

=>

'noreturn' attribute does not appear on the first declaration

gcc compiles this without error.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2574803325

From fyang at openjdk.org  Tue Jan  7 10:52:00 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 7 Jan 2025 10:52:00 GMT
Subject: [jdk24] RFR: 8346838: RISC-V:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crash with
 debug VMs
Message-ID: <iS5rhstmtYDqv5ndUWcW652k4zpugEKh0osXcwM6hOI=.a43e37ee-6e0b-49b2-852e-1e32337ab9bb@github.com>

Hi all,

This pull request contains a backport of commit [379ac349](https://github.com/openjdk/jdk/commit/379ac349d13e2c0c6986eb0787f33b9a7a2a3749) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Fei Yang on 7 Jan 2025 and was reviewed by Feilong Jiang and Robbin Ehn.

Thanks!

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

Commit messages:
 - Backport 379ac349d13e2c0c6986eb0787f33b9a7a2a3749

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

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

From stefank at openjdk.org  Tue Jan  7 12:06:45 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 7 Jan 2025 12:06:45 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER
In-Reply-To: <xhg_uFNDY7rzIK0EL13nI-64mbTR6Bu0SbRgld9AZgk=.a0bcc2fd-1e58-46fb-b665-376092bc0db3@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>
 <COjHd9W5K-B7s2wF2IVGT_YiuLj4_ak1egEOcRdIC48=.4aff405a-1e9b-46c7-8679-6c24eaac89b7@github.com>
 <WTkzmdbkAd7ihhWqfYi4rsEVjxBsf4GGGLMQV0s0Lq8=.c58e1323-e57a-4eeb-b197-6b08053dd010@github.com>
 <xhg_uFNDY7rzIK0EL13nI-64mbTR6Bu0SbRgld9AZgk=.a0bcc2fd-1e58-46fb-b665-376092bc0db3@github.com>
Message-ID: <oZkOBs-AFyASajbH2cnC0xkvls2bbGZALvcvc7-jbQc=.e929d4c3-1edb-4329-a0ba-65932daeeabc@github.com>

On Tue, 7 Jan 2025 04:35:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> UINT64_FORMAT_RAW_X_0  is not terrible. :)
>
> To be honest though I don't know why we want hexadecimal output without the leading 0x ...

The `_X` infix is meant to indicate `0x`. I think `UINT64_FORMAT_0` is what you are looking for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1905357323

From coleenp at openjdk.org  Tue Jan  7 12:34:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:34:43 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER
In-Reply-To: <oZkOBs-AFyASajbH2cnC0xkvls2bbGZALvcvc7-jbQc=.e929d4c3-1edb-4329-a0ba-65932daeeabc@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>
 <COjHd9W5K-B7s2wF2IVGT_YiuLj4_ak1egEOcRdIC48=.4aff405a-1e9b-46c7-8679-6c24eaac89b7@github.com>
 <WTkzmdbkAd7ihhWqfYi4rsEVjxBsf4GGGLMQV0s0Lq8=.c58e1323-e57a-4eeb-b197-6b08053dd010@github.com>
 <xhg_uFNDY7rzIK0EL13nI-64mbTR6Bu0SbRgld9AZgk=.a0bcc2fd-1e58-46fb-b665-376092bc0db3@github.com>
 <oZkOBs-AFyASajbH2cnC0xkvls2bbGZALvcvc7-jbQc=.e929d4c3-1edb-4329-a0ba-65932daeeabc@github.com>
Message-ID: <WKMZYaCJSKTnzpEs93ARVOQUzJ-kOWHvOOPLg7njV3E=.92e9dfef-8e31-402c-aef9-2e9c382930bb@github.com>

On Tue, 7 Jan 2025 12:03:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> To be honest though I don't know why we want hexadecimal output without the leading 0x ...
>
> The `_X` infix is meant to indicate `0x`. I think `UINT64_FORMAT_0` is what you are looking for.

I thought X was hexadecimal.  That's a lot better.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1905387568

From coleenp at openjdk.org  Tue Jan  7 12:36:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:36:46 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
 <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>
Message-ID: <ThBA0Kns0IoLwZ4OkKm5X_oh5WJKcgGn_AV610Xhhyo=.c65e531d-5c24-438d-8b09-498f40235f6e@github.com>

On Tue, 7 Jan 2025 08:50:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
>> prefix gets included in the width when dealing with field width, which might not be great either.
>
> The problem of accounting for the prefix in the field width calculation can be dealt with by using precision
> rather than field width.

Well then that leaves the fun of dealing with these format specifiers when you're trying to do your own formatting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905390045

From coleenp at openjdk.org  Tue Jan  7 12:39:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:39:47 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v2]
In-Reply-To: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
Message-ID: <R7eznq9_V9CM-MChOLuGhVeBQGRfmj-zBKREx93MQEk=.c72ab986-d886-4777-b7cd-b583100b5b7b@github.com>

> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
> GHA tested.

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

  Use INT64_FORMAT_0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22918/files
  - new: https://git.openjdk.org/jdk/pull/22918/files/c93c939b..f2223d2c

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

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

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

From coleenp at openjdk.org  Tue Jan  7 12:51:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:51:33 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

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

  Restore copyright and macro.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/6e8b2702..ae9d9f6f

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

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

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

From coleenp at openjdk.org  Tue Jan  7 12:51:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:51:33 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
 <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
 <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>
Message-ID: <L3cRMsD-8R7vI4fAvbYGrkjq6xEOrpjvrMMIGjZboFY=.67be8877-242a-47c9-b224-5829ce85eab7@github.com>

On Tue, 7 Jan 2025 08:48:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
>> I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
>> format directives that resemble line noise, or ugly conditionals like that.
>
> Improving on my prior suggestion
> `"%#.*zx", (2 * BytesPerWord), _secondary_supers_bitmap`
> Using precision rather than field width, to avoid needing to account for the prefix in the width calculation.
> But still looking a lot like line noise, and still think it shouldn't be changed.

Yes, this looks horrible.  The macro that I was trying to remove is better.  I restored but moved it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905405696

From dholmes at openjdk.org  Tue Jan  7 13:08:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 13:08:40 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v2]
In-Reply-To: <WKMZYaCJSKTnzpEs93ARVOQUzJ-kOWHvOOPLg7njV3E=.92e9dfef-8e31-402c-aef9-2e9c382930bb@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>
 <COjHd9W5K-B7s2wF2IVGT_YiuLj4_ak1egEOcRdIC48=.4aff405a-1e9b-46c7-8679-6c24eaac89b7@github.com>
 <WTkzmdbkAd7ihhWqfYi4rsEVjxBsf4GGGLMQV0s0Lq8=.c58e1323-e57a-4eeb-b197-6b08053dd010@github.com>
 <xhg_uFNDY7rzIK0EL13nI-64mbTR6Bu0SbRgld9AZgk=.a0bcc2fd-1e58-46fb-b665-376092bc0db3@github.com>
 <oZkOBs-AFyASajbH2cnC0xkvls2bbGZALvcvc7-jbQc=.e929d4c3-1edb-4329-a0ba-65932daeeabc@github.com>
 <WKMZYaCJSKTnzpEs93ARVOQUzJ-kOWHvOOPLg7njV3E=.92e9dfef-8e31-402c-aef9-2e9c382930bb@github.com>
Message-ID: <0KfKCCHF9ITI92SV6XA5iVWgjDd9AORT5iyCdhNkI9s=.c128cfe1-2cbf-4a14-b6ad-b56d24271ae2@github.com>

On Tue, 7 Jan 2025 12:31:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The `_X` infix is meant to indicate `0x`. I think `UINT64_FORMAT_0` is what you are looking for.
>
> I thought X was hexadecimal.  That's a lot better.  Thanks.

// Guide to the suffixes used in the format specifiers for integers:
//        - print the decimal value:                   745565
//  _X    - print as hexadecimal, without leading 0s: 0x12345
//  _X_0  - print as hexadecimal, with leading 0s: 0x00012345

It wasn't obvious to me that the _X meant hexadecimal-with-0x-prefix versus simply hexadecimal. But I have no issue with always doing 0x :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1905429372

From dholmes at openjdk.org  Tue Jan  7 13:15:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 13:15:45 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v2]
In-Reply-To: <R7eznq9_V9CM-MChOLuGhVeBQGRfmj-zBKREx93MQEk=.c72ab986-d886-4777-b7cd-b583100b5b7b@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <R7eznq9_V9CM-MChOLuGhVeBQGRfmj-zBKREx93MQEk=.c72ab986-d886-4777-b7cd-b583100b5b7b@github.com>
Message-ID: <k_rWOJlwOwiSkOZbPEpSl52x0fH2HCUgD617rQ1Co8Q=.b1578953-889c-4df6-bf19-8744dfd41100@github.com>

On Tue, 7 Jan 2025 12:39:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
>> GHA tested.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use INT64_FORMAT_0

src/hotspot/share/utilities/globalDefinitions.hpp line 135:

> 133: #define UINT64_FORMAT_W(width)   "%"   #width PRIu64
> 134: 
> 135: // Format with padding without leading 0x

This comment belongs in the "Guide to suffixes" block comment above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1905436918

From dholmes at openjdk.org  Tue Jan  7 13:18:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 13:18:42 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v2]
In-Reply-To: <R7eznq9_V9CM-MChOLuGhVeBQGRfmj-zBKREx93MQEk=.c72ab986-d886-4777-b7cd-b583100b5b7b@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <R7eznq9_V9CM-MChOLuGhVeBQGRfmj-zBKREx93MQEk=.c72ab986-d886-4777-b7cd-b583100b5b7b@github.com>
Message-ID: <ePgTnSSouwg9Zmx1reao5lerBFnlY0VbdlLpOe1HBSc=.71c386c4-6808-4383-9e5f-87ac350d4850@github.com>

On Tue, 7 Jan 2025 12:39:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
>> GHA tested.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use INT64_FORMAT_0

src/hotspot/share/utilities/globalDefinitions.hpp line 136:

> 134: 
> 135: // Format with padding without leading 0x
> 136: #define INT64_FORMAT_0           "%016"       PRIx64

AFAICS the os.cpp usages want unsigned (`%016llx`), so this should be UINT64_FORMAT_0

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1905440696

From stefank at openjdk.org  Tue Jan  7 13:24:35 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 7 Jan 2025 13:24:35 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v2]
In-Reply-To: <0KfKCCHF9ITI92SV6XA5iVWgjDd9AORT5iyCdhNkI9s=.c128cfe1-2cbf-4a14-b6ad-b56d24271ae2@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <P2GLc-wevl7NGNGkdU7F2UPvn-H2YxqvOwDQ6R5s2cs=.7274d005-f79e-467d-bf54-44ecbda7cfd6@github.com>
 <COjHd9W5K-B7s2wF2IVGT_YiuLj4_ak1egEOcRdIC48=.4aff405a-1e9b-46c7-8679-6c24eaac89b7@github.com>
 <WTkzmdbkAd7ihhWqfYi4rsEVjxBsf4GGGLMQV0s0Lq8=.c58e1323-e57a-4eeb-b197-6b08053dd010@github.com>
 <xhg_uFNDY7rzIK0EL13nI-64mbTR6Bu0SbRgld9AZgk=.a0bcc2fd-1e58-46fb-b665-376092bc0db3@github.com>
 <oZkOBs-AFyASajbH2cnC0xkvls2bbGZALvcvc7-jbQc=.e929d4c3-1edb-4329-a0ba-65932daeeabc@github.com>
 <WKMZYaCJSKTnzpEs93ARVOQUzJ-kOWHvOOPLg7njV3E=.92e9dfef-8e31-402c-aef9-2e9c382930bb@github.com>
 <0KfKCCHF9ITI92SV6XA5iVWgjDd9AORT5iyCdhNkI9s=.c128cfe1-2cbf-4a14-b6ad-b56d24271ae2@github.com>
Message-ID: <WczhQyOUe3l0slVdqLEr3TMpbGuJSeGOB7XK2_a4xx0=.e2484838-1c3f-441c-9c25-794463c8e90c@github.com>

On Tue, 7 Jan 2025 13:06:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I thought X was hexadecimal.  That's a lot better.  Thanks.
>
> // Guide to the suffixes used in the format specifiers for integers:
> //        - print the decimal value:                   745565
> //  _X    - print as hexadecimal, without leading 0s: 0x12345
> //  _X_0  - print as hexadecimal, with leading 0s: 0x00012345
> 
> It wasn't obvious to me that the _X meant hexadecimal-with-0x-prefix versus simply hexadecimal. But I have no issue with always doing 0x :)

Hmm. You are right. I read too much into the comment (that I wrote some time ago :) )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22918#discussion_r1905448446

From coleenp at openjdk.org  Tue Jan  7 14:07:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 14:07:20 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v3]
In-Reply-To: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
Message-ID: <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>

> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
> GHA tested.

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

  You're right, it's UINT64_FORMAT and moved the comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22918/files
  - new: https://git.openjdk.org/jdk/pull/22918/files/f2223d2c..6ac66379

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

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

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

From mdoerr at openjdk.org  Tue Jan  7 15:21:39 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 7 Jan 2025 15:21:39 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v4]
In-Reply-To: <mgaIxADi54AaczgDWzqFm3WUzMu2tqApcxrZ2oh_4Mc=.1e792b0f-89a8-460e-a96b-6cb0f6f74a3a@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <mgaIxADi54AaczgDWzqFm3WUzMu2tqApcxrZ2oh_4Mc=.1e792b0f-89a8-460e-a96b-6cb0f6f74a3a@github.com>
Message-ID: <fxDnyYA1AHns3gXjtAyAMzujRJdrYzBcYbulbB5tQGM=.b5c0a410-a801-464e-a2f5-191df85c9461@github.com>

On Tue, 7 Jan 2025 09:09:16 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more fixes for clang noreturn issues

Thanks! That solved the issue. Now, we need to adapt all usages in the low level AIX code and support `strdup`:

diff --git a/src/hotspot/os/aix/libodm_aix.cpp b/src/hotspot/os/aix/libodm_aix.cpp
index 9fe0fb7abd8..854fd5e2b79 100644
--- a/src/hotspot/os/aix/libodm_aix.cpp
+++ b/src/hotspot/os/aix/libodm_aix.cpp
@@ -30,6 +30,7 @@
 #include <string.h>
 #include "runtime/arguments.hpp"
 #include "runtime/os.hpp"
+#include "utilities/permitForbiddenFunctions.hpp"
 
 
 dynamicOdm::dynamicOdm() {
@@ -59,7 +60,7 @@ dynamicOdm::~dynamicOdm() {
 }
 
 
-void odmWrapper::clean_data() { if (_data) { free(_data); _data = nullptr; } }
+void odmWrapper::clean_data() { if (_data) { permit_forbidden_function::free(_data); _data = nullptr; } }
 
 
 int odmWrapper::class_offset(const char *field, bool is_aix_5)
diff --git a/src/hotspot/os/aix/loadlib_aix.cpp b/src/hotspot/os/aix/loadlib_aix.cpp
index bc21aef3836..88f660ad46f 100644
--- a/src/hotspot/os/aix/loadlib_aix.cpp
+++ b/src/hotspot/os/aix/loadlib_aix.cpp
@@ -38,6 +38,7 @@
 #include "logging/log.hpp"
 #include "utilities/debug.hpp"
 #include "utilities/ostream.hpp"
+#include "utilities/permitForbiddenFunctions.hpp"
 
 // For loadquery()
 #include <sys/ldr.h>
@@ -55,7 +56,7 @@ class StringList {
   // Enlarge list. If oom, leave old list intact and return false.
   bool enlarge() {
     int cap2 = _cap + 64;
-    char** l2 = (char**) ::realloc(_list, sizeof(char*) * cap2);
+    char** l2 = (char**) permit_forbidden_function::realloc(_list, sizeof(char*) * cap2);
     if (!l2) {
       return false;
     }
@@ -73,7 +74,7 @@ class StringList {
       }
     }
     assert0(_cap > _num);
-    char* s2 = ::strdup(s);
+    char* s2 = permit_forbidden_function::strdup(s);
     if (!s2) {
       return nullptr;
     }
@@ -167,7 +168,7 @@ static void free_entry_list(loaded_module_t** start) {
   loaded_module_t* lm = *start;
   while (lm) {
     loaded_module_t* const lm2 = lm->next;
-    ::free(lm);
+    permit_forbidden_function::free(lm);
     lm = lm2;
   }
   *start = nullptr;
@@ -190,7 +191,7 @@ static bool reload_table() {
   uint8_t* buffer = nullptr;
   size_t buflen = 1024;
   for (;;) {
-    buffer = (uint8_t*) ::realloc(buffer, buflen);
+    buffer = (uint8_t*) permit_forbidden_function::realloc(buffer, buflen);
     if (loadquery(L_GETINFO, buffer, buflen) == -1) {
       if (errno == ENOMEM) {
         buflen *= 2;
@@ -210,7 +211,7 @@ static bool reload_table() {
 
   for (;;) {
 
-    loaded_module_t* lm = (loaded_module_t*) ::malloc(sizeof(loaded_module_t));
+    loaded_module_t* lm = (loaded_module_t*) permit_forbidden_function::malloc(sizeof(loaded_module_t));
     if (!lm) {
       log_warning(os)("OOM.");
       goto cleanup;
@@ -226,7 +227,7 @@ static bool reload_table() {
     lm->path = g_stringlist.add(ldi->ldinfo_filename);
     if (!lm->path) {
       log_warning(os)("OOM.");
-      free(lm);
+      permit_forbidden_function::free(lm);
       goto cleanup;
     }
 
@@ -248,7 +249,7 @@ static bool reload_table() {
       lm->member = g_stringlist.add(p_mbr_name);
       if (!lm->member) {
         log_warning(os)("OOM.");
-        free(lm);
+        permit_forbidden_function::free(lm);
         goto cleanup;
       }
     } else {
@@ -296,7 +297,7 @@ static bool reload_table() {
     free_entry_list(&new_list);
   }
 
-  ::free(buffer);
+  permit_forbidden_function::free(buffer);
 
   return rc;
 
diff --git a/src/hotspot/os/aix/os_aix.cpp b/src/hotspot/os/aix/os_aix.cpp
index 26627c2f8fb..2d0859a4d5e 100644
--- a/src/hotspot/os/aix/os_aix.cpp
+++ b/src/hotspot/os/aix/os_aix.cpp
@@ -74,6 +74,7 @@
 #include "utilities/defaultStream.hpp"
 #include "utilities/events.hpp"
 #include "utilities/growableArray.hpp"
+#include "utilities/permitForbiddenFunctions.hpp"
 #include "utilities/vmError.hpp"
 #if INCLUDE_JFR
 #include "jfr/support/jfrNativeLibraryLoadEvent.hpp"
@@ -364,9 +365,9 @@ static void query_multipage_support() {
   // or by environment variable LDR_CNTRL (suboption DATAPSIZE). If none is given,
   // default should be 4K.
   {
-    void* p = ::malloc(16*M);
+    void* p = permit_forbidden_function::malloc(16*M);
     g_multipage_support.datapsize = os::Aix::query_pagesize(p);
-    ::free(p);
+    permit_forbidden_function::free(p);
   }
 
   // Query default shm page size (LDR_CNTRL SHMPSIZE).
@@ -1406,7 +1407,7 @@ static struct {
 } vmem;
 
 static void vmembk_add(char* addr, size_t size, size_t pagesize, int type) {
-  vmembk_t* p = (vmembk_t*) ::malloc(sizeof(vmembk_t));
+  vmembk_t* p = (vmembk_t*) permit_forbidden_function::malloc(sizeof(vmembk_t));
   assert0(p);
   if (p) {
     MiscUtils::AutoCritSect lck(&vmem.cs);
@@ -1435,7 +1436,7 @@ static void vmembk_remove(vmembk_t* p0) {
   for (vmembk_t** pp = &(vmem.first); *pp; pp = &((*pp)->next)) {
     if (*pp == p0) {
       *pp = p0->next;
-      ::free(p0);
+      permit_forbidden_function::free(p0);
       return;
     }
   }
diff --git a/src/hotspot/os/aix/porting_aix.cpp b/src/hotspot/os/aix/porting_aix.cpp
index 9d91c91bf8a..2235d3da686 100644
--- a/src/hotspot/os/aix/porting_aix.cpp
+++ b/src/hotspot/os/aix/porting_aix.cpp
@@ -1082,7 +1082,7 @@ void* Aix_dlopen(const char* filename, int Flags, int *eno, const char** error_r
       if (g_handletable_used == max_handletable) {
         // No place in array anymore; increase array.
         unsigned new_max = MAX2(max_handletable * 2, init_num_handles);
-        struct handletableentry* new_tab = (struct handletableentry*)::realloc(p_handletable, new_max * sizeof(struct handletableentry));
+        struct handletableentry* new_tab = (struct handletableentry*) permit_forbidden_function::realloc(p_handletable, new_max * sizeof(struct handletableentry));
         assert(new_tab != nullptr, "no more memory for handletable");
         if (new_tab == nullptr) {
           *error_report = "dlopen: no more memory for handletable";
diff --git a/src/hotspot/share/utilities/permitForbiddenFunctions.hpp b/src/hotspot/share/utilities/permitForbiddenFunctions.hpp
index 0611d7e1996..a751158832c 100644
--- a/src/hotspot/share/utilities/permitForbiddenFunctions.hpp
+++ b/src/hotspot/share/utilities/permitForbiddenFunctions.hpp
@@ -60,6 +60,7 @@ inline void* malloc(size_t size) { return ::malloc(size); }
 inline void free(void* ptr) { return ::free(ptr); }
 inline void* calloc(size_t nmemb, size_t size) { return ::calloc(nmemb, size); }
 inline void* realloc(void* ptr, size_t size) { return ::realloc(ptr, size); }
+inline char* strdup(const char* str) { return ::strdup(str); }
 
 END_ALLOW_FORBIDDEN_FUNCTIONS
 } // namespace permit_forbidden_function


It may be possible to use some `os::` versions, but that would need a careful review. I think it's safer to keep it this way for now. @JoKern65: You may want to take a look, too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2575556410

From fgao at openjdk.org  Tue Jan  7 15:53:35 2025
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 7 Jan 2025 15:53:35 GMT
Subject: RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let
 legitimize_address() fix out-of-range operands
In-Reply-To: <s_94WASXBZfedpvij--bghlregLi4MZ6O4j49-lw1B8=.f3daabef-a9b4-42a0-bc52-0152a4b9ef27@github.com>
References: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
 <s_94WASXBZfedpvij--bghlregLi4MZ6O4j49-lw1B8=.f3daabef-a9b4-42a0-bc52-0152a4b9ef27@github.com>
Message-ID: <EC4abQyI0a7_T4rkFsjLCpqTsfwqgaa6-HotxekD1Ic=.3e1f746d-b1e8-4456-a61d-ccb5a0fabf31@github.com>

On Mon, 23 Dec 2024 19:01:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

> In general I like this very much. If I were you I'd count how often `legitimize_address` has to split an instruction, and also count the total size of all C2 compilations over a run. I'd perhaps run jshell or javac all of java.base. Then we'd know how rare `legitimize_address` splitting is. Thanks.

Thanks for your review and comments! @theRealAph

Yes, as expected, `legitimize_address` splitting is very rare. As you suggested, I compiled all of `java.base` with built `javac` and found over `700k` `load/store` generated by C2 but no `legitimize_address` splitting. Actually, no `legitimize_address` splitting happened even I did `make bootcycle-images`. From our experience, `Unsafe` APIs can generate unaligned offsets and some corner cases may generate out-of-range offsets.

I'll update the comments for the code in the next commit soon. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22862#issuecomment-2575632823

From jsjolen at openjdk.org  Tue Jan  7 16:01:59 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 7 Jan 2025 16:01:59 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <JsAD3IcUMs7Z0e2iUVTY1Bu_B-AgBrfopHHcf3e4MZc=.3ad7dbd8-ffc2-4b4f-bc70-b738109ffd6d@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <JsAD3IcUMs7Z0e2iUVTY1Bu_B-AgBrfopHHcf3e4MZc=.3ad7dbd8-ffc2-4b4f-bc70-b738109ffd6d@github.com>
Message-ID: <qj-dBbtwooojct52g48-oc1HX9FbDUS4Ky8Xsvm3s54=.6fb1e652-6284-44d9-a142-09f0aac7dc7f@github.com>

On Tue, 7 Jan 2025 09:41:05 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed coloring functions
>
> src/hotspot/share/utilities/rbTree.inline.hpp line 100:
> 
>> 98:     _right->visit_in_order_inner(f);
>> 99:   }
>> 100: }
> 
> This is basically fine, as stack depth will be at most `2log n`, but is there a reason that you can't use the iterative solution that's present in the Treap? Btw, having this method belonging to RBTree and take a `RBNode*` instead of RBNode allows you to just check if the current root node is null, letting you skip a check.
> 
> Here's `visit_in_order` as an iterative function:
> 
> 
>   template<typename F>
>   void visit_in_order(F f) const {
>     GrowableArrayCHeap<TreapNode*, mtNMT> to_visit;
>     TreapNode* head = _root;
>     while (!to_visit.is_empty() || head != nullptr) {
>       while (head != nullptr) {
>         to_visit.push(head);
>         head = head->left();
>       }
>       head = to_visit.pop();
>       f(head);
>       head = head->right();
>     }
>   }

In fact, you can pre-size the GA such that it starts with a capacity of 2log(n+1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905431013

From jsjolen at openjdk.org  Tue Jan  7 16:01:59 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 7 Jan 2025 16:01:59 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
Message-ID: <JsAD3IcUMs7Z0e2iUVTY1Bu_B-AgBrfopHHcf3e4MZc=.3ad7dbd8-ffc2-4b4f-bc70-b738109ffd6d@github.com>

On Wed, 18 Dec 2024 10:46:53 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed coloring functions

src/hotspot/share/utilities/rbTree.hpp line 114:

> 112:     if (node_place == nullptr) {
> 113:       return nullptr;
> 114:     }

Remove this and instead `assert` that it can't be `nullptr` with a message saying that allocators must exit on failure.

src/hotspot/share/utilities/rbTree.hpp line 134:

> 132:   RBNode* find_node(RBNode* curr, const K& k);
> 133: 
> 134:   RBNode* insert_node(const K& k, const V& v);

Comment that it replaces `v` (as `upsert` does) if found.

src/hotspot/share/utilities/rbTree.hpp line 266:

> 264:     const RBTree* const _tree;
> 265:     GrowableArrayCHeap<RBNode*, mtInternal> _to_visit;
> 266:     RBNode* _next;

This isn't used?

src/hotspot/share/utilities/rbTree.hpp line 274:

> 272:     NONCOPYABLE(IteratorImpl);
> 273: 
> 274:     IteratorImpl(const RBTree* tree) : _tree(tree) {

Initialize `_to_visit` explicitly with a `2log(n)` where n is number of nodes, unnecessary resizing happens otherwise.

src/hotspot/share/utilities/rbTree.inline.hpp line 100:

> 98:     _right->visit_in_order_inner(f);
> 99:   }
> 100: }

This is basically fine, as stack depth will be at most `2log n`, but is there a reason that you can't use the iterative solution that's present in the Treap? Btw, having this method belonging to RBTree and take a `RBNode*` instead of RBNode allows you to just check if the current root node is null, letting you skip a check.

Here's `visit_in_order` as an iterative function:


  template<typename F>
  void visit_in_order(F f) const {
    GrowableArrayCHeap<TreapNode*, mtNMT> to_visit;
    TreapNode* head = _root;
    while (!to_visit.is_empty() || head != nullptr) {
      while (head != nullptr) {
        to_visit.push(head);
        head = head->left();
      }
      head = to_visit.pop();
      f(head);
      head = head->right();
    }
  }

src/hotspot/share/utilities/rbTree.inline.hpp line 172:

> 170:       curr = curr->_left;
> 171:     } else {                    // k > key
> 172:       curr = curr->_right;

Nit: Unnecessary comments, should be clear what they do.

src/hotspot/share/utilities/rbTree.inline.hpp line 203:

> 201:       curr = curr->_right;
> 202:     }
> 203:   }

Replace with `find_node` and write `parent` by reading `_parent`?

src/hotspot/share/utilities/rbTree.inline.hpp line 237:

> 235: 
> 236:     RBNode* uncle = parent->is_left_child() ? grandparent->_right : grandparent->_left;
> 237:     if (is_black(uncle)) { // Parent is red, uncle is black

And uncle has to exist (can't be null) as per some invariant? Add assert.

test/hotspot/gtest/utilities/test_rbtree.cpp line 300:

> 298:       EXPECT_EQ(reverse_iterator.next()->val(), n);
> 299:     }
> 300:   }

At least also test:

1. Iterator on empty tree works as expected
2. `has_next` is false after the loops

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905163526
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905433593
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905676241
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905675907
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905175777
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905431887
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905434902
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905437920
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905676906

From yzheng at openjdk.org  Tue Jan  7 16:17:45 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 7 Jan 2025 16:17:45 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <8DdLbSa2qunYTvNQxss7Dh26pYhGzZepTCgE1252_VI=.0150a509-d248-43a5-a01b-f47a96589727@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

JVMCI changes look good to me!

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2534792137

From stuefe at openjdk.org  Tue Jan  7 16:34:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 7 Jan 2025 16:34:48 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
Message-ID: <G3XVdHl4e-4d3vNEnTvJdG7RssclwKsbby1PNme1T48=.0b5c26d3-34ae-4504-802d-7b1d28a23541@github.com>

On Wed, 18 Dec 2024 10:46:53 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed coloring functions

This is highly welcome. Thank you for this work!

Will this implementation guarantee address stability and identity of the nodes themselves? Meaning, can I use this RB for memory management, with the Nodes themselves being the blocks being managed, and their identity is the address/size of the node memory block? 

The reason I ask is that IIRC many RB implementations will, at some point (I believe during deletion) copy node content around. j.u.TreeSet does this, for instance. Back in 2020 I briefly attempted to replace the Metaspace dictionary with an RB tree, but IIRC that point thwarted me. I dimly remember that the only implementation I found that could do this was the Linux kernel RB implementation (which would not be a bad implementation to copy, btw).

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

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2575738516

From jsjolen at openjdk.org  Tue Jan  7 17:13:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 7 Jan 2025 17:13:40 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
Message-ID: <pOSDbb7W0iQO6bWIBVbqwqIBAH17Vx2zmJOdyel8Cpk=.25710294-ffba-4484-839d-b2f3a5ee028e@github.com>

On Wed, 18 Dec 2024 10:46:53 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed coloring functions

src/hotspot/share/utilities/rbTree.hpp line 308:

> 306: 
> 307:   void free(void* ptr) { os::free(ptr); }
> 308: };

An issue with this allocator is that it doesn't call destructors on `free`. I think we should add this, or any future users may leak memory by mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905801401

From aph at openjdk.org  Tue Jan  7 17:13:39 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 7 Jan 2025 17:13:39 GMT
Subject: RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let
 legitimize_address() fix out-of-range operands
In-Reply-To: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
References: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
Message-ID: <7KNxpwpRzo3wWkNqMLplSIKhGwRwqBTLxVPhKJHst6w=.45c448e0-c061-441f-aecf-68ce6ec01d3a@github.com>

On Mon, 23 Dec 2024 10:45:00 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `IndOffXX` types don't do us any good. It would be simpler and faster to match a general-purpose `IndOff` type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.
> 
> This patch simplifies the definitions of `immXOffset` with an estimated range. Whether an immediate can be encoded in a `LDR`/`STR` instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessary `legitimize_address()` in the phase of matcher for all `LDR`/`STR` instructions using the new `IndOff` memory operands (fix [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437)).
> 
> After this clean-up, memory operands matched with `IndOff` may require extra code emission (effectively a `lea`) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646)). On `aarch64` platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. Because `LDR`/`STR` is always the last one emitted, no matter what addressing mode the load/store operations finally use.
> 
> Tier 1 - 3 passed on `Macos-aarch64` with or without the vm option `-XX:+UseZGC`.

> Yes, as expected, `legitimize_address` splitting is very rare. As you suggested, I compiled all of `java.base` with built `javac` and found over `700k` `load/store` generated by C2 but no `legitimize_address` splitting. Actually, no `legitimize_address` splitting happened even I did `make bootcycle-images`. From our experience, `Unsafe` APIs can generate unaligned offsets and some corner cases may generate out-of-range offsets.

Good enough for me. I made a couple of suggestions about comments.

src/hotspot/cpu/aarch64/aarch64.ad line 5158:

> 5156: // with an immediate offset. legitimize_address() will fix out-of-range
> 5157: // operands by generating a lea before the address can be used.
> 5158: operand indOffI(iRegP reg, immIOffset off)

Suggestion:

// "off" may not be within the encoding range for LDR/STR instructions
// with an immediate offset. In that case, legitimize_address() will fix 
// out-of-range operands by generating a lea before the address is used.
operand indOffI(iRegP reg, immIOffset off)

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

PR Review: https://git.openjdk.org/jdk/pull/22862#pullrequestreview-2534959037
PR Review Comment: https://git.openjdk.org/jdk/pull/22862#discussion_r1905798204

From jsjolen at openjdk.org  Tue Jan  7 18:40:39 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 7 Jan 2025 18:40:39 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
Message-ID: <UxZ4CawQBcm2rKQd0NmJsyNciwkFsgPBJs6TcazZqCI=.6a623faa-f139-41c7-b4e5-a7ce41e86a24@github.com>

On Wed, 18 Dec 2024 10:46:53 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed coloring functions

src/hotspot/share/utilities/rbTree.inline.hpp line 438:

> 436: 
> 437:     node = curr;
> 438:   }

@tstuefe,

Seems like nodes are not stable. To quote Wikipedia:

>- When the deleted node has 2 children (non-NIL), then we can swap its value with its in-order successor (the leftmost child of the right subtree), and then delete the successor instead. Since the successor is leftmost, it can only have a right child (non-NIL) or no child at all. 

This is quite unfortunate, as it becomes very difficult (impossible?) to have intrusive RB-trees with this. 

@caspernorrbin,

Finding information on this in the literature seems like it takes quite a bit of digging. Can't we replace this with swapping everything *but* the key and value?

```c++
  if (node->_left != nullptr && node->_right != nullptr) { // node has two children
    RBNode* curr = node->_right;
    while (curr->_left != nullptr) {
      curr = curr->_left;
    }
  // Swap parent, left, right, and color
  std::swap(curr->_parent, node->_parent);
  std::swap(curr->_left, node->_left);
  std::swap(curr->_right, node->_right);
  std::swap(curr->_color, node->_color);
  // Swap the parent's child pointer
  if (curr->_parent->_left == node) curr->_parent->_left = curr;
  if (curr->_parent->_right == node) curr->_parent->_right = curr;
  // Set the children's parent pointers 
  curr->_left->_parent = curr; curr->_right->_parent = curr;

  // and then the identical writes for node
  if (node->_parent->_left == curr) node->_parent->_left = node;
  if (node->_parent->_right == curr) node->_parent->_right = node;
  // Set the children's parent pointers 
  node->_left->_parent = node; node->_right->_parent = node;

  // Done, they've swapped places in the tree.
  node = curr;
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1905894720

From sspitsyn at openjdk.org  Tue Jan  7 19:39:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 19:39:16 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v8]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <zq4IECS1_2qX3FChMHDYwM6pbzDB4JdPZ0JkL3JZMxs=.41c7e626-6f54-433c-826f-c45afb6c58d7@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

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 nine additional commits since the last revision:

 - Merge
 - review: updated one copyright year
 - review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp
 - review: removed unneeded check for JvmtiExport::can_post_frame_pop()
 - review: add a unit test covering JVMTI ClearAllFramePops
 - review: removed DUPLICATE related changes; a minor tweak for ASSERT line
 - added extra check to post_method_exit_inner before clear_frame_pop to avoid assert
 - fixed trailing space in jvmtiEnvBase.hpp
 - 8346143: add ClearAllFramePops function to speedup debugger single stepping in some cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/21ca5294..6a8e37aa

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

  Stats: 21029 lines in 649 files changed: 15125 ins; 3706 del; 2198 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

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

From sspitsyn at openjdk.org  Tue Jan  7 19:39:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 19:39:26 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v5]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <7KIxNpNeQdzrpTAfDoFJCMI1Eb3KYCSS1RaSsqZrCrg=.f3789314-03cc-46ba-bd76-90edd8ee6685@github.com>

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with 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 five additional commits since the last revision:

 - Merge
 - review: improved one failure logging a little bit
 - review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned
 - review: minor tweak in jvmti.xml update
 - 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/2b3fef1e..2468357f

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

  Stats: 21029 lines in 649 files changed: 15125 ins; 3706 del; 2198 mod
  Patch: https://git.openjdk.org/jdk/pull/22798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22798/head:pull/22798

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

From sspitsyn at openjdk.org  Tue Jan  7 19:47:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 19:47:10 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v6]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <MllP26-zZy8BltkxGEEPlWwIifKpZWWrVDrG-oXb5Z0=.4656ba1b-73ec-49eb-af16-bfd81699e03c@github.com>

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/2468357f..fbf9459d

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

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

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

From sspitsyn at openjdk.org  Tue Jan  7 19:53:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 19:53:20 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v9]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <3jlL15dxNOGhbPlWBQktux0XbjAd03fhFgW1BZJhp2A=.d48ef40c-776f-414d-a9e7-0cc3403448b8@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  update ciopyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/6a8e37aa..4682bcba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=07-08

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

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

From dholmes at openjdk.org  Tue Jan  7 20:05:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 20:05:34 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v3]
In-Reply-To: <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>
Message-ID: <qo3aK8Dv-UkKaG4SNX50hIkHRATKDe6Y8_4UKWkcVjg=.36d67513-9391-4003-96b3-b98cdc1c23e7@github.com>

On Tue, 7 Jan 2025 14:07:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
>> GHA tested.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   You're right, it's UINT64_FORMAT and moved the comment.

That looks good to me. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22918#pullrequestreview-2535264122

From sspitsyn at openjdk.org  Tue Jan  7 20:21:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 20:21:38 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <8JJQFQfpJBAwdH9AWlW037NoiFt99uxqXadqVOGRnOQ=.603d82b0-f3f4-4c1d-a957-30f88acf1676@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

Patricio, please, let me double check something before your push.

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

PR Comment: https://git.openjdk.org/jdk/pull/22931#issuecomment-2576149281

From sspitsyn at openjdk.org  Tue Jan  7 20:26:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 20:26:41 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <WvirHJ0p51sW319n_lz1Mgv4bcq4L2GhMcizCe-jYwo=.134f1180-969b-4b33-b131-2829e2e94f51@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Thank you for one more unification update! Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2535297355

From dlong at openjdk.org  Tue Jan  7 21:02:19 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Jan 2025 21:02:19 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <4DemtiMYMfFk02L_CpRut0MMGssK3jBcKfSTMLH36Y4=.24ee458f-5893-4249-b166-496f04a35d70@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

src/hotspot/share/classfile/vmIntrinsics.cpp line 39:

> 37: 
> 38: // These are flag-matching functions:
> 39: inline bool match_F_R(u2 flags) {

I wish more code could be size-agnostic.  So instead of using `u2` here, there could be a typedef in accessFlags.hpp that we could use that hides the size.  However, it's not a big deal, because it seems unlikely this type will change much in the future without a JVM spec change.  I'm tempted to suggesting using AccessFlags here, but it's a class.  Since this is an end-point "consumer" of the type that doesn't store it or pass it along, we could even use something like `uint` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1906033152

From dlong at openjdk.org  Tue Jan  7 21:23:37 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Jan 2025 21:23:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <oJJ4G2eUKrl3s_ZXA2Incjej0gjUgjJfBHK9We1zQvI=.bedeea70-55c1-4dae-a52d-c6e5deebfe59@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2535389245

From coleenp at openjdk.org  Tue Jan  7 22:06:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 22:06:42 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <XbcOXVEWmXamhjuakfCSR6xjdLkz-MuzR_yAtF-TH4M=.b01e080e-72d3-49f0-8bc3-4a6c3c0a5175@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

> IMO you could just call as_int() here. All other usages of ciFlags::as_int() are in printing code.
> Ideally, ciField::print() could use ciFlags::print(), but such cleanup can be done separately.

This does seem like a good future cleanup.  Thanks for reviewing Vladimir.

Thanks for reviewing David, Yudi and Serguei.  I reran tiers 1-7 on this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2576308012
PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2576309500

From coleenp at openjdk.org  Tue Jan  7 22:06:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 22:06:43 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <4DemtiMYMfFk02L_CpRut0MMGssK3jBcKfSTMLH36Y4=.24ee458f-5893-4249-b166-496f04a35d70@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
 <4DemtiMYMfFk02L_CpRut0MMGssK3jBcKfSTMLH36Y4=.24ee458f-5893-4249-b166-496f04a35d70@github.com>
Message-ID: <c26HPTNYT_1LUt7TbuVfGmc7zyMZX2WrphfyaotBi58=.7f660db3-831c-45b5-8f16-beadea6b5b86@github.com>

On Tue, 7 Jan 2025 20:59:18 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.
>
> src/hotspot/share/classfile/vmIntrinsics.cpp line 39:
> 
>> 37: 
>> 38: // These are flag-matching functions:
>> 39: inline bool match_F_R(u2 flags) {
> 
> I wish more code could be size-agnostic.  So instead of using `u2` here, there could be a typedef in accessFlags.hpp that we could use that hides the size.  However, it's not a big deal, because it seems unlikely this type will change much in the future without a JVM spec change.  I'm tempted to suggesting using AccessFlags here, but it's a class.  Since this is an end-point "consumer" of the type that doesn't store it or pass it along, we could even use something like `uint` here.

That seems like a good idea if this weren't so limited.  I did chat with DanH. to see if access flags will ever grow in size from u2 and he was doubtful that would ever happen. uint would work here too, but this small use might prevent some future -Wconversion warnings and doesn't hurt anything.
Thank you for reviewing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1906090983

From coleenp at openjdk.org  Tue Jan  7 22:06:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 22:06:44 GMT
Subject: Integrated: 8339113: AccessFlags can be u2 in metadata
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <hiPoyjk4Lj9wjmzLyIMWoFHmk5nMiQtgNEIAHuTxDb8=.8f60692f-e2d3-42ca-9a8a-90cc2bf17228@github.com>

On Tue, 19 Nov 2024 16:18:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

This pull request has now been integrated.

Changeset: 098afc8b
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/098afc8b7d0e7caa82999fb9d4e319ea8aed09a1
Stats:     328 lines in 58 files changed: 45 ins; 50 del; 233 mod

8339113: AccessFlags can be u2 in metadata

Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Reviewed-by: sspitsyn, vlivanov, yzheng, dlong, dholmes

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

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

From coleenp at openjdk.org  Tue Jan  7 22:24:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 22:24:35 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v3]
In-Reply-To: <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>
Message-ID: <p-ohBTcDkNPHerXd3_T7Lwo-Y6bTZICYRle8eykIXlQ=.a91f6713-633a-4ebb-84ab-74af51b57775@github.com>

On Tue, 7 Jan 2025 14:07:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
>> GHA tested.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   You're right, it's UINT64_FORMAT and moved the comment.

Thanks for reviewing, David.

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

PR Comment: https://git.openjdk.org/jdk/pull/22918#issuecomment-2576341112

From kbarrett at openjdk.org  Tue Jan  7 22:49:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 22:49:35 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v3]
In-Reply-To: <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>
Message-ID: <CWSDgZVbMq0_rf_3coFtbBdVVUB-kL0h2bXTDfxto9U=.794618ff-b04b-4a24-8000-1a5e04d82266@github.com>

On Tue, 7 Jan 2025 14:07:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
>> GHA tested.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   You're right, it's UINT64_FORMAT and moved the comment.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22918#pullrequestreview-2535519448

From asmehra at openjdk.org  Tue Jan  7 22:49:42 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Jan 2025 22:49:42 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v3]
In-Reply-To: <C_aAQOl_agKc49vGZe5pdpUIORd2HIV4stAPJ0HEnis=.a670485e-9c9e-4a99-ad18-a31b6d750e28@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <C_aAQOl_agKc49vGZe5pdpUIORd2HIV4stAPJ0HEnis=.a670485e-9c9e-4a99-ad18-a31b6d750e28@github.com>
Message-ID: <VjZyqnHXzQQOqdnMZ-8ZthWTfyAWwhuVrFL98Y9-qoE=.55ac71ec-7ee7-42d7-a886-197bc18b5d25@github.com>

On Tue, 3 Dec 2024 06:46:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
>> 
>> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
>> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
>> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
>> 
>> Note to reviewers:
>> 
>> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8344140-consolidate-aot-artifact-gathering-discovery
>  - Fixe 32-bit builds; removed unused function
>  - more clean up
>  - tmp
>  - More clean up
>  - Removed unnecessary code
>  - 8344140: Consolidate AOT cache code for artifact discovery

@iklam nice refactoring/cleanup! The comments and the logic in AOTArtifactFinder makes it a lot easier to understand the algorithm now.

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

PR Comment: https://git.openjdk.org/jdk/pull/22291#issuecomment-2576371136

From asmehra at openjdk.org  Tue Jan  7 22:54:43 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 7 Jan 2025 22:54:43 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v3]
In-Reply-To: <C_aAQOl_agKc49vGZe5pdpUIORd2HIV4stAPJ0HEnis=.a670485e-9c9e-4a99-ad18-a31b6d750e28@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <C_aAQOl_agKc49vGZe5pdpUIORd2HIV4stAPJ0HEnis=.a670485e-9c9e-4a99-ad18-a31b6d750e28@github.com>
Message-ID: <Rz_wLTn_6nuzC1ykXc0_X44wHnUdOxjFs6wtGRP31K8=.54ed0414-b83a-47f3-b03f-5341a2406b11@github.com>

On Tue, 3 Dec 2024 06:46:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
>> 
>> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
>> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
>> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
>> 
>> Note to reviewers:
>> 
>> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8344140-consolidate-aot-artifact-gathering-discovery
>  - Fixe 32-bit builds; removed unused function
>  - more clean up
>  - tmp
>  - More clean up
>  - Removed unnecessary code
>  - 8344140: Consolidate AOT cache code for artifact discovery

Comment in `AOTClassInitializer::can_archive_initialized_mirror()` refers to `HeapShared::find_all_aot_initialized_classes()` which does not exist anymore:


  // When CDSConfig::is_initing_classes_at_dump_time() is enabled,
  // HeapShared::find_all_aot_initialized_classes() finds the classes of all
  // heap objects that are reachable from HeapShared::_run_time_special_subgraph,
  // and mark these classes as aot-inited.


And this comment at line 263 in `aotClassInitializer.cpp` also needs to be updated as the enum classes are not unconditionally AOT-initialized:


      // above we selected all enums; we must include their super as well
      {"java/lang/Enum"},

src/hotspot/share/cds/metaspaceShared.cpp line 548:

> 546:     FileMapInfo::metaspace_pointers_do(it);
> 547:     AOTArtifactFinder::all_cached_classes_do(it);
> 548:     SystemDictionaryShared::dumptime_classes_do(it);

There is some duplicatoin of work in `AOTArtifactFinder::all_cached_classes_do()` and `SystemDictionaryShared::dumptime_classes_do()`. all_cached_classes_do() operates on `_all_cached_classes` which is built using `SystemDictionaryShared::_dumptime_table`. So the iteration over `_dumptime_table` in `SystemDictionaryShared::dumptime_classes_do()` seems redundant.

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

PR Comment: https://git.openjdk.org/jdk/pull/22291#issuecomment-2576376931
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1906128195

From dlong at openjdk.org  Tue Jan  7 23:07:35 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Jan 2025 23:07:35 GMT
Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for
 Ampere-1A and 1B
In-Reply-To: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
References: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
Message-ID: <OvuEdq1wzjFYCfg2fgdNQFpz5Q74alddGWG9VHF-PuU=.e63558e5-84d3-4a1b-b31d-0fb5100845ae@github.com>

On Fri, 15 Nov 2024 07:01:23 GMT, Liming Liu <lliu at openjdk.org> wrote:

> This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128.
> 
> Ran JTReg tier1 on Ampere-1A and no new issues were found.

Looks good.  Does this change not help CPU_MODEL_AMPERE_1?

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22134#pullrequestreview-2535539536

From kvn at openjdk.org  Tue Jan  7 23:13:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 7 Jan 2025 23:13:46 GMT
Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for
 Ampere-1A and 1B
In-Reply-To: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
References: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
Message-ID: <fRExKoJ7nxw-bO0M--h2NU7Onorr4piDVV6YKMMtLiI=.9c898a00-b32a-4dca-80f7-ca9ae5490379@github.com>

On Fri, 15 Nov 2024 07:01:23 GMT, Liming Liu <lliu at openjdk.org> wrote:

> This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128.
> 
> Ran JTReg tier1 on Ampere-1A and no new issues were found.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22134#pullrequestreview-2535545428

From coleenp at openjdk.org  Tue Jan  7 23:16:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 23:16:44 GMT
Subject: RFR: 8329549: Remove FORMAT64_MODIFIER [v3]
In-Reply-To: <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
 <YtaCMxwytUHc-wW7QCDm3pC38E3VNkMeGeFcA_zR9zc=.19d10752-c59c-4149-a423-27caad9ea373@github.com>
Message-ID: <mjMyfT6t5EPqW6i8djOD65-u5bcRLgQzHy60qqt92mQ=.a33d3345-8fa6-4548-92ca-66de024e2203@github.com>

On Tue, 7 Jan 2025 14:07:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
>> GHA tested.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   You're right, it's UINT64_FORMAT and moved the comment.

Thanks for the review Kim.

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

PR Comment: https://git.openjdk.org/jdk/pull/22918#issuecomment-2576402738

From coleenp at openjdk.org  Tue Jan  7 23:16:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 23:16:44 GMT
Subject: Integrated: 8329549: Remove FORMAT64_MODIFIER
In-Reply-To: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
References: <SFi3wjQxSBGXrfkchw_9ibNWz1tcINdDgTMCQJmuWxM=.23eab6b2-8b7c-424c-879f-37c478cdbb3a@github.com>
Message-ID: <xbJFVrYtbjRyu7btREtupNOQSmHWae6Tw3B55AYqOGo=.c1fb630d-768d-49df-8282-bfacaefc50a6@github.com>

On Fri, 3 Jan 2025 17:31:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes FORMAT64_MODIFIER but adds another INT64_FORMAT_X_0_ macro to specify not having leading "0x" in the output.  Suggestions for better macro name welcome.
> GHA tested.

This pull request has now been integrated.

Changeset: ddb58819
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ddb58819640dc8f1930d243d6eb07ce88ef79b22
Stats:     26 lines in 5 files changed: 5 ins; 14 del; 7 mod

8329549: Remove FORMAT64_MODIFIER

Reviewed-by: dholmes, kbarrett

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

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

From dholmes at openjdk.org  Wed Jan  8 00:10:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 00:10:20 GMT
Subject: RFR: 8347148: [BACKOUT]  AccessFlags can be u2 in metadata
Message-ID: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>

Revert "8339113: AccessFlags can be u2 in metadata"

This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.

The integration of the original change needs to be coordinated with a change to Graal so backing out till that is ready.

Thanks

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

Commit messages:
 - Revert "8339113: AccessFlags can be u2 in metadata"

Changes: https://git.openjdk.org/jdk/pull/22959/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22959&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347148
  Stats: 328 lines in 58 files changed: 50 ins; 45 del; 233 mod
  Patch: https://git.openjdk.org/jdk/pull/22959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22959/head:pull/22959

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

From coleenp at openjdk.org  Wed Jan  8 00:12:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 00:12:44 GMT
Subject: RFR: 8347148: [BACKOUT]  AccessFlags can be u2 in metadata
In-Reply-To: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
References: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
Message-ID: <x8vRQQTfYQ16EC0IedEe6hKfvS0aEjgmZ6Nv-vX6cVE=.47766884-6ce0-4c41-a41c-f6eeddc2e623@github.com>

On Wed, 8 Jan 2025 00:04:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8339113: AccessFlags can be u2 in metadata"
> 
> This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
> 
> The integration of the original change needs to be coordinated with a change to Graal so backing out till that is ready.
> 
> Thanks

Looks good plus urgent.  Thanks for doing this, David.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22959#pullrequestreview-2535594292

From dholmes at openjdk.org  Wed Jan  8 00:18:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 00:18:34 GMT
Subject: RFR: 8347148: [BACKOUT]  AccessFlags can be u2 in metadata
In-Reply-To: <x8vRQQTfYQ16EC0IedEe6hKfvS0aEjgmZ6Nv-vX6cVE=.47766884-6ce0-4c41-a41c-f6eeddc2e623@github.com>
References: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
 <x8vRQQTfYQ16EC0IedEe6hKfvS0aEjgmZ6Nv-vX6cVE=.47766884-6ce0-4c41-a41c-f6eeddc2e623@github.com>
Message-ID: <KiVUwU3baOLFdE6LOix3Xw0yfY-_Rp4Kt2L4zyzBh8s=.e6ed9ef9-ae1f-4c04-b6b9-100e9a45cd14@github.com>

On Wed, 8 Jan 2025 00:10:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Revert "8339113: AccessFlags can be u2 in metadata"
>> 
>> This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
>> 
>> The integration of the original change needs to be coordinated with a change to Graal so backing out till that is ready.
>> 
>> Thanks
>
> Looks good plus urgent.  Thanks for doing this, David.

Thanks for the review @coleenp ! Just waiting tier1 sanity to complete

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

PR Comment: https://git.openjdk.org/jdk/pull/22959#issuecomment-2576463303

From dholmes at openjdk.org  Wed Jan  8 00:42:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 00:42:38 GMT
Subject: Integrated: 8347148: [BACKOUT]  AccessFlags can be u2 in metadata
In-Reply-To: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
References: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
Message-ID: <9o7YHNAv4mkotoVPqwxDgL_-s1CN9UCrrIihsBVe89o=.b6337941-8549-433d-bda2-fb42c6e5b112@github.com>

On Wed, 8 Jan 2025 00:04:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8339113: AccessFlags can be u2 in metadata"
> 
> This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
> 
> The integration of the original change needs to be coordinated with a change to Graal so backing out till that is ready.
> 
> Thanks

This pull request has now been integrated.

Changeset: 021c4764
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/021c476409c52c65cc7b40516d81dedef040fe83
Stats:     328 lines in 58 files changed: 50 ins; 45 del; 233 mod

8347148: [BACKOUT]  AccessFlags can be u2 in metadata

Reviewed-by: coleenp

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

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

From dholmes at openjdk.org  Wed Jan  8 01:12:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 01:12:47 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <pfmga_UcpVOAaU1rOW3hLFjbNpKlRkr3cSsOYwp7d_Q=.c54ed21e-b502-4b64-b940-c84ebda1fc17@github.com>

On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

Test libraries belong in test/lib even if only hotspot is using this one IMO. I'd like to hear @lmesnik 's opinion on this.

Also how is this library being built for the tests to use? If relying on jtreg facilities we will likely hit the known problems that jtreg has in this area - and this library would seem a good candidate for the proposal to prebuild some test libraries when the test image is built.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576512536

From dholmes at openjdk.org  Wed Jan  8 01:16:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 01:16:33 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <bcB7Cjnw9r6n_E9U6De2neJAWFzv2o0x1he-L-08F-E=.3729d2e8-cb8e-480e-96de-f7fea88ee91b@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <bcB7Cjnw9r6n_E9U6De2neJAWFzv2o0x1he-L-08F-E=.3729d2e8-cb8e-480e-96de-f7fea88ee91b@github.com>
Message-ID: <5IYTUxLAMpubLWi2gSAh6paz3K6XWZSGeQ6Nk3ahEiw=.6a26ad2a-e88e-4430-945f-996d648b1fda@github.com>

On Tue, 7 Jan 2025 20:19:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Moving it to test/hotspot/jtreg is initially surprising, I assumed it would move to test/lib. Did you choose the hotspot tree as only tests in hotspot/jtreg use it and you didn't want to add or change the @library tag on these tests?
> 
> The other thing is the package name, maybe it should move back to org.objectweb.asm as it won't be a JDK internal package.

I also agree with @AlanBateman  about the package name. It is not appropriate for anything outside the platform modules to claim to be part of `jdk.internal`. In fact I'm surprised we are even allowed to add to that from outside the module!

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576516315

From lmesnik at openjdk.org  Wed Jan  8 01:48:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 8 Jan 2025 01:48:34 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <DlovGx6vyRnAL0x15uT5VOJezyHjp-xiwtXlR9kEo-c=.024e9228-d734-4674-82f9-99104a868ea0@github.com>

On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

I think it is make sense to put ASM into hotspot testlibrary if there are no any other users. So it is clear that non-hotspot tests don't depend on it.
There is a location
test/hotspot/jtreg/testlibrary 
for hotstpot specific libraries.
Could you please move it here.

Before renaming packages, I would like to understand if we can move to standard ASM? We are no planning to develop new tests and maintain this library for newer releases. Otherwise, keeping jdk.internal simplify backporting changes.

It is not possible to implement it as a precompiled library because of jtreg limitations to find jars in test-images. So I'll implement this later.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576544218

From iklam at openjdk.org  Wed Jan  8 02:43:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 8 Jan 2025 02:43:57 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v3]
In-Reply-To: <Rz_wLTn_6nuzC1ykXc0_X44wHnUdOxjFs6wtGRP31K8=.54ed0414-b83a-47f3-b03f-5341a2406b11@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <C_aAQOl_agKc49vGZe5pdpUIORd2HIV4stAPJ0HEnis=.a670485e-9c9e-4a99-ad18-a31b6d750e28@github.com>
 <Rz_wLTn_6nuzC1ykXc0_X44wHnUdOxjFs6wtGRP31K8=.54ed0414-b83a-47f3-b03f-5341a2406b11@github.com>
Message-ID: <eiBZ3d34SpP3oUvUVmqht75Os-bN_iXP7lmg0y0RyIM=.bd48855f-ea76-4976-ab96-521e8c15d65d@github.com>

On Tue, 7 Jan 2025 22:52:16 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Comment in `AOTClassInitializer::can_archive_initialized_mirror()` refers to `HeapShared::find_all_aot_initialized_classes()` which does not exist anymore:
> 
> ```
>   // When CDSConfig::is_initing_classes_at_dump_time() is enabled,
>   // HeapShared::find_all_aot_initialized_classes() finds the classes of all
>   // heap objects that are reachable from HeapShared::_run_time_special_subgraph,
>   // and mark these classes as aot-inited.
> ```
> 
> And this comment at line 263 in `aotClassInitializer.cpp` also needs to be updated as the enum classes are not unconditionally AOT-initialized:
> 
> ```
>       // above we selected all enums; we must include their super as well
>       {"java/lang/Enum"},
> ```

I fixed the comments and removed the entry for `java/lang/Enum`

> src/hotspot/share/cds/metaspaceShared.cpp line 548:
> 
>> 546:     FileMapInfo::metaspace_pointers_do(it);
>> 547:     AOTArtifactFinder::all_cached_classes_do(it);
>> 548:     SystemDictionaryShared::dumptime_classes_do(it);
> 
> There is some duplicatoin of work in `AOTArtifactFinder::all_cached_classes_do()` and `SystemDictionaryShared::dumptime_classes_do()`. all_cached_classes_do() operates on `_all_cached_classes` which is built using `SystemDictionaryShared::_dumptime_table`. So the iteration over `_dumptime_table` in `SystemDictionaryShared::dumptime_classes_do()` seems redundant.

The call to `SystemDictionaryShared::dumptime_classes_do()` is still necessary. It does more than just discovering the classes. It also walks the `DumpTimeClassInfo` with


info.metaspace_pointers_do(it);


which will walk the loader constraints, etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/22291#issuecomment-2576589873
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1906263814

From iklam at openjdk.org  Wed Jan  8 02:43:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 8 Jan 2025 02:43:56 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v4]
In-Reply-To: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
Message-ID: <DRyTYIrn0aCMtV4pyimQPfuG_lu5N2ZytSF1Sn5rKJQ=.fb4814b2-ea90-4cb7-993b-bac586a2e172@github.com>

> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
> 
> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
> 
> Note to reviewers:
> 
> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @ashu-mehra comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22291/files
  - new: https://git.openjdk.org/jdk/pull/22291/files/31a7e9b8..c5ed9578

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

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

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

From asmehra at openjdk.org  Wed Jan  8 04:08:43 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 8 Jan 2025 04:08:43 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v3]
In-Reply-To: <eiBZ3d34SpP3oUvUVmqht75Os-bN_iXP7lmg0y0RyIM=.bd48855f-ea76-4976-ab96-521e8c15d65d@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <C_aAQOl_agKc49vGZe5pdpUIORd2HIV4stAPJ0HEnis=.a670485e-9c9e-4a99-ad18-a31b6d750e28@github.com>
 <Rz_wLTn_6nuzC1ykXc0_X44wHnUdOxjFs6wtGRP31K8=.54ed0414-b83a-47f3-b03f-5341a2406b11@github.com>
 <eiBZ3d34SpP3oUvUVmqht75Os-bN_iXP7lmg0y0RyIM=.bd48855f-ea76-4976-ab96-521e8c15d65d@github.com>
Message-ID: <dAJTJ17Hi3uB_9hY8lYNi2KHAyvtDjFZ15oFEhqquSQ=.18557a14-b4a1-4a03-9df1-a70a99b7d88f@github.com>

On Wed, 8 Jan 2025 02:41:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/metaspaceShared.cpp line 548:
>> 
>>> 546:     FileMapInfo::metaspace_pointers_do(it);
>>> 547:     AOTArtifactFinder::all_cached_classes_do(it);
>>> 548:     SystemDictionaryShared::dumptime_classes_do(it);
>> 
>> There is some duplicatoin of work in `AOTArtifactFinder::all_cached_classes_do()` and `SystemDictionaryShared::dumptime_classes_do()`. all_cached_classes_do() operates on `_all_cached_classes` which is built using `SystemDictionaryShared::_dumptime_table`. So the iteration over `_dumptime_table` in `SystemDictionaryShared::dumptime_classes_do()` seems redundant.
>
> The call to `SystemDictionaryShared::dumptime_classes_do()` is still necessary. It does more than just discovering the classes. It also walks the `DumpTimeClassInfo` with
> 
> 
> info.metaspace_pointers_do(it);
> 
> 
> which will walk the loader constraints, etc.

Right, missed that. Thanks for pointing that out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1906433520

From kbarrett at openjdk.org  Wed Jan  8 04:25:18 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Jan 2025 04:25:18 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v5]
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <kh2Ws276RK5M4JWMtOc28zJ3A9ZwV51eB8iH9u2_Cqo=.b5396e95-a37c-4188-8e98-2993a46d0d96@github.com>

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  aix permit patches

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22890/files
  - new: https://git.openjdk.org/jdk/pull/22890/files/c478bda1..b774f14c

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

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

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

From kbarrett at openjdk.org  Wed Jan  8 04:27:37 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Jan 2025 04:27:37 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v4]
In-Reply-To: <fxDnyYA1AHns3gXjtAyAMzujRJdrYzBcYbulbB5tQGM=.b5c0a410-a801-464e-a2f5-191df85c9461@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <mgaIxADi54AaczgDWzqFm3WUzMu2tqApcxrZ2oh_4Mc=.1e792b0f-89a8-460e-a96b-6cb0f6f74a3a@github.com>
 <fxDnyYA1AHns3gXjtAyAMzujRJdrYzBcYbulbB5tQGM=.b5c0a410-a801-464e-a2f5-191df85c9461@github.com>
Message-ID: <CCQxWvwxnvV8bu6FZeM8YrRGlOEmf_MTf5wyBDnm5xs=.b7735ca9-37ab-4f52-9daa-dcad3595efbe@github.com>

On Tue, 7 Jan 2025 15:18:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks! That solved the issue. Now, we need to adapt all usages in the low level AIX code and support `strdup`:

Not surprising that there are a few of these, since the aix-specific code
wasn't previously under the forbidden-function regime.

I've applied most of the provided patches. (And thanks for providing them.)
The exception is the patches related to strdup. There's only one use, in
loadlib_aix.cpp. Rather than the patch to add a permit wrapper for strdup
(affecting all other code too) and use that here, I'd rather just suppress the
warning explicitly here.

I filed an enhancement to remove the use of ::strdup.
https://bugs.openjdk.org/browse/JDK-8347157

I also filed this after looking for strdup uses in aix code.
https://bugs.openjdk.org/browse/JDK-8347143
It's about a strange use of os::strdup, so doesn't affect this PR.

> It may be possible to use some `os::` versions, but that would need a careful review. I think it's safer to keep it this way for now. @JoKern65: You may want to take a look, too.

I'll leave it to you folks to file any additional issues related to using
permit bypass functions instead of the relevant os:: functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2576721514

From sspitsyn at openjdk.org  Wed Jan  8 05:38:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Jan 2025 05:38:45 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <QWoG2cS_0x3MjB_ybdYb2k3mDvjyVwjAANR_83DCnqM=.cedd4f1a-f3d7-4701-ab72-cd0b9c7757e2@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

The fix looks good. It is a great and important finding - thanks!
What was bothering me is that the `EnterInterpOnlyModeClosure` is used in the `JvmtiEventControllerPrivate::enter_interp_only_mode()` but no `HandshakeClosure` is used in the `JvmtiEventControllerPrivate::leave_interp_only_mode()`. The handshake use for the `enter_interp_only_mode()` looks like a paranoid overkill to me. It can be I just forgot the exact reason why it is used there.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22931#pullrequestreview-2536049299

From kbarrett at openjdk.org  Wed Jan  8 06:20:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Jan 2025 06:20:38 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
 <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
Message-ID: <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>

On Mon, 6 Jan 2025 01:35:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If I was going to go that route, I'd be more inclined toward
>> 
>> #if !define(_WINDOWS)
>> #include "forbiddenFunctions_windows.hpp"
>> #else
>> #include "forbiddenFunctions_posix.hpp"
>> #endif
>> 
>> rather than list all (or maybe just a subset) of the posix-like ports.  My
>> inclination is to leave it as-is with OS_HEADERS, since I think that's the
>> "intended" idiom.
>
> Overall I like this change. I appreciate the effort that has been put in to try and find an elegant solution to this problem.
> 
> but having OS specific files created just to include the posix version runs counter to why we have the posix variants in the first place IMO. Please select one of the above approaches so that the new aix/bsd/linux specific files can be removed in favour of the posix one. Thanks.

I disagree. It seems to me that breaking the abstraction like that is just asking for trouble.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1906533984

From asotona at openjdk.org  Wed Jan  8 06:54:35 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Jan 2025 06:54:35 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <DlovGx6vyRnAL0x15uT5VOJezyHjp-xiwtXlR9kEo-c=.024e9228-d734-4674-82f9-99104a868ea0@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <DlovGx6vyRnAL0x15uT5VOJezyHjp-xiwtXlR9kEo-c=.024e9228-d734-4674-82f9-99104a868ea0@github.com>
Message-ID: <R8X799JZkfptATR50CoMLU6ix-1dycL5nO5LLalgvNU=.9f97bd92-4495-4091-aae3-d6ae431e4154@github.com>

On Wed, 8 Jan 2025 01:45:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> I think it is make sense to put ASM into hotspot testlibrary if there are no any other users. So it is clear that non-hotspot tests don't depend on it.
> There is a location
> test/hotspot/jtreg/testlibrary 
> for hotstpot specific libraries.
> Could you please move it here.
> 
> Before renaming packages, I would like to understand if we can move to standard ASM? We are no planning to develop new tests and maintain this library for newer releases. Otherwise, keeping jdk.internal simplify backporting changes.
> 
> It is not possible to implement it as a precompiled library because of jtreg limitations to find jars in test-images. So I'll implement this later.

I agree with @lmesnik that any unnecessary repackaging would affect backporting compatibility (>1200 unnecessary changes across >250 source files causing potential conflicts).

My question to test/hotspot/jtreg/testlibrary - is it effective to mix existing testlibrary with ASM. From the hotspot tests I see not all tests requiring testlibrary need ASM and vice versa. And many tests include other test libraries. However maybe it is irrelevant.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576876491

From alanb at openjdk.org  Wed Jan  8 06:59:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Jan 2025 06:59:44 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <CHyeeSxfLWmPcYyIUOiXpSwUFDGhagofOvSd06a6f-Y=.be0007ef-d41d-4aa1-89e6-d32145235ded@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <CHyeeSxfLWmPcYyIUOiXpSwUFDGhagofOvSd06a6f-Y=.be0007ef-d41d-4aa1-89e6-d32145235ded@github.com>
Message-ID: <QwBDdjB2iCw10Rv65DFw33Y4xMlJnIA-_19wADxnT-0=.fc980bf2-d114-42ca-a7b1-4d8e102f847c@github.com>

On Tue, 7 Jan 2025 22:19:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Despite the 265 modified files is this PR trying to be minimalistic. Repackaging of the library would be far more complex and would affect significantly more files, including the library itself. I would recommend to invest that effort into the tests conversion into Class-File API instead.

I'm not suggesting any re-packaging or pre-packaging, just saying that you can revert the changes that we have in the jdk repo so it goes back to .org.objectweb.asm. If we aren't doing that then okay but we still need to change all the tests that use it to remove "@modules java.base/jdk.internal.org.objectweb.asm".

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576882323

From asotona at openjdk.org  Wed Jan  8 07:05:45 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Jan 2025 07:05:45 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <QwBDdjB2iCw10Rv65DFw33Y4xMlJnIA-_19wADxnT-0=.fc980bf2-d114-42ca-a7b1-4d8e102f847c@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <CHyeeSxfLWmPcYyIUOiXpSwUFDGhagofOvSd06a6f-Y=.be0007ef-d41d-4aa1-89e6-d32145235ded@github.com>
 <QwBDdjB2iCw10Rv65DFw33Y4xMlJnIA-_19wADxnT-0=.fc980bf2-d114-42ca-a7b1-4d8e102f847c@github.com>
Message-ID: <Do3DcV1AgC5je3LLDnBlzafX26FkhJcPWg0IKLohFq4=.a7552786-3917-4970-97b0-a9355ba831ee@github.com>

On Wed, 8 Jan 2025 06:57:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> you can revert the changes that we have in the jdk repo so it goes back to .org.objectweb.asm

that represents a refactoring with >1200 changes in >250 files across multiple repositories

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576889598

From alanb at openjdk.org  Wed Jan  8 07:08:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Jan 2025 07:08:34 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <5IYTUxLAMpubLWi2gSAh6paz3K6XWZSGeQ6Nk3ahEiw=.6a26ad2a-e88e-4430-945f-996d648b1fda@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <bcB7Cjnw9r6n_E9U6De2neJAWFzv2o0x1he-L-08F-E=.3729d2e8-cb8e-480e-96de-f7fea88ee91b@github.com>
 <5IYTUxLAMpubLWi2gSAh6paz3K6XWZSGeQ6Nk3ahEiw=.6a26ad2a-e88e-4430-945f-996d648b1fda@github.com>
Message-ID: <VX_xza745OKKjNEhlFKlyXBUdJDPcaLKOaI4bNc-1YE=.4c7d7d0b-3bd2-497d-9a6d-7800436732d5@github.com>

On Wed, 8 Jan 2025 01:14:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> It is not appropriate for anything outside the platform modules to claim to be part of `jdk.internal`. In fact I'm surprised we are even allowed to add to that from outside the module!

There's nothing to prohibit this, it's just surprising to have classes in jdk.internal.obj.objectweb.asm in an unnamed module, it will work of course.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576894583

From lmesnik at openjdk.org  Wed Jan  8 07:12:35 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 8 Jan 2025 07:12:35 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <4QEGZN9Q1i4qxuYSaP5Hsl4HsVqpiiyIgOnx_yUp61o=.a20ae6e2-85e8-4848-9c4f-dcf720b63fe3@github.com>

On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

so you if add asm and use it like
`* @library  /testlibrary/asm`
it should fit.
There are tests that use 
`* @library /testlibrary`
but seems it is redundant and leftover after merging hostpot and jdk. I'll file bug to clean up this.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576899567

From asotona at openjdk.org  Wed Jan  8 07:21:36 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Jan 2025 07:21:36 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v2]
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <huTabpsxLKQvkC_EnuYVrPZ8Ch1Tj53X0adEBIwCD6E=.58581a3d-b4d0-44e3-81c0-5b359c334cd5@github.com>

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  asm move under test/hotspot/jtreg/testlibrary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22946/files
  - new: https://git.openjdk.org/jdk/pull/22946/files/f94d79e4..56fc9e41

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

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

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

From jsjolen at openjdk.org  Wed Jan  8 11:04:39 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 8 Jan 2025 11:04:39 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <pOSDbb7W0iQO6bWIBVbqwqIBAH17Vx2zmJOdyel8Cpk=.25710294-ffba-4484-839d-b2f3a5ee028e@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <pOSDbb7W0iQO6bWIBVbqwqIBAH17Vx2zmJOdyel8Cpk=.25710294-ffba-4484-839d-b2f3a5ee028e@github.com>
Message-ID: <QMbKo48O5-iB2twQCVeeUBLQSTa8-AukTGFK1ln6a5U=.65fa595a-ee3b-44a8-b7c3-fd46b22456b1@github.com>

On Tue, 7 Jan 2025 17:11:20 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed coloring functions
>
> src/hotspot/share/utilities/rbTree.hpp line 308:
> 
>> 306: 
>> 307:   void free(void* ptr) { os::free(ptr); }
>> 308: };
> 
> An issue with this allocator is that it doesn't call destructors on `free`. I think we should add this, or any future users may leak memory by mistake.

Some more thoughts: It's not the allocator that should run the destructor, but the RBTree itself. It should probably enforce that the key is a trivial type also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1907005846

From mdoerr at openjdk.org  Wed Jan  8 11:17:37 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Jan 2025 11:17:37 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v5]
In-Reply-To: <kh2Ws276RK5M4JWMtOc28zJ3A9ZwV51eB8iH9u2_Cqo=.b5396e95-a37c-4188-8e98-2993a46d0d96@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <kh2Ws276RK5M4JWMtOc28zJ3A9ZwV51eB8iH9u2_Cqo=.b5396e95-a37c-4188-8e98-2993a46d0d96@github.com>
Message-ID: <t_bW3JXvffDPuoWvk5exKlAciivZ-2pZvGojhLYTaqA=.a453f400-0953-4b50-be64-620a446f5ced@github.com>

On Wed, 8 Jan 2025 04:25:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aix permit patches

Thanks! The AIX build was successful with the recent changes.
Regarding [JDK-8347157](https://bugs.openjdk.org/browse/JDK-8347157), I don't think we should use `os::strdup` in `StringList` because the class is designed to use raw malloc. I guess @JoKern65 can take a look at the 2 RFEs.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2577419121

From mdoerr at openjdk.org  Wed Jan  8 11:33:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Jan 2025 11:33:41 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <nRU9k-eee7oCZ8PjFt3uwAhTgwHtklr57rORR8Wru18=.ddfb2dbe-cc97-4dfa-867a-3bc885623b29@github.com>

On Wed, 25 Dec 2024 15:40:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

Thanks for the review!
I haven't found precise rules how to handle Copyright headers. I usually use the year of the PR publication date. Does anybody know other requirements?

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

PR Comment: https://git.openjdk.org/jdk/pull/22881#issuecomment-2577447378

From jsjolen at openjdk.org  Wed Jan  8 12:11:49 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 8 Jan 2025 12:11:49 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v5]
In-Reply-To: <kh2Ws276RK5M4JWMtOc28zJ3A9ZwV51eB8iH9u2_Cqo=.b5396e95-a37c-4188-8e98-2993a46d0d96@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <kh2Ws276RK5M4JWMtOc28zJ3A9ZwV51eB8iH9u2_Cqo=.b5396e95-a37c-4188-8e98-2993a46d0d96@github.com>
Message-ID: <nIqXBZNd8p6wiGrliKiXPP_JmS9-xHxjB5TU6q2b-Mo=.9b1f7916-0996-44c6-98a1-504424a02808@github.com>

On Wed, 8 Jan 2025 04:25:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aix permit patches

If this passes testing and David's comments are fixed, then I'm very happy with this PR as it is. Thank you for this.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22890#pullrequestreview-2536977481

From gcao at openjdk.org  Wed Jan  8 12:41:39 2025
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 8 Jan 2025 12:41:39 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v6]
In-Reply-To: <vQqj01yERuZXYKDqyu9OOJnRaKQUJ_jQfePafsRTgvo=.877c8fb5-249e-4804-8d17-ad0ff3151d7e@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <vQqj01yERuZXYKDqyu9OOJnRaKQUJ_jQfePafsRTgvo=.877c8fb5-249e-4804-8d17-ad0ff3151d7e@github.com>
Message-ID: <IS__B1DTruJL4ZEYMVHHCMVB5Dtn8fCu4kI3I-M_tj8=.e672ad2e-4917-4f56-81b0-070c35f3cf40@github.com>

On Wed, 11 Dec 2024 07:23:18 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comment

bot, please keep it open

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

PR Comment: https://git.openjdk.org/jdk/pull/21922#issuecomment-2577576314

From coleenp at openjdk.org  Wed Jan  8 13:26:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 13:26:49 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
 <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
 <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>
Message-ID: <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>

On Wed, 8 Jan 2025 06:18:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Overall I like this change. I appreciate the effort that has been put in to try and find an elegant solution to this problem.
>> 
>> but having OS specific files created just to include the posix version runs counter to why we have the posix variants in the first place IMO. Please select one of the above approaches so that the new aix/bsd/linux specific files can be removed in favour of the posix one. Thanks.
>
> I disagree. It seems to me that breaking the abstraction like that is just asking for trouble.

Yes, I think it's fine to say !WINDOWS instead of listing all the posix ports.  We've been avoiding dispatch files and once it reaches a threshold of too many #ifdef !WINDOWS #include posix.hpp one, then we could add another macro like the OS_CPU one.

Also the copyright script added 2025 for these because they started with 2024 so it's sort of a bug in the script but not really solvable because it doesn't know that you didn't check this in in 2024.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1907176766

From coleenp at openjdk.org  Wed Jan  8 13:43:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 13:43:52 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata
Message-ID: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>

This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.

A tier1 sanity test in progress.

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

Commit messages:
 - 8347147: [REDO] AccessFlags can be u2 in metadata

Changes: https://git.openjdk.org/jdk/pull/22968/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22968&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347147
  Stats: 328 lines in 58 files changed: 45 ins; 50 del; 233 mod
  Patch: https://git.openjdk.org/jdk/pull/22968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22968/head:pull/22968

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

From fgao at openjdk.org  Wed Jan  8 13:49:33 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 8 Jan 2025 13:49:33 GMT
Subject: RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let
 legitimize_address() fix out-of-range operands [v2]
In-Reply-To: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
References: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
Message-ID: <gWSKYAcn6p7WOUTeUnYBw1Rd6bA6oGHTrF7aTZ6Oxr4=.30226cab-3fbb-4fe6-90e3-7701f5e2dc39@github.com>

> `IndOffXX` types don't do us any good. It would be simpler and faster to match a general-purpose `IndOff` type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.
> 
> This patch simplifies the definitions of `immXOffset` with an estimated range. Whether an immediate can be encoded in a `LDR`/`STR` instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessary `legitimize_address()` in the phase of matcher for all `LDR`/`STR` instructions using the new `IndOff` memory operands (fix [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437)).
> 
> After this clean-up, memory operands matched with `IndOff` may require extra code emission (effectively a `lea`) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646)). On `aarch64` platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. Because `LDR`/`STR` is always the last one emitted, no matter what addressing mode the load/store operations finally use.
> 
> Tier 1 - 3 passed on `Macos-aarch64` with or without the vm option `-XX:+UseZGC`.

Fei Gao 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 three additional commits since the last revision:

 - Update the copyright year and code comments
 - Merge branch 'master' into cleanup_indoff
 - 8341611: [REDO] AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands
   
   IndOffXX types don't do us any good. It would be simpler and
   faster to match a general-purpose IndOff type then let
   legitimize_address() fix any out-of-range operands. That'd
   reduce the size of the match rules and the time to run them.
   
   This patch simplifies the definitions of `immXOffset` with an
   estimated range. Whether an immediate can be encoded in a
   LDR/STR instructions as an offset will be determined in the phase
   of code-emitting. Meanwhile, we add necessary
   `legitimize_address()` in the phase of matcher for all LDR/STR
   instructions using the new `IndOff` memory operands
   (fix JDK-8341437).
   
   After this clean-up, memory operands matched with `IndOff` may
   require extra code emission (effectively a lea) before the address
   can be used. So we also modify the code about looking up precise
   offset of load/store instruction for implicit null check
   (fix JDK-8340646). On aarch64 platform, we will use the beginning
   offset of the last instruction in the instruction clause emitted
   for a load/store machine node. Because LDR/STR is always the last
   one emitted, no matter what addressing mode the load/store
   operations finally use.
   
   Tier 1 - 3 passed on Macos-aarch64 with or without the vm option
   "-XX:+UseZGC"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22862/files
  - new: https://git.openjdk.org/jdk/pull/22862/files/699417f8..3f12b1c8

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

  Stats: 12078 lines in 314 files changed: 8176 ins; 2888 del; 1014 mod
  Patch: https://git.openjdk.org/jdk/pull/22862.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22862/head:pull/22862

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

From fgao at openjdk.org  Wed Jan  8 13:54:41 2025
From: fgao at openjdk.org (Fei Gao)
Date: Wed, 8 Jan 2025 13:54:41 GMT
Subject: RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let
 legitimize_address() fix out-of-range operands [v2]
In-Reply-To: <7KNxpwpRzo3wWkNqMLplSIKhGwRwqBTLxVPhKJHst6w=.45c448e0-c061-441f-aecf-68ce6ec01d3a@github.com>
References: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
 <7KNxpwpRzo3wWkNqMLplSIKhGwRwqBTLxVPhKJHst6w=.45c448e0-c061-441f-aecf-68ce6ec01d3a@github.com>
Message-ID: <ycInBAMZJQCXrAl4a6gCdZNbUDkI3u3SJjxtAhKl-PI=.76b3d088-5a61-4884-89d4-9f521a5fc023@github.com>

On Tue, 7 Jan 2025 17:11:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Yes, as expected, `legitimize_address` splitting is very rare. As you suggested, I compiled all of `java.base` with built `javac` and found over `700k` `load/store` generated by C2 but no `legitimize_address` splitting. Actually, no `legitimize_address` splitting happened even I did `make bootcycle-images`. From our experience, `Unsafe` APIs can generate unaligned offsets and some corner cases may generate out-of-range offsets.
> 
> Good enough for me. I made a couple of suggestions about comments.

Updated in the new commit. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22862#issuecomment-2577721827

From epeter at openjdk.org  Wed Jan  8 14:13:40 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 8 Jan 2025 14:13:40 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>
 <H_eWDODWEakhmBpbiL2apPxV9iJeeoTFBjSBsagytNI=.0efc7881-efbc-4609-8982-17eb13f3c56a@github.com>
 <xCmBgJGY_IQMTbqFxlT3WKxI4ZQ9x4kgryTmUX8w3xU=.acbcba77-a4d3-4feb-87f2-2e12ea2477bc@github.com>
 <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>
Message-ID: <p-mnNNcuHXqMfaqSxOMBwJKoS1ywGs6i2fLqGxzxmFg=.aad9adb5-92fb-4147-9a37-135ed5a8ba50@github.com>

On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > Can you quickly summarize what tests you have, and what they test?
>>> 
>>> Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
>> 
>> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.
>
>> > > Can you quickly summarize what tests you have, and what they test?
>> > 
>> > 
>> > Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
>> 
>> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.
> 
> 
> Validations details:-
> 
> A) x86 backend changes
>    - new assembler instruction
>    - macro assembly routines. 
>     Test point:-  test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java
>          - This test is based on a testng framework and includes new DataProviders to generate test vectors.
>          -  Test vectors cover the entire float16 value range and also special floating point values (NaN, +Int, -Inf, 0.0 and -0.0) 
> B) GVN transformations:-
>      -  Value Transforms
>         Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>               -  Covers all the constant folding scenarios for add, sub, mul, div, sqrt, fma, min, and max operations addressed by this patch.
>               -  It also tests special case scenarios for each operation as specified by Java language specification.
>     -   identity Transforms
>         Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>                -  Covers identity transformation for  ReinterpretS2HFNode,  DivHFNode
>     -  idealization Transforms
>         Test points:-  test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java
>                                 :-   test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>             - Contains test point for the following transform 
>                          MulHF idealization i.e. MulHF * 2 => AddHF  
>            -  Contains test point for the following transform
>                          DivHF SRC ,  PoT(constant) =>  MulHF SRC * reciprocal (constant) 
>             - Contains idealization test points for the following transform 
>                    ConvF2HF(FP32BinOp(ConvHF2F(x), ConvHF2F(y))) =>
>                            ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y)))

@jatin-bhateja Is this ready for another review pass?

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

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2577768041

From sgehwolf at openjdk.org  Wed Jan  8 14:30:17 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 8 Jan 2025 14:30:17 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime
Message-ID: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>

Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.

Testing:
- [ ] GHA
- [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.

Thoughts?

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

Commit messages:
 - 8347124: Clean tests with --enable-linkable-runtime

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

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

From coleenp at openjdk.org  Wed Jan  8 14:49:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 14:49:35 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata
In-Reply-To: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
Message-ID: <7NzZ7Lj7Aapsnt9zTgcJ7KUzLWNHNiskGiePGkpQIxU=.7c6779dd-6194-4a20-a598-c65bffff1c89@github.com>

On Wed, 8 Jan 2025 13:38:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
> 
> A tier1 sanity test complete.

PR for original review here: https://github.com/openjdk/jdk/pull/22246

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

PR Comment: https://git.openjdk.org/jdk/pull/22968#issuecomment-2577853778

From azafari at openjdk.org  Wed Jan  8 15:31:24 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 8 Jan 2025 15:31:24 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v12]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <hDXz_W9BCZMczZj4FBWbF7DgWYwFoUN16XfrkMk9AtQ=.bd6c4c8b-5ccb-42d0-ae89-7e37b8158734@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - visit committed regions refined.
 - visit_committed_regions signature changed.
 - removed unused local var.
 - a missed change in a shenandoah file.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - some fixes.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - Roberto's feedback applied.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - ... and 45 more: https://git.openjdk.org/jdk/compare/b741f3fe...2afb8c79

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

Changes: https://git.openjdk.org/jdk/pull/20425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=11
  Stats: 3042 lines in 47 files changed: 1264 ins; 1528 del; 250 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 amitkumar at openjdk.org  Wed Jan  8 16:20:51 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 8 Jan 2025 16:20:51 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <o4q7adGK4N_hdkoweHUlmxGJczkJ63Ld1lJk0t092D4=.cd018e69-737c-41d0-a30d-96f9bf2a933c@github.com>

On Wed, 25 Dec 2024 15:40:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

I have seen header getting updated for some PRs like this one: https://github.com/openjdk/jdk/pull/22246

So I think we are expected to update, I haven?t seen any such rule though?

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

PR Comment: https://git.openjdk.org/jdk/pull/22881#issuecomment-2578080249

From mdoerr at openjdk.org  Wed Jan  8 16:23:59 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Jan 2025 16:23:59 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <5Vxiu4Z9eBZtOvIRdXnMqzRHMvqcm61fZWDO9k2ePtY=.ff04e851-2798-4f21-a8c8-8e0bdabed5d6@github.com>

On Wed, 25 Dec 2024 15:40:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

> I have seen header getting updated for some PRs like this one: #22246
> 
> So I think we are expected to update, I haven?t seen any such rule though?

Some people use a script, but it's unclear if it does the right thing: https://github.com/openjdk/jdk/pull/22890#discussion_r1907176766

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

PR Comment: https://git.openjdk.org/jdk/pull/22881#issuecomment-2578085986

From vpaprotski at openjdk.org  Wed Jan  8 16:26:46 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 8 Jan 2025 16:26:46 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni
In-Reply-To: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
Message-ID: <svpzV8Ti5Za8RQ_fhSB-x4np6O1zT4hrrMRPwPD8NEU=.55914cca-f307-4d8b-a59d-bb2fca9583a7@github.com>

On Tue, 10 Dec 2024 23:45:37 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> @TobiHartmann  There are still some unanswered questions I have, but committing this since we need to work around vacation schedules.
> 
> **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This fix fixes the crash but I don't understand entirely why the crash happens in the first place.
> 
> The issue fixed here are all the CheckJNI warnings:
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> Crash has nothing to do with String.indexOf work, but was introduced by my `8319429: Resetting MXCSR flags degrades ecore` change. I was able to get HelloWorld to crash on Windows (`-Xcheck:jni -XX:+EnableX86ECoreOpts`). Same command on linux produces hundreds of CheckJNI warnings. Is it odd that its only being found now, no other CheckJNI tests?
> 
> I would appreciate some help/reviews from somebody more aware of the Java-to-C linkage. I think I got the masks fixed, but there is one specific place (see the 'FIXME' question in the diff) for Windows I am not certain about. (@sviswa7 is on vacation for few more weeks)
> 
> Note: Crash on windows (if I have the Windows debugger actually correct), happens on:
> 
> 0x000001f2525f13c1:   fxrstor64 (%rsp)
> Stack:
> 0x00000088f1bfe060:   00007ff8b4384310 0000025bfaeb2200
> 
> 
> `00007ff8` _seems_ like a valid mxcsr value, only way it should crash is if top 2 bytes weren't zeroes, which they are.

(back from vacation. After discussing this with Sandhya, will have an update soon)

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

PR Comment: https://git.openjdk.org/jdk/pull/22673#issuecomment-2578090185

From duke at openjdk.org  Wed Jan  8 16:38:50 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 8 Jan 2025 16:38:50 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v13]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <-HnLiN9gQYv9-y-_30kif20f-OE7SuGpRmIHQ_ddIrU=.7ce6c92d-aa43-401f-a8ff-74f92d7eefef@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  use Threads::is_single_threaded()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/5e36546e..379eaac8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=11-12

  Stats: 38 lines in 7 files changed: 15 ins; 17 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

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

From coleenp at openjdk.org  Wed Jan  8 16:40:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 16:40:59 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v2]
In-Reply-To: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
Message-ID: <8tNmyDP0TIeRCdxsXomkLvU5Xqq3ACegEUHDPe-jPSc=.df292c1b-f901-4068-8915-c501d4ee8ab1@github.com>

> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
> 
> A tier1 sanity test complete.

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

  Fix some more triggerUnloading() in tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22968/files
  - new: https://git.openjdk.org/jdk/pull/22968/files/71419187..9b2abf9c

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

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

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

From coleenp at openjdk.org  Wed Jan  8 16:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 16:43:51 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v3]
In-Reply-To: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
Message-ID: <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>

> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
> 
> A tier1 sanity test complete.

Coleen Phillimore has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:

  8347147: [REDO] AccessFlags can be u2 in metadata

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22968/files
  - new: https://git.openjdk.org/jdk/pull/22968/files/9b2abf9c..71419187

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

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

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

From sroy at openjdk.org  Wed Jan  8 17:26:06 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 8 Jan 2025 17:26:06 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v2]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <bLP9ehhNk6g960i26YxgjqPzUB5eB_Kc5PpXedrVp10=.cc6f7f59-0a0c-4f84-ba50-6b72d3b24c66@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  reuse registers to reduce count

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/9dea4fc0..4c0d0eab

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

  Stats: 85 lines in 1 file changed: 9 ins; 20 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

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

From sroy at openjdk.org  Wed Jan  8 17:30:02 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 8 Jan 2025 17:30:02 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v3]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <rhdg0YwwIgtOLL0MXMoDAOXqEKXZU2wR8KXS7zbUTaY=.db293014-346f-4f7c-95b7-425d79303801@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  check for vsx

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/4c0d0eab..08535915

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

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

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

From pchilanomate at openjdk.org  Wed Jan  8 17:35:41 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 8 Jan 2025 17:35:41 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <QWoG2cS_0x3MjB_ybdYb2k3mDvjyVwjAANR_83DCnqM=.cedd4f1a-f3d7-4701-ab72-cd0b9c7757e2@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
 <QWoG2cS_0x3MjB_ybdYb2k3mDvjyVwjAANR_83DCnqM=.cedd4f1a-f3d7-4701-ab72-cd0b9c7757e2@github.com>
Message-ID: <VPN9tX4vajCaJZ5PaWycbxzVqX4u9Sr-Ou7tsrMG7mA=.156b8712-03a8-4a57-8a04-8930bbe6bcc9@github.com>

On Wed, 8 Jan 2025 05:35:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix looks good. It is a great and important finding - thanks! What was bothering me is that the `EnterInterpOnlyModeClosure` is used in the `JvmtiEventControllerPrivate::enter_interp_only_mode()` but no `HandshakeClosure` is used in the `JvmtiEventControllerPrivate::leave_interp_only_mode()`. The handshake use for the `enter_interp_only_mode()` looks like a paranoid overkill to me. It can be I just forgot the exact reason why it is used there.
>
I see. Yes, we still need the handshake in `JvmtiEventControllerPrivate::enter_interp_only_mode` to safely walk the stack of the target to deoptimize the frames. When leaving interpreter only mode we just decrement `_interp_only_mode/_saved_interp_only_mode` so I don?t think we need anything else, other than making sure the change is atomic, which I think we guarantee by holding `JvmtiThreadState_lock`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22931#issuecomment-2578238579

From sroy at openjdk.org  Wed Jan  8 17:46:28 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 8 Jan 2025 17:46:28 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v4]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <a2XGUZsC-kqHBMmn11Zxcg1U8x9CHTMrR5fl3KKzarI=.1647b7e8-0d29-4a94-9c83-eb99dfbddf9c@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 -  clearing bits
 -  clearing bits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/08535915..cd121d07

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

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

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

From sroy at openjdk.org  Wed Jan  8 17:46:29 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 8 Jan 2025 17:46:29 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v4]
In-Reply-To: <Q0Gew_GeNQLcwFQAZ3eiisUOCBMaAv8mHLpQOvSHSsM=.142a184c-5b17-4eef-8c74-497cb26c4635@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <Q0Gew_GeNQLcwFQAZ3eiisUOCBMaAv8mHLpQOvSHSsM=.142a184c-5b17-4eef-8c74-497cb26c4635@github.com>
Message-ID: <1KCTAPpnuy-hlRDH1FSYy4O8N37kYRBkFyQ3wmKPRe8=.2d2a0837-eaa3-4bc9-88db-febe686a6e90@github.com>

On Fri, 20 Dec 2024 17:19:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  -  clearing bits
>>  -  clearing bits
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 713:
> 
>> 711:   __ vxor(vTmp1, vTmp1, vTmp1);
>> 712:   __ vxor(vZero, vZero, vZero);
>> 713:   __ mtctr(blocks);
> 
> Can `blocks` be 0?
> `blocks` is an int. The higher half of the register may possibly contain garbage and should be cleared. (Can be combined with 0 check if needed.)

(https://github.com/openjdk/jdk/blob/a641932427cbe8453130593355372837d70a098f/src/java.base/share/classes/com/sun/crypto/provider/GHASH.java#L281) In the java code, the 0 check is handled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1907562020

From stooke at openjdk.org  Wed Jan  8 18:01:27 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 8 Jan 2025 18:01:27 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v3]
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <VMnZyQk__1dIZurrIBbYdzU9nKyN61pSWUWpPpsHco4=.e5b19d2f-4b29-4527-9f89-140502c2cec8@github.com>

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Simon Tooke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'openjdk:master' into pr_8346717
 - refine jtreg tags per review
 - Merge branch 'pr_8346717' of https://github.com/stooke/jdk into pr_8346717
 - restore deleted function name
 - add ZGC run of SystemMapTest
 - fix test for unready thread on Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22870/files
  - new: https://git.openjdk.org/jdk/pull/22870/files/9819f027..f47f9425

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

  Stats: 17637 lines in 241 files changed: 6043 ins; 10628 del; 966 mod
  Patch: https://git.openjdk.org/jdk/pull/22870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22870/head:pull/22870

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

From vlivanov at openjdk.org  Wed Jan  8 19:17:11 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 8 Jan 2025 19:17:11 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v3]
In-Reply-To: <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
 <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
Message-ID: <cWy9x1rHhncmchshDYO9u2399BaiharSu2GcJdftHrw=.d583f27f-ef48-4590-b6fd-922558ec9b23@github.com>

On Wed, 8 Jan 2025 16:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
>> 
>> A tier1 sanity test complete.
>
> Coleen Phillimore has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8347147: [REDO] AccessFlags can be u2 in metadata

Reviewed.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22968#pullrequestreview-2537996774

From yzheng at openjdk.org  Wed Jan  8 19:50:44 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 8 Jan 2025 19:50:44 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v3]
In-Reply-To: <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
 <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
Message-ID: <Dq3Dxp2sgPWU0T7IipaXNwgjzfxGCjD9LydU24o9ExI=.ac5cc352-67ef-4638-ba5a-f599e390a44d@github.com>

On Wed, 8 Jan 2025 16:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
>> 
>> A tier1 sanity test complete.
>
> Coleen Phillimore has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8347147: [REDO] AccessFlags can be u2 in metadata

Marked as reviewed by yzheng (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22968#pullrequestreview-2538071009

From coleenp at openjdk.org  Wed Jan  8 19:50:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 19:50:44 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v3]
In-Reply-To: <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
 <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
Message-ID: <GDiLKcqwNaKTAQSDnM8C0OuxTkr1yScHwYTN83_-2Ps=.f3f8b239-72e4-4438-958b-7eebd6da337f@github.com>

On Wed, 8 Jan 2025 16:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
>> 
>> A tier1 sanity test complete.
>
> Coleen Phillimore has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8347147: [REDO] AccessFlags can be u2 in metadata

Thank you for the re-review Vladimir and Yudi.

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

PR Comment: https://git.openjdk.org/jdk/pull/22968#issuecomment-2578500217

From coleenp at openjdk.org  Wed Jan  8 19:50:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 19:50:45 GMT
Subject: Integrated: 8347147: [REDO] AccessFlags can be u2 in metadata
In-Reply-To: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
Message-ID: <tJrtkuZoPY8e5_JsEilAHfsQ9NfOhRlaE6GwJaEIMts=.335092d5-7b53-4416-845e-bb1fa25fa3e9@github.com>

On Wed, 8 Jan 2025 13:38:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
> 
> A tier1 sanity test complete.

This pull request has now been integrated.

Changeset: 6ee2bd2f
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ee2bd2f33e38c13f93fba9953b33850828d031b
Stats:     328 lines in 58 files changed: 45 ins; 50 del; 233 mod

8347147: [REDO] AccessFlags can be u2 in metadata

Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Reviewed-by: vlivanov, yzheng

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

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

From mdoerr at openjdk.org  Wed Jan  8 20:51:40 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 8 Jan 2025 20:51:40 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v4]
In-Reply-To: <1KCTAPpnuy-hlRDH1FSYy4O8N37kYRBkFyQ3wmKPRe8=.2d2a0837-eaa3-4bc9-88db-febe686a6e90@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <Q0Gew_GeNQLcwFQAZ3eiisUOCBMaAv8mHLpQOvSHSsM=.142a184c-5b17-4eef-8c74-497cb26c4635@github.com>
 <1KCTAPpnuy-hlRDH1FSYy4O8N37kYRBkFyQ3wmKPRe8=.2d2a0837-eaa3-4bc9-88db-febe686a6e90@github.com>
Message-ID: <NO0ZBBV0DNmxT02QpIBcuuWI_pxmWUFfZIgEF1cRQ2Q=.ecd93400-802b-4d94-a39a-0d6f1324eccf@github.com>

On Wed, 8 Jan 2025 17:41:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 713:
>> 
>>> 711:   __ vxor(vTmp1, vTmp1, vTmp1);
>>> 712:   __ vxor(vZero, vZero, vZero);
>>> 713:   __ mtctr(blocks);
>> 
>> Can `blocks` be 0?
>> `blocks` is an int. The higher half of the register may possibly contain garbage and should be cleared. (Can be combined with 0 check if needed.)
>
> (https://github.com/openjdk/jdk/blob/a641932427cbe8453130593355372837d70a098f/src/java.base/share/classes/com/sun/crypto/provider/GHASH.java#L281) In the java code, the 0 check is handled.

The C2 compiler replaces this Java code by the intrinsic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1907849753

From stooke at openjdk.org  Wed Jan  8 21:01:37 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 8 Jan 2025 21:01:37 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v4]
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <sexTLjbrme-gCVabfKszi9BeME0Chqz4Cg7dOH5GNg8=.9ee2ac81-9246-44e7-bb7b-ac9894be03fc@github.com>

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  test SystemMap with and without ZGC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22870/files
  - new: https://git.openjdk.org/jdk/pull/22870/files/f47f9425..f62bbd7c

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

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

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

From pchilanomate at openjdk.org  Wed Jan  8 21:53:39 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 8 Jan 2025 21:53:39 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <txGcUNxJa5bkZiI8TOKjaTPY02FVBbXXd27l9X7IDeg=.5958522a-4bed-4faa-b452-0e6ab63093aa@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
 <txGcUNxJa5bkZiI8TOKjaTPY02FVBbXXd27l9X7IDeg=.5958522a-4bed-4faa-b452-0e6ab63093aa@github.com>
Message-ID: <pNm0Hb8o37byfoPkSUet9Qxaz53BO7GNBEpD6W-OEDg=.15866a6a-b99e-48d7-ab01-5005399bf79e@github.com>

On Mon, 6 Jan 2025 21:20:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
>> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
>> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
>> 
>> Thanks,
>> Patricio
>
> Looks good to me. Thanks for the detailed analysis.

Thanks for the reviews @dholmes-ora, @alexmenkov and @sspitsyn!

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

PR Comment: https://git.openjdk.org/jdk/pull/22931#issuecomment-2578734644

From pchilanomate at openjdk.org  Wed Jan  8 21:53:40 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 8 Jan 2025 21:53:40 GMT
Subject: Integrated: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <2TkKI1RXg3EHYgTYkbqhzKfSc2l_7MLkhRcfq5i7AJQ=.81986a22-37da-41e6-bafb-d8870b74e50d@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: ea495377
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8310340: assert(_thread->is_interp_only_mode() || stub_caller) failed: expected a stub-caller

Reviewed-by: dholmes, amenkov, sspitsyn

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

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

From dholmes at openjdk.org  Wed Jan  8 22:16:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 22:16:49 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <R8X799JZkfptATR50CoMLU6ix-1dycL5nO5LLalgvNU=.9f97bd92-4495-4091-aae3-d6ae431e4154@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <DlovGx6vyRnAL0x15uT5VOJezyHjp-xiwtXlR9kEo-c=.024e9228-d734-4674-82f9-99104a868ea0@github.com>
 <R8X799JZkfptATR50CoMLU6ix-1dycL5nO5LLalgvNU=.9f97bd92-4495-4091-aae3-d6ae431e4154@github.com>
Message-ID: <66NC-smYThiCbhz0NF3Q-2MkeyQze5NB0mBqG3_holM=.c1afabd3-ca94-446c-9363-777e5512281f@github.com>

On Wed, 8 Jan 2025 06:52:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> BTW: purpose of this PR is to seamlessly remove ASM from java.base and it is slightly turning into a massive synchronous refactoring of several hundreds of hotspot tests.

Moving the ASM library requires modifying every single test that uses it.

If you also change the package structure then you also need to modify the import statements in those tests, so that is more work. Personally I think continuing to use `jdk.internal` is just wrong (in principle) and I'm surprised it is being allowed. But I'm prepared to address that change as a follow up.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2578774743

From asmehra at openjdk.org  Wed Jan  8 22:39:45 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 8 Jan 2025 22:39:45 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v4]
In-Reply-To: <DRyTYIrn0aCMtV4pyimQPfuG_lu5N2ZytSF1Sn5rKJQ=.fb4814b2-ea90-4cb7-993b-bac586a2e172@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <DRyTYIrn0aCMtV4pyimQPfuG_lu5N2ZytSF1Sn5rKJQ=.fb4814b2-ea90-4cb7-993b-bac586a2e172@github.com>
Message-ID: <-FBbsP3jZ90kBiyhCNJkI4FAO2P7w8Z7wZH0mXBDUuI=.a6df905c-2cca-4d8c-a72c-0a032cc3a970@github.com>

On Wed, 8 Jan 2025 02:43:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
>> 
>> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
>> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
>> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
>> 
>> Note to reviewers:
>> 
>> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @ashu-mehra comments

Marked as reviewed by asmehra (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22291#pullrequestreview-2538415364

From cjplummer at openjdk.org  Wed Jan  8 22:58:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Jan 2025 22:58:27 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v9]
In-Reply-To: <3jlL15dxNOGhbPlWBQktux0XbjAd03fhFgW1BZJhp2A=.d48ef40c-776f-414d-a9e7-0cc3403448b8@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <3jlL15dxNOGhbPlWBQktux0XbjAd03fhFgW1BZJhp2A=.d48ef40c-776f-414d-a9e7-0cc3403448b8@github.com>
Message-ID: <wQtmLDXRWfrulCrhMjzrUNbcKdZH6F2BACiYkBjgyz4=.fcf052ea-4bf0-4e5e-a9cc-7857ba1efcd6@github.com>

On Tue, 7 Jan 2025 19:53:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
>> 
>> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
>> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
>> 
>> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
>> 
>> Testing:
>>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update ciopyright year

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2538433490

From cjplummer at openjdk.org  Wed Jan  8 22:58:28 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Jan 2025 22:58:28 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v6]
In-Reply-To: <MllP26-zZy8BltkxGEEPlWwIifKpZWWrVDrG-oXb5Z0=.4656ba1b-73ec-49eb-af16-bfd81699e03c@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <MllP26-zZy8BltkxGEEPlWwIifKpZWWrVDrG-oXb5Z0=.4656ba1b-73ec-49eb-af16-bfd81699e03c@github.com>
Message-ID: <Rj3oJ0bKxTmXW-heTcjLBbMUVL_9jOHkQ67Gk-sv_Zs=.3d7ba74a-e75e-4b81-acc5-1730de0de297@github.com>

On Tue, 7 Jan 2025 19:47:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2538432259

From dholmes at openjdk.org  Thu Jan  9 00:50:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 00:50:39 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
 <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
 <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>
 <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>
Message-ID: <4EpMWy1cYrxFRM28fNjJwB4_UXwfLR9Y5hFhjXWeVBk=.4da7362c-2384-44ca-b8a4-1e001aaf35f6@github.com>

On Wed, 8 Jan 2025 13:23:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I disagree. It seems to me that breaking the abstraction like that is just asking for trouble.
>
> Yes, I think it's fine to say !WINDOWS instead of listing all the posix ports.  We've been avoiding dispatch files and once it reaches a threshold of too many #ifdef !WINDOWS #include posix.hpp one, then we could add another macro like the OS_CPU one.
> 
> Also the copyright script added 2025 for these because they started with 2024 so it's sort of a bug in the script but not really solvable because it doesn't know that you didn't check this in in 2024.

> It seems to me that breaking the abstraction like that is just asking for trouble.

Sorry but what "abstraction" are you referring to?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908044703

From dholmes at openjdk.org  Thu Jan  9 01:10:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 01:10:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v13]
In-Reply-To: <-HnLiN9gQYv9-y-_30kif20f-OE7SuGpRmIHQ_ddIrU=.7ce6c92d-aa43-401f-a8ff-74f92d7eefef@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-HnLiN9gQYv9-y-_30kif20f-OE7SuGpRmIHQ_ddIrU=.7ce6c92d-aa43-401f-a8ff-74f92d7eefef@github.com>
Message-ID: <N9Uiyr_H2bMVS0OXGCy6jcJcMp70qE0Gd1DcMo6Cs0g=.17420840-6871-4658-982b-3b319620be20@github.com>

On Wed, 8 Jan 2025 16:38:50 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Threads::is_single_threaded()

Thanks for the update but the `is_single_threaded()` check can be done more efficiently.

src/hotspot/share/runtime/threads.hpp line 159:

> 157:     }
> 158:     return count <= 1;
> 159:   }

Suggestion:

  // VM initialization is single-threaded until the first NJT (WatcherThread) is created
  // by the main thread, but that thread disappears during VM exit so we can't just
  // check for it. To reduce the overhead we check for > 1 JavaThreads first.
  static bool is_single_threaded() {
    if (number_of_threads() > 1) {
        return false;
    }
    NonJavaThread::Iterator njti;
    return njti->current() == nullptr;
  }

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2538579113
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1908054366

From dholmes at openjdk.org  Thu Jan  9 01:21:15 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 01:21:15 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
 <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>
Message-ID: <YBl0QWTX01LYMxsH7mOrFVfRJDUOl0PJErdyO5VA9Ow=.9dd25af9-c4df-4a38-bf79-d1bf88155edc@github.com>

On Tue, 7 Jan 2025 09:13:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/interpreter/abstractInterpreter.cpp line 137:
>> 
>>> 135:       case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits;
>>> 136:       case vmIntrinsics::_longBitsToDouble:  return java_lang_Double_longBitsToDouble;
>>> 137:       case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits;
>> 
>> Why are these intrinsics for the Java methods disappearing?
>
> These are interpreter "intrinsics" that are only implemented on x86_32 to handle x87 FPU pecularities. Look around for `TemplateInterpreterGenerator::generate_Float_intBitsToFloat_entry`, for example.

Hmmm ... okay ... I see something "special" is done only on x86_32, but what is done seems to have nothing to do with x87 code.

Just to be clear these Java methods still get intrinsified, it is just handled in a different way - right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1908061750

From sspitsyn at openjdk.org  Thu Jan  9 02:15:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Jan 2025 02:15:41 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <VPN9tX4vajCaJZ5PaWycbxzVqX4u9Sr-Ou7tsrMG7mA=.156b8712-03a8-4a57-8a04-8930bbe6bcc9@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
 <QWoG2cS_0x3MjB_ybdYb2k3mDvjyVwjAANR_83DCnqM=.cedd4f1a-f3d7-4701-ab72-cd0b9c7757e2@github.com>
 <VPN9tX4vajCaJZ5PaWycbxzVqX4u9Sr-Ou7tsrMG7mA=.156b8712-03a8-4a57-8a04-8930bbe6bcc9@github.com>
Message-ID: <6_6xBPaAyMGanR9vGmuqW4d6Sengm_P2TTmQTb_wMbc=.0d250d88-bad6-4641-b14f-15ad7db4bdd9@github.com>

On Wed, 8 Jan 2025 17:33:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> I see. Yes, we still need the handshake in JvmtiEventControllerPrivate::enter_interp_only_mode to safely walk the stack of the target to deoptimize the frames. When leaving interpreter only mode we just decrement _interp_only_mode/_saved_interp_only_mode so I don?t think we need anything else, other than making sure the change is atomic, which I think we guarantee by holding JvmtiThreadState_lock.

Agreed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22931#issuecomment-2579037121

From lliu at openjdk.org  Thu Jan  9 03:09:39 2025
From: lliu at openjdk.org (Liming Liu)
Date: Thu, 9 Jan 2025 03:09:39 GMT
Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for
 Ampere-1A and 1B
In-Reply-To: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
References: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
Message-ID: <ilkErwzaHSujl5dxSLcXqqE79Q0d_neC1SdHdu2xBJ0=.7c1b2a73-7ef2-4131-a274-a42a27dfa5aa@github.com>

On Fri, 15 Nov 2024 07:01:23 GMT, Liming Liu <lliu at openjdk.org> wrote:

> This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128.
> 
> Ran JTReg tier1 on Ampere-1A and no new issues were found.

> Does this change not help CPU_MODEL_AMPERE_1?

No.

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

PR Comment: https://git.openjdk.org/jdk/pull/22134#issuecomment-2579089570

From duke at openjdk.org  Thu Jan  9 03:09:39 2025
From: duke at openjdk.org (duke)
Date: Thu, 9 Jan 2025 03:09:39 GMT
Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for
 Ampere-1A and 1B
In-Reply-To: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
References: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
Message-ID: <kDiH7DA_D7bJw9P57INjYeWjvcsGudPI7bSYwIDqjo0=.e9978b00-f033-47d5-924e-6b7c4709f76b@github.com>

On Fri, 15 Nov 2024 07:01:23 GMT, Liming Liu <lliu at openjdk.org> wrote:

> This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128.
> 
> Ran JTReg tier1 on Ampere-1A and no new issues were found.

@limingliu-ampere 
Your change (at version 1a666acfe46192530a0d2a32ca6d374ee2fa3631) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22134#issuecomment-2579091091

From dholmes at openjdk.org  Thu Jan  9 03:09:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 03:09:44 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v4]
In-Reply-To: <sexTLjbrme-gCVabfKszi9BeME0Chqz4Cg7dOH5GNg8=.9ee2ac81-9246-44e7-bb7b-ac9894be03fc@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <sexTLjbrme-gCVabfKszi9BeME0Chqz4Cg7dOH5GNg8=.9ee2ac81-9246-44e7-bb7b-ac9894be03fc@github.com>
Message-ID: <3jOPTXsCDtxgDPDlSW67E2-Sr9bOI-vIrIqoN9O8fns=.19075be5-37c0-4655-8fe4-4c633185d2bf@github.com>

On Wed, 8 Jan 2025 21:01:37 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test SystemMap with and without ZGC

Marked as reviewed by dholmes (Reviewer).

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 39:

> 37:  *          java.management
> 38:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
> 39:  * @run testng/othervm -XX:+UsePerfData -XX:-UseZGC SystemMapTest

Technically you don't need to disable ZGC as the requires clause means it is already not the selected GC

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

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2538658134
PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1908108908

From fyang at openjdk.org  Thu Jan  9 03:34:18 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 9 Jan 2025 03:34:18 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v7]
In-Reply-To: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
Message-ID: <j8o-tyzcHEAs6L9CRMGxdhteIOAqkQTyKr3DlDRtLe8=.f81be863-a55c-4d42-a138-ed64d7b5405e@github.com>

> Hi, please consider this cleanup change.
> 
> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
> 
> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
> 
> 
> 
>  <Design of the RISC-V Instruction Set Architecture>:
> 
>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>  -2048 would add 2048 to a register, which ADDI is incapable of.
> 
> 
> Testing on Premier-P550 SBC running Ubuntu-24.04:
> - [x] : tier1-3 and gtest:all (release)
> - [x] : hotspot:tier1 (fastdebug)

Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8346478
 - Review comments
 - Revert unnecessary change
 - Improve naming for rotate routines
 - Revert unnecessary changes
 - Merge branch 'master' into JDK-8346478
 - 8346478: RISC-V: Refactor add/sub assembler routines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22804/files
  - new: https://git.openjdk.org/jdk/pull/22804/files/ba5f37cc..54177bbf

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

  Stats: 21268 lines in 372 files changed: 8739 ins; 10907 del; 1622 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

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

From fyang at openjdk.org  Thu Jan  9 03:34:18 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 9 Jan 2025 03:34:18 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v7]
In-Reply-To: <9j40rWZ33LquI5ljXhNwhiVJcNnSaZM7AhdkoreGtzs=.38d337b9-18a5-4ec4-a331-450976eec519@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <O4t3DYyEeMOgQ2HAR2M-UPI0IIbgMKLINEdExVgyFUc=.057053f2-0107-4ddd-a433-c3e7dad923af@github.com>
 <9j40rWZ33LquI5ljXhNwhiVJcNnSaZM7AhdkoreGtzs=.38d337b9-18a5-4ec4-a331-450976eec519@github.com>
Message-ID: <KeIlgwTH9HeKpR1JjXxMC87yUj7ES3EAd3rHxTdchWo=.c57e310b-fc3a-40dc-8c35-b5f7d3943818@github.com>

On Mon, 23 Dec 2024 13:49:19 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8346478
>>  - Review comments
>>  - Revert unnecessary change
>>  - Improve naming for rotate routines
>>  - Revert unnecessary changes
>>  - Merge branch 'master' into JDK-8346478
>>  - 8346478: RISC-V: Refactor add/sub assembler routines
>
> Marked as reviewed by fjiang (Committer).

@feilongjiang @zifeihan : Thanks for the review!
@robehn : Are you OK with the latest version? Let me know if you have any further comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/22804#issuecomment-2579111135

From sspitsyn at openjdk.org  Thu Jan  9 05:07:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Jan 2025 05:07:47 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
Message-ID: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>

This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.

Testing:
- Ran mach5 tiers 1-6
- There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

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

Commit messages:
 - 8346727: JvmtiVTMSTransitionDisabler deadlock

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

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

From kbarrett at openjdk.org  Thu Jan  9 06:34:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 06:34:48 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <4EpMWy1cYrxFRM28fNjJwB4_UXwfLR9Y5hFhjXWeVBk=.4da7362c-2384-44ca-b8a4-1e001aaf35f6@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
 <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
 <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>
 <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>
 <4EpMWy1cYrxFRM28fNjJwB4_UXwfLR9Y5hFhjXWeVBk=.4da7362c-2384-44ca-b8a4-1e001aaf35f6@github.com>
Message-ID: <eTmwZE6K_UeBUhY6HcwSzYqFrVBzWTZzITxaYDdD2Hw=.30affb9e-c7a6-4557-a9e6-a81597288843@github.com>

On Thu, 9 Jan 2025 00:46:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes, I think it's fine to say !WINDOWS instead of listing all the posix ports.  We've been avoiding dispatch files and once it reaches a threshold of too many #ifdef !WINDOWS #include posix.hpp one, then we could add another macro like the OS_CPU one.
>> 
>> Also the copyright script added 2025 for these because they started with 2024 so it's sort of a bug in the script but not really solvable because it doesn't know that you didn't check this in in 2024.
>
>> It seems to me that breaking the abstraction like that is just asking for trouble.
> 
> Sorry but what "abstraction" are you referring to?

@dholmes-ora - OS_HEADER and CPU_HEADER instead of explicit knowledge of what platforms exist and
which ones share some code in a "_posix" file and which ones have some unshared code.  IMO the includer
shouldn't need to know that kind of implementation detail.

But oh well, all y'all seem to really hate the simple forwarding files and would prefer to skip that in favor of
hard-coding the file organization.  In the interest of making progress, I'll do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908229538

From kbarrett at openjdk.org  Thu Jan  9 06:34:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 06:34:49 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
 <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
 <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>
 <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>
Message-ID: <MBXafo0I882JS7AW3TRT-vZcUhr1Zwg_aiWeErvtma0=.8e867441-b738-4d9d-975c-a07e6934b316@github.com>

On Wed, 8 Jan 2025 13:23:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I disagree. It seems to me that breaking the abstraction like that is just asking for trouble.
>
> Yes, I think it's fine to say !WINDOWS instead of listing all the posix ports.  We've been avoiding dispatch files and once it reaches a threshold of too many #ifdef !WINDOWS #include posix.hpp one, then we could add another macro like the OS_CPU one.
> 
> Also the copyright script added 2025 for these because they started with 2024 so it's sort of a bug in the script but not really solvable because it doesn't know that you didn't check this in in 2024.

@coleenp The copyrights on the new files being 2024-2025 is intentional. They were first published (in this PR)
in 2024, so I think are supposed to have that starting year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908231286

From rehn at openjdk.org  Thu Jan  9 06:49:37 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 9 Jan 2025 06:49:37 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v7]
In-Reply-To: <j8o-tyzcHEAs6L9CRMGxdhteIOAqkQTyKr3DlDRtLe8=.f81be863-a55c-4d42-a138-ed64d7b5405e@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <j8o-tyzcHEAs6L9CRMGxdhteIOAqkQTyKr3DlDRtLe8=.f81be863-a55c-4d42-a138-ed64d7b5405e@github.com>
Message-ID: <4m9iZQxoEy2VJjI1qh2MdYwB5BNuCNQ3iUaW9ex_LTM=.94ad0e7c-aad6-474b-9331-04f0a1a243bc@github.com>

On Thu, 9 Jan 2025 03:34:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
>> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
>> 
>> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
>> 
>> 
>> 
>>  <Design of the RISC-V Instruction Set Architecture>:
>> 
>>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>>  -2048 would add 2048 to a register, which ADDI is incapable of.
>> 
>> 
>> Testing on Premier-P550 SBC running Ubuntu-24.04:
>> - [x] : tier1-3 and gtest:all (release)
>> - [x] : hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8346478
>  - Review comments
>  - Revert unnecessary change
>  - Improve naming for rotate routines
>  - Revert unnecessary changes
>  - Merge branch 'master' into JDK-8346478
>  - 8346478: RISC-V: Refactor add/sub assembler routines

Hey, sorry, I didn't understand/forgot over the holidays that you were waiting for me.

Yes, thanks!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22804#pullrequestreview-2538864751

From kbarrett at openjdk.org  Thu Jan  9 07:08:37 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 07:08:37 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v4]
In-Reply-To: <CCQxWvwxnvV8bu6FZeM8YrRGlOEmf_MTf5wyBDnm5xs=.b7735ca9-37ab-4f52-9daa-dcad3595efbe@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <mgaIxADi54AaczgDWzqFm3WUzMu2tqApcxrZ2oh_4Mc=.1e792b0f-89a8-460e-a96b-6cb0f6f74a3a@github.com>
 <fxDnyYA1AHns3gXjtAyAMzujRJdrYzBcYbulbB5tQGM=.b5c0a410-a801-464e-a2f5-191df85c9461@github.com>
 <CCQxWvwxnvV8bu6FZeM8YrRGlOEmf_MTf5wyBDnm5xs=.b7735ca9-37ab-4f52-9daa-dcad3595efbe@github.com>
Message-ID: <qcErP_8iEkrR-LxIfSPFSUGyLmRsdJdjT9RJC84p4XU=.4dc8fcef-721f-4ef8-8658-7788b274d7a3@github.com>

On Wed, 8 Jan 2025 04:24:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I filed an enhancement to remove the use of ::strdup. https://bugs.openjdk.org/browse/JDK-8347157

Per discussion in that bug, it's been closed as not an issue, and I'm changing the code here to add and use the
permit wrapper for strdup.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2579311852

From alanb at openjdk.org  Thu Jan  9 08:08:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Jan 2025 08:08:46 GMT
Subject: RFR: 8346986: Remove ASM from java.base
In-Reply-To: <66NC-smYThiCbhz0NF3Q-2MkeyQze5NB0mBqG3_holM=.c1afabd3-ca94-446c-9363-777e5512281f@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <DlovGx6vyRnAL0x15uT5VOJezyHjp-xiwtXlR9kEo-c=.024e9228-d734-4674-82f9-99104a868ea0@github.com>
 <R8X799JZkfptATR50CoMLU6ix-1dycL5nO5LLalgvNU=.9f97bd92-4495-4091-aae3-d6ae431e4154@github.com>
 <66NC-smYThiCbhz0NF3Q-2MkeyQze5NB0mBqG3_holM=.c1afabd3-ca94-446c-9363-777e5512281f@github.com>
Message-ID: <PyRS7c_xj04pewtwSbIud8gl3vzsMeqtpwhaxbyRns8=.8735f808-915b-47ed-bc92-d55c00a15763@github.com>

On Wed, 8 Jan 2025 22:14:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Moving the ASM library requires modifying every single test that uses it.

Right, as without it there will be warnings due to jtreg launching tests to export packages that aren't in java.base. There may also be a few tests that use launch child VMs with explicit options to export these packages so they will need to be hunted down. It may be that all the tests are passing, in which case this could be done in a follow-up PR, but I think better to do everything at the same time.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2579392677

From asotona at openjdk.org  Thu Jan  9 08:20:36 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Jan 2025 08:20:36 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v2]
In-Reply-To: <huTabpsxLKQvkC_EnuYVrPZ8Ch1Tj53X0adEBIwCD6E=.58581a3d-b4d0-44e3-81c0-5b359c334cd5@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <huTabpsxLKQvkC_EnuYVrPZ8Ch1Tj53X0adEBIwCD6E=.58581a3d-b4d0-44e3-81c0-5b359c334cd5@github.com>
Message-ID: <ATl0yn5Tu0sA8MJREPDCF31MlfWRPyC5hVcOVk1R5dE=.a3b84d04-2856-43c5-984b-77fbc4d6f3bb@github.com>

On Wed, 8 Jan 2025 07:21:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asm move under test/hotspot/jtreg/testlibrary

The consensus seems to be more toward the all-in-one solution (move + repackage). 
I'll update the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2579412022

From sroy at openjdk.org  Thu Jan  9 08:25:13 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 9 Jan 2025 08:25:13 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v5]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <5NoAAte3RreyFNDmVF8q0mqLsgJQ2IT-R1rG03jipHc=.e735352c-698f-47d6-ba8c-fc0f7a63e6d8@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 -  assertion for blocks
 -  assertion for blocks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/cd121d07..89e7be9e

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

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

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

From asotona at openjdk.org  Thu Jan  9 08:40:37 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Jan 2025 08:40:37 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed jdk.internal package prefix from asm

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22946/files
  - new: https://git.openjdk.org/jdk/pull/22946/files/56fc9e41..13267e26

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

  Stats: 3748 lines in 240 files changed: 1342 ins; 1342 del; 1064 mod
  Patch: https://git.openjdk.org/jdk/pull/22946.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946

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

From sroy at openjdk.org  Thu Jan  9 09:07:21 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 9 Jan 2025 09:07:21 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  restore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/89e7be9e..6fc23197

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

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

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

From shade at openjdk.org  Thu Jan  9 09:38:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Jan 2025 09:38:38 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <YBl0QWTX01LYMxsH7mOrFVfRJDUOl0PJErdyO5VA9Ow=.9dd25af9-c4df-4a38-bf79-d1bf88155edc@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
 <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>
 <YBl0QWTX01LYMxsH7mOrFVfRJDUOl0PJErdyO5VA9Ow=.9dd25af9-c4df-4a38-bf79-d1bf88155edc@github.com>
Message-ID: <SQUEdE1fFiWXLWxBQIDvCikr0Ynw5UP_evoTeNkQdiI=.15525857-a5f9-48fc-b02b-a7e9562a5569@github.com>

On Thu, 9 Jan 2025 01:17:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> These are interpreter "intrinsics" that are only implemented on x86_32 to handle x87 FPU pecularities. Look around for `TemplateInterpreterGenerator::generate_Float_intBitsToFloat_entry`, for example.
>
> Hmmm ... okay ... I see something "special" is done only on x86_32, but what is done seems to have nothing to do with x87 code.
> 
> Just to be clear these Java methods still get intrinsified, it is just handled in a different way - right?

It *is* about x87 handling of NaNs, a common problem for x86_32 code in Hotspot, you can read about this mess in [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373), if you are interested. If we allow to use native implementations of these conversion methods, we get into trouble with NaNs. What these interpreter intrinsics do on x86_32: going for SSE if available, thus avoiding x87. Since this is a correctness problem, these intrinsics go all the way down to interpreter as well. There is still a gaping hole when SSE is not available, but then we have no choice than to use x87 and have all the relevant issues. 

But all of this is only a headache for x86_32, all other platforms do not have these interpreter intrinsics implemented. With x86_32 going away, we can finally yank these and relevant scaffolding out.

The C1/C2 intrinsics are still up and enabled for supported platforms: those are for performance :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1908436596

From kbarrett at openjdk.org  Thu Jan  9 10:02:15 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 10:02:15 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v6]
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <4FG-nUwG3rnddQFgdiZ-vtnGqtm_Ij0LbmQ6nX96fdw=.8b63229c-0686-43bd-b783-9f6402ee0b0d@github.com>

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - add permit wrapper for strdup and use in aix
 - remove os-specific posix forwarding headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22890/files
  - new: https://git.openjdk.org/jdk/pull/22890/files/b774f14c..000aca91

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

  Stats: 100 lines in 6 files changed: 6 ins; 92 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22890.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22890/head:pull/22890

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

From stefank at openjdk.org  Thu Jan  9 10:13:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 9 Jan 2025 10:13:44 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v6]
In-Reply-To: <4FG-nUwG3rnddQFgdiZ-vtnGqtm_Ij0LbmQ6nX96fdw=.8b63229c-0686-43bd-b783-9f6402ee0b0d@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <4FG-nUwG3rnddQFgdiZ-vtnGqtm_Ij0LbmQ6nX96fdw=.8b63229c-0686-43bd-b783-9f6402ee0b0d@github.com>
Message-ID: <mfiTTuLurW-ziCQ0ewl3p3Q_pqz2V6WS76Ko2zcn33E=.28abb2fa-8e77-4df2-ba0b-72743ed8fa51@github.com>

On Thu, 9 Jan 2025 10:02:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add permit wrapper for strdup and use in aix
>  - remove os-specific posix forwarding headers

src/hotspot/os/posix/forbiddenFunctions_posix.hpp line 29:

> 27: 
> 28: #include "utilities/compilerWarnings.hpp"
> 29: #include <stddef.h> // for size_t

Suggestion:

#include "utilities/compilerWarnings.hpp"

#include <stddef.h> // for size_t

src/hotspot/os/windows/forbiddenFunctions_windows.hpp line 29:

> 27: 
> 28: #include "utilities/compilerWarnings.hpp"
> 29: #include <stddef.h> // for size_t

Suggestion:

#include "utilities/compilerWarnings.hpp"

#include <stddef.h> // for size_t

src/hotspot/share/utilities/forbiddenFunctions.hpp line 30:

> 28: #include "utilities/compilerWarnings.hpp"
> 29: #include "utilities/macros.hpp"
> 30: #include <stdarg.h> // for va_list

Suggestion:

#include "utilities/macros.hpp"

#include <stdarg.h> // for va_list

src/hotspot/share/utilities/permitForbiddenFunctions.hpp line 70:

> 68: 
> 69: #endif // SHARE_UTILITIES_PERMITFORBIDDENFUNCTIONS_HPP
> 70: 

Suggestion:

#endif // SHARE_UTILITIES_PERMITFORBIDDENFUNCTIONS_HPP

test/hotspot/gtest/unittest.hpp line 27:

> 25: #define UNITTEST_HPP
> 26: 
> 27: #include "utilities/globalDefinitions.hpp"

Suggestion:

#include "utilities/globalDefinitions.hpp"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908485156
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908485732
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908486633
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908487438
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908488569

From kbarrett at openjdk.org  Thu Jan  9 10:28:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 10:28:28 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v7]
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <WLAjyUn1yLQkDX4PtJyB7VoXGlIdeMg2vzq3fTy3Wpk=.1cd1b4b9-6ff9-4475-bdb6-5698a9beee2a@github.com>

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  stefank whitespace suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22890/files
  - new: https://git.openjdk.org/jdk/pull/22890/files/000aca91..97a56ae6

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

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

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

From kbarrett at openjdk.org  Thu Jan  9 10:31:57 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 10:31:57 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v7]
In-Reply-To: <WLAjyUn1yLQkDX4PtJyB7VoXGlIdeMg2vzq3fTy3Wpk=.1cd1b4b9-6ff9-4475-bdb6-5698a9beee2a@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <WLAjyUn1yLQkDX4PtJyB7VoXGlIdeMg2vzq3fTy3Wpk=.1cd1b4b9-6ff9-4475-bdb6-5698a9beee2a@github.com>
Message-ID: <pfeu3Q88bgApblDHukeEsTHwFogqJmE1-xnUAszoDIs=.553ac9c8-c198-4e34-815f-f31a878cab5a@github.com>

On Thu, 9 Jan 2025 10:28:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stefank whitespace suggestions

@stefank Someday that long ago long discussion about include ordering and formatting needs to get cleaned up and
added to the style guide.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2579749535

From galder at openjdk.org  Thu Jan  9 10:43:15 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 9 Jan 2025 10:43:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v7]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <1NAcKoms9A361Do3Vi6f4xT_euhDNTrotPWMskOsi70=.ca927892-1d5b-4a0d-b07a-f4f987f824a7@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request incrementally with two additional commits since the last revision:

 - Fix license header
 - Tests should also run on aarch64 asimd=true envs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/130b4755..fb0f731f

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

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

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

From galder at openjdk.org  Thu Jan  9 11:28:40 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 9 Jan 2025 11:28:40 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v6]
In-Reply-To: <AE1cy_IT7B9BapAUJ9iQs-U1r-gtyYee-UAQaiShDcE=.7f82bd1a-0e14-4bef-bff9-7d43563ff1b8@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <BmcBU2NE8-d1Zaz8mM6oPw5VY--4lPsn8aX9pL7hJ0Y=.e2d62858-a0da-4f69-845a-7cbd8897dd30@github.com>
 <9uGYNmVdvCXvyYSOAfwmvD70nWkimOFIlQJolQWa_Z4=.c6ffbfa0-5eb1-40a4-83a4-b657f57c9836@github.com>
 <JOUCPakioJEQD8AVPnDAw51sFAk6qYADITVo-fEsZxk=.8d6dc3d6-0838-490a-b2e6-8a78cb1f6afb@github.com>
 <AE1cy_IT7B9BapAUJ9iQs-U1r-gtyYee-UAQaiShDcE=.7f82bd1a-0e14-4bef-bff9-7d43563ff1b8@github.com>
Message-ID: <d010-Hh9tQy-m16EcRvoCgbBZJMrfXHm7QUMlW65XXw=.c7c1d3ee-4881-4943-8575-a4133aeceeeb@github.com>

On Fri, 3 Jan 2025 08:48:37 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> That's right. Neoverse V2 is 4 pipes of 128 bits, V1 is 2 pipes of 256 bits.
>> That comment is "interesting". Maybe it should be tunable by the back end. Given that Neoverse V2 can issue 4 SVE operations per clock cycle, it might still be a win.
>> 
>> Galder, how about you disable that line and give it another try?
>
> FYI: I'm working on removing the line [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566).
> 
> The issue is that on some platforms 2-element vectors are somehow really slower, and we need a cost-model to give us a better heuristic, rather than the hard "no". See my draft https://github.com/openjdk/jdk/pull/20964.
> 
> But yes: why don't you remove the line, and see if that makes it work. If so, then don't worry about this case for now, and maybe leave a comment in the test. We can then fix that later.

Yeah, this limit limits reductions like this working on 128 bit registers:


      // Length 2 reductions of INT/LONG do not offer performance benefits
      if (((arith_type->basic_type() == T_INT) || (arith_type->basic_type() == T_LONG)) && (size == 2)) {
        retValue = false;


I've tried today to remove that but then the profitable checks fail to pass. So, I'm not going down that route now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1908608309

From fyang at openjdk.org  Thu Jan  9 11:39:44 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 9 Jan 2025 11:39:44 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v7]
In-Reply-To: <j8o-tyzcHEAs6L9CRMGxdhteIOAqkQTyKr3DlDRtLe8=.f81be863-a55c-4d42-a138-ed64d7b5405e@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <j8o-tyzcHEAs6L9CRMGxdhteIOAqkQTyKr3DlDRtLe8=.f81be863-a55c-4d42-a138-ed64d7b5405e@github.com>
Message-ID: <o86Y_jmKLYvAoHuIqt0ycUqnY6JHolLF_DhtZN7w_Ww=.10ee65c3-9016-424e-b5e6-8741b42832d8@github.com>

On Thu, 9 Jan 2025 03:34:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
>> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
>> 
>> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
>> 
>> 
>> 
>>  <Design of the RISC-V Instruction Set Architecture>:
>> 
>>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>>  -2048 would add 2048 to a register, which ADDI is incapable of.
>> 
>> 
>> Testing on Premier-P550 SBC running Ubuntu-24.04:
>> - [x] tier1-3 and gtest:all (release)
>> - [x] hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8346478
>  - Review comments
>  - Revert unnecessary change
>  - Improve naming for rotate routines
>  - Revert unnecessary changes
>  - Merge branch 'master' into JDK-8346478
>  - 8346478: RISC-V: Refactor add/sub assembler routines

Thanks all for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22804#issuecomment-2579932558

From fyang at openjdk.org  Thu Jan  9 11:39:45 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 9 Jan 2025 11:39:45 GMT
Subject: Integrated: 8346478: RISC-V: Refactor add/sub assembler routines
In-Reply-To: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
Message-ID: <2GOBGCl9iEDRZP5IItgKu4RKb6kUQA1kuMdIc9K5pQk=.41998e32-156e-4f0c-8d1e-acd87991eecf@github.com>

On Wed, 18 Dec 2024 03:29:09 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please consider this cleanup change.
> 
> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
> 
> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
> 
> 
> 
>  <Design of the RISC-V Instruction Set Architecture>:
> 
>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>  -2048 would add 2048 to a register, which ADDI is incapable of.
> 
> 
> Testing on Premier-P550 SBC running Ubuntu-24.04:
> - [x] tier1-3 and gtest:all (release)
> - [x] hotspot:tier1 (fastdebug)

This pull request has now been integrated.

Changeset: 8c87ea2b
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c87ea2bdf6e1aea5fdca4624d7b7fe590d33a37
Stats:     419 lines in 21 files changed: 14 ins; 6 del; 399 mod

8346478: RISC-V: Refactor add/sub assembler routines

Reviewed-by: fjiang, rehn, gcao

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

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

From fyang at openjdk.org  Thu Jan  9 11:42:41 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 9 Jan 2025 11:42:41 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v6]
In-Reply-To: <vQqj01yERuZXYKDqyu9OOJnRaKQUJ_jQfePafsRTgvo=.877c8fb5-249e-4804-8d17-ad0ff3151d7e@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <vQqj01yERuZXYKDqyu9OOJnRaKQUJ_jQfePafsRTgvo=.877c8fb5-249e-4804-8d17-ad0ff3151d7e@github.com>
Message-ID: <zRj1T_lGvUVtr0G9IiNmb1Jf9vL_y4sQRkijV7xDHTo=.a6cc6021-7c28-4c75-846d-6f7fd5d36845@github.com>

On Wed, 11 Dec 2024 07:23:18 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comment

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 954:

> 952:   void revb(Register Rd, Register Rs, Register tmp1 = t0, Register tmp2 = t1);  // reverse bytes in doubleword
> 953: 
> 954:   void ror_reg(Register dst, Register src, Register shift, Register tmp = t0);

Hi, Could you please merge master? Then we can rename this routine to:
`void ror(Register dst, Register src, Register shift, Register tmp = t0);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1908629206

From galder at openjdk.org  Thu Jan  9 11:47:58 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 9 Jan 2025 11:47:58 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v8]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <Lpza2nQ-u3rnWYyVzcSBIBM9PcFKNVsXdt0ULQl12ZY=.bab7e852-8fde-4e32-9047-78ce2ea19456@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:

  Test can only run with 256 bit registers or bigger
  
  * Remove platform dependant check
  and use platform independent configuration instead.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/fb0f731f..c0491987

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

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

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

From sspitsyn at openjdk.org  Thu Jan  9 12:05:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Jan 2025 12:05:45 GMT
Subject: Integrated: 8346460: NotifyFramePop should return
 JVMTI_ERROR_DUPLICATE
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <9D3Y5T128B7aDfkUNxtoVIq_ytSx4Rwt3_O0UdD7L_0=.559dc3d2-b6dc-4af7-a9ca-97f408a68ec9@github.com>

On Tue, 17 Dec 2024 21:01:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 2801bc6b
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2801bc6bf3d5e7eff23be1a7501f7e64dda85f67
Stats:     30 lines in 3 files changed: 19 ins; 6 del; 5 mod

8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE

Reviewed-by: cjplummer, amenkov

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

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

From galder at openjdk.org  Thu Jan  9 12:06:41 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 9 Jan 2025 12:06:41 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
Message-ID: <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>

On Wed, 18 Dec 2024 06:22:56 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further.
>> 
>> @jaskarth FYI I've adjusted the expectations in `TestMinMaxIdentities` after this change (thx for adding the test!). Check if there's any comments/changes you'd like.
>
> @galderz Nice, thanks for the updates. I gave the patch a quick scan and I think it looks really good. Just ping me again when you are done with your aarch64 investigations, and you think I should review again :)

@eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`)

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2579989885

From epeter at openjdk.org  Thu Jan  9 12:21:44 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 9 Jan 2025 12:21:44 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
Message-ID: <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>

On Thu, 9 Jan 2025 12:03:55 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> @galderz Nice, thanks for the updates. I gave the patch a quick scan and I think it looks really good. Just ping me again when you are done with your aarch64 investigations, and you think I should review again :)
>
> @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`)

@galderz So you want me to review again?

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2580018680

From cnorrbin at openjdk.org  Thu Jan  9 12:57:40 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 12:57:40 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v8]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <vKth9zOaYnm-I91yg-fmTzL_z91WrXvE1rdJoZaJFaI=.d9e83578-e634-48a5-aa85-daab20b985b0@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with three additional commits since the last revision:

 - updated copyright headers
 - stable tree nodes
 - more feedback from johan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/505c7f8d..6a06e15d

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

  Stats: 216 lines in 3 files changed: 135 ins; 61 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

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

From rehn at openjdk.org  Thu Jan  9 13:02:26 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 9 Jan 2025 13:02:26 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads
Message-ID: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>

Hi, please consider.

The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.

If we need them before hwprobe we can add a flag for manually enabling them.

Sanity tested.

Thanks!

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

Commit messages:
 - Check for extension

Changes: https://git.openjdk.org/jdk/pull/23003/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23003&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347343
  Stats: 34 lines in 3 files changed: 7 ins; 18 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23003.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23003/head:pull/23003

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

From stefank at openjdk.org  Thu Jan  9 13:03:49 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 9 Jan 2025 13:03:49 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v7]
In-Reply-To: <pfeu3Q88bgApblDHukeEsTHwFogqJmE1-xnUAszoDIs=.553ac9c8-c198-4e34-815f-f31a878cab5a@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <WLAjyUn1yLQkDX4PtJyB7VoXGlIdeMg2vzq3fTy3Wpk=.1cd1b4b9-6ff9-4475-bdb6-5698a9beee2a@github.com>
 <pfeu3Q88bgApblDHukeEsTHwFogqJmE1-xnUAszoDIs=.553ac9c8-c198-4e34-815f-f31a878cab5a@github.com>
Message-ID: <ozTfPIy3CJAMVyo_5anXRhbJVqBPUH8j0q5UkJeIjlw=.c923611c-8d10-4799-b684-c0406bc87c1a@github.com>

On Thu, 9 Jan 2025 10:29:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> @stefank Someday that long ago long discussion about include ordering and formatting needs to get cleaned up and added to the style guide.

Yes. The guide that system includes should come last and be separated from the rest of the HotSpot includes was never written down here:
https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2580098775

From coleenp at openjdk.org  Thu Jan  9 13:03:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Jan 2025 13:03:51 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v7]
In-Reply-To: <WLAjyUn1yLQkDX4PtJyB7VoXGlIdeMg2vzq3fTy3Wpk=.1cd1b4b9-6ff9-4475-bdb6-5698a9beee2a@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <WLAjyUn1yLQkDX4PtJyB7VoXGlIdeMg2vzq3fTy3Wpk=.1cd1b4b9-6ff9-4475-bdb6-5698a9beee2a@github.com>
Message-ID: <X3JbN615LyqQ6XP--iUH-GPjHHq5ml1vmhF6_mhfRN4=.9a0d6182-7d7d-42d1-a3cb-4917b96cec28@github.com>

On Thu, 9 Jan 2025 10:28:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stefank whitespace suggestions

src/hotspot/os/bsd/permitForbiddenFunctions_bsd.hpp line 30:

> 28: #include "permitForbiddenFunctions_posix.hpp"
> 29: 
> 30: #endif // OS_BSD_PERMITFORBIDDENFUNCTIONS_BSD_HPP

I thought you were eliminating these in favor of #ifdef where included?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1908753962

From cnorrbin at openjdk.org  Thu Jan  9 13:08:39 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 13:08:39 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <qj-dBbtwooojct52g48-oc1HX9FbDUS4Ky8Xsvm3s54=.6fb1e652-6284-44d9-a142-09f0aac7dc7f@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <JsAD3IcUMs7Z0e2iUVTY1Bu_B-AgBrfopHHcf3e4MZc=.3ad7dbd8-ffc2-4b4f-bc70-b738109ffd6d@github.com>
 <qj-dBbtwooojct52g48-oc1HX9FbDUS4Ky8Xsvm3s54=.6fb1e652-6284-44d9-a142-09f0aac7dc7f@github.com>
Message-ID: <2aZ3F325V6oldgyjnTu9ToxrL_mJW26LJRWzEKLx3ak=.d61248e2-5f9f-45f0-b494-b2bb00a9f0b4@github.com>

On Tue, 7 Jan 2025 13:07:44 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.inline.hpp line 100:
>> 
>>> 98:     _right->visit_in_order_inner(f);
>>> 99:   }
>>> 100: }
>> 
>> This is basically fine, as stack depth will be at most `2log n`, but is there a reason that you can't use the iterative solution that's present in the Treap? Btw, having this method belonging to RBTree and take a `RBNode*` instead of RBNode allows you to just check if the current root node is null, letting you skip a check.
>> 
>> Here's `visit_in_order` as an iterative function:
>> 
>> 
>>   template<typename F>
>>   void visit_in_order(F f) const {
>>     GrowableArrayCHeap<TreapNode*, mtNMT> to_visit;
>>     TreapNode* head = _root;
>>     while (!to_visit.is_empty() || head != nullptr) {
>>       while (head != nullptr) {
>>         to_visit.push(head);
>>         head = head->left();
>>       }
>>       head = to_visit.pop();
>>       f(head);
>>       head = head->right();
>>     }
>>   }
>
> In fact, you can pre-size the GA such that it starts with a capacity of 2log(n+1)

I thought the recursive versions looked neater, but changed them now to the iterative version with pre-sized GAs

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908759470

From cnorrbin at openjdk.org  Thu Jan  9 13:08:42 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 13:08:42 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <JsAD3IcUMs7Z0e2iUVTY1Bu_B-AgBrfopHHcf3e4MZc=.3ad7dbd8-ffc2-4b4f-bc70-b738109ffd6d@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <JsAD3IcUMs7Z0e2iUVTY1Bu_B-AgBrfopHHcf3e4MZc=.3ad7dbd8-ffc2-4b4f-bc70-b738109ffd6d@github.com>
Message-ID: <CudSwCIQeCtEuV2FmCNpKUhIcGUJ4TYQFhL26mEcuGU=.d374405f-541a-45d2-a3c7-e3894b01bd55@github.com>

On Tue, 7 Jan 2025 13:11:06 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed coloring functions
>
> src/hotspot/share/utilities/rbTree.inline.hpp line 203:
> 
>> 201:       curr = curr->_right;
>> 202:     }
>> 203:   }
> 
> Replace with `find_node` and write `parent` by reading `_parent`?

`find_node` either returns the node matching the key or `nullptr`, where here we go down the tree and stay on the parent if the exact key wasn't found in order to insert below it. This would be lost if using `find_node`

> src/hotspot/share/utilities/rbTree.inline.hpp line 237:
> 
>> 235: 
>> 236:     RBNode* uncle = parent->is_left_child() ? grandparent->_right : grandparent->_left;
>> 237:     if (is_black(uncle)) { // Parent is red, uncle is black
> 
> And uncle has to exist (can't be null) as per some invariant? Add assert.

A NIL node (nullptr) is considered black, so `is_black(nullptr)` is valid and returns true.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908763522
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908764855

From cnorrbin at openjdk.org  Thu Jan  9 13:14:39 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 13:14:39 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <UxZ4CawQBcm2rKQd0NmJsyNciwkFsgPBJs6TcazZqCI=.6a623faa-f139-41c7-b4e5-a7ce41e86a24@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <UxZ4CawQBcm2rKQd0NmJsyNciwkFsgPBJs6TcazZqCI=.6a623faa-f139-41c7-b4e5-a7ce41e86a24@github.com>
Message-ID: <CfGuXTiqomCI-hiOV8I_6tRNBfqGl6TsAFzEL9vWsQM=.d9756604-c181-43e0-a21c-24cad6c8b33c@github.com>

On Tue, 7 Jan 2025 18:38:12 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed coloring functions
>
> src/hotspot/share/utilities/rbTree.inline.hpp line 438:
> 
>> 436: 
>> 437:     node = curr;
>> 438:   }
> 
> @tstuefe,
> 
> Seems like nodes are not stable. To quote Wikipedia:
> 
>>- When the deleted node has 2 children (non-NIL), then we can swap its value with its in-order successor (the leftmost child of the right subtree), and then delete the successor instead. Since the successor is leftmost, it can only have a right child (non-NIL) or no child at all. 
> 
> This is quite unfortunate, as it becomes very difficult (impossible?) to have intrusive RB-trees with this. 
> 
> @caspernorrbin,
> 
> Finding information on this in the literature seems like it takes quite a bit of digging. Can't we replace this with swapping everything *but* the key and value?
> 
> ```c++
>   if (node->_left != nullptr && node->_right != nullptr) { // node has two children
>     RBNode* curr = node->_right;
>     while (curr->_left != nullptr) {
>       curr = curr->_left;
>     }
>   // Swap parent, left, right, and color
>   std::swap(curr->_parent, node->_parent);
>   std::swap(curr->_left, node->_left);
>   std::swap(curr->_right, node->_right);
>   std::swap(curr->_color, node->_color);
>   // Swap the parent's child pointer
>   if (curr->_parent->_left == node) curr->_parent->_left = curr;
>   if (curr->_parent->_right == node) curr->_parent->_right = curr;
>   // Set the children's parent pointers 
>   curr->_left->_parent = curr; curr->_right->_parent = curr;
> 
>   // and then the identical writes for node
>   if (node->_parent->_left == curr) node->_parent->_left = node;
>   if (node->_parent->_right == curr) node->_parent->_right = node;
>   // Set the children's parent pointers 
>   node->_left->_parent = node; node->_right->_parent = node;
> 
>   // Done, they've swapped places in the tree.
>   // node = curr; <- Don't do this anymore, should still delete node
>   }

Nodes are now stable! This was not something I had considered, but it's possible with what Johan suggested above. Previously, keys and values were swapped around between nodes during deletion but now we instead re-point the node's pointers instead. With this the key and value stays constant in a node through its lifetime, given the user does not themself change the value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908774771

From cnorrbin at openjdk.org  Thu Jan  9 13:17:42 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 13:17:42 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <QMbKo48O5-iB2twQCVeeUBLQSTa8-AukTGFK1ln6a5U=.65fa595a-ee3b-44a8-b7c3-fd46b22456b1@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <pOSDbb7W0iQO6bWIBVbqwqIBAH17Vx2zmJOdyel8Cpk=.25710294-ffba-4484-839d-b2f3a5ee028e@github.com>
 <QMbKo48O5-iB2twQCVeeUBLQSTa8-AukTGFK1ln6a5U=.65fa595a-ee3b-44a8-b7c3-fd46b22456b1@github.com>
Message-ID: <t9BBwb0yie6xQlvXsTGiqeKd05GQmXq2kt6vyXta3X0=.abd50fc5-3b58-4839-81a2-06c489717be4@github.com>

On Wed, 8 Jan 2025 11:02:00 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.hpp line 308:
>> 
>>> 306: 
>>> 307:   void free(void* ptr) { os::free(ptr); }
>>> 308: };
>> 
>> An issue with this allocator is that it doesn't call destructors on `free`. I think we should add this, or any future users may leak memory by mistake.
>
> Some more thoughts: It's not the allocator that should run the destructor, but the RBTree itself. It should probably enforce that the key is a trivial type also.

We now assert that the key is trivially destructible and the value's destructor is called when removing a node

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908778181

From stuefe at openjdk.org  Thu Jan  9 13:26:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Jan 2025 13:26:43 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <CfGuXTiqomCI-hiOV8I_6tRNBfqGl6TsAFzEL9vWsQM=.d9756604-c181-43e0-a21c-24cad6c8b33c@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <UxZ4CawQBcm2rKQd0NmJsyNciwkFsgPBJs6TcazZqCI=.6a623faa-f139-41c7-b4e5-a7ce41e86a24@github.com>
 <CfGuXTiqomCI-hiOV8I_6tRNBfqGl6TsAFzEL9vWsQM=.d9756604-c181-43e0-a21c-24cad6c8b33c@github.com>
Message-ID: <vjE5u4QOoDtkwHwAt_ka-B9tVldW__kJg0D6tymXtg8=.36dd7b9a-44c5-485e-b7c3-6d1070a4b2b7@github.com>

On Thu, 9 Jan 2025 13:12:21 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.inline.hpp line 438:
>> 
>>> 436: 
>>> 437:     node = curr;
>>> 438:   }
>> 
>> @tstuefe,
>> 
>> Seems like nodes are not stable. To quote Wikipedia:
>> 
>>>- When the deleted node has 2 children (non-NIL), then we can swap its value with its in-order successor (the leftmost child of the right subtree), and then delete the successor instead. Since the successor is leftmost, it can only have a right child (non-NIL) or no child at all. 
>> 
>> This is quite unfortunate, as it becomes very difficult (impossible?) to have intrusive RB-trees with this. 
>> 
>> @caspernorrbin,
>> 
>> Finding information on this in the literature seems like it takes quite a bit of digging. Can't we replace this with swapping everything *but* the key and value?
>> 
>> ```c++
>>   if (node->_left != nullptr && node->_right != nullptr) { // node has two children
>>     RBNode* curr = node->_right;
>>     while (curr->_left != nullptr) {
>>       curr = curr->_left;
>>     }
>>   // Swap parent, left, right, and color
>>   std::swap(curr->_parent, node->_parent);
>>   std::swap(curr->_left, node->_left);
>>   std::swap(curr->_right, node->_right);
>>   std::swap(curr->_color, node->_color);
>>   // Swap the parent's child pointer
>>   if (curr->_parent->_left == node) curr->_parent->_left = curr;
>>   if (curr->_parent->_right == node) curr->_parent->_right = curr;
>>   // Set the children's parent pointers 
>>   curr->_left->_parent = curr; curr->_right->_parent = curr;
>> 
>>   // and then the identical writes for node
>>   if (node->_parent->_left == curr) node->_parent->_left = node;
>>   if (node->_parent->_right == curr) node->_parent->_right = node;
>>   // Set the children's parent pointers 
>>   node->_left->_parent = node; node->_right->_parent = node;
>> 
>>   // Done, they've swapped places in the tree.
>>   // node = curr; <- Don't do this anymore, should still delete node
>>   }
>
> Nodes are now stable! This was not something I had considered, but it's possible with what Johan suggested above. Previously, keys and values were swapped around between nodes during deletion but now we re-point the node's pointers instead. With this the key and value stays constant in a node through its lifetime, given the user does not themself change the value.

@caspernorrbin @jdksjolen Excellent, thank you. 

For the Doubting Thomas I am, could you write a little gtest like this:

- node (key = size) value don't matter I guess.
- malloc n times, with random sizes, so variable sized, but large enough to hold at least a node structure
- then in a loop, add or remove a randomly chosen malloc block to the tree.

If we survive that, I am happy and will use this in the future in Metaspace. Probably also in other areas.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908793974

From epeter at openjdk.org  Thu Jan  9 13:28:52 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 9 Jan 2025 13:28:52 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <wC8r8_HCDKkE79Wj1UBs5Sah5YVYOY57jlqyc3qfqow=.2b441f90-af39-4622-8cbd-fca750938eaf@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <wC8r8_HCDKkE79Wj1UBs5Sah5YVYOY57jlqyc3qfqow=.2b441f90-af39-4622-8cbd-fca750938eaf@github.com>
Message-ID: <BWXgD_Lq0or9wqflGiYUCn0Fkj7xRAZaW75bslVARng=.959fd64c-b81d-4f3a-afdd-008444b804e5@github.com>

On Mon, 16 Dec 2024 18:42:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more test points
>
> src/java.base/share/classes/jdk/internal/vm/vector/Float16Math.java line 35:
> 
>> 33:  * The class {@code Float16Math} constains intrinsic entry points corresponding
>> 34:  * to scalar numeric operations defined in Float16 class.
>> 35:  * @author
> 
> Please remove all author tags. We haven't used them in new code in the JDK for some time.

@jatin-bhateja did you remove them? I still see an `@author`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908788132

From epeter at openjdk.org  Thu Jan  9 13:28:50 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 9 Jan 2025 13:28:50 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
Message-ID: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>

On Fri, 3 Jan 2025 20:42:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Updating copyright year of modified files.

We are on the final approach. Just a few small comments / suggestions left.

src/hotspot/share/opto/convertnode.cpp line 991:

> 989:       return Op_MinHF;
> 990:     default:
> 991:       return false;

Is that a sane return value? Should we not assert here?

src/hotspot/share/opto/library_call.cpp line 8665:

> 8663:     fatal_unexpected_iid(id);
> 8664:     break;
> 8665:   }

Suggestion:

  switch (id) {
    // Unary operations
    case vmIntrinsics::_sqrt_float16:
      result = _gvn.transform(new SqrtHFNode(C, control(), fld1));
      break;
    // Ternary operations
    case vmIntrinsics::_fma_float16:
      result = _gvn.transform(new FmaHFNode(control(), fld1, fld2, fld3));
      break;
    default:
      fatal_unexpected_iid(id);
      break;
  }

Formatting could be improved. In the other switch you indent the cases.
The lines are also a little long.

src/hotspot/share/opto/mulnode.cpp line 560:

> 558: // Compute the product type of two half float ranges into this node.
> 559: const Type* MulHFNode::mul_ring(const Type* t0, const Type* t1) const {
> 560:   if(t0 == Type::HALF_FLOAT || t1 == Type::HALF_FLOAT) return Type::HALF_FLOAT;

Suggestion:

  if(t0 == Type::HALF_FLOAT || t1 == Type::HALF_FLOAT) { return Type::HALF_FLOAT; }

src/hotspot/share/opto/superword.cpp line 2567:

> 2565:     // half float to float, in such a case back propagation of narrow type (SHORT)
> 2566:     // may not be possible.
> 2567:     if (n->Opcode() == Op_ConvF2HF || n->Opcode() == Op_ReinterpretHF2S) {

Is this relevant, or does that belong to a different (vector) RFE?

src/hotspot/share/opto/type.cpp line 460:

> 458:   RETURN_ADDRESS=make(Return_Address);
> 459:   FLOAT   = make(FloatBot);     // All floats
> 460:   HALF_FLOAT   = make(HalfFloatBot); // All half floats

Suggestion:

  HALF_FLOAT = make(HalfFloatBot); // All half floats

src/hotspot/share/opto/type.cpp line 1092:

> 1090:     if (_base == DoubleTop || _base == DoubleBot) return Type::BOTTOM;
> 1091:     typerr(t);
> 1092:     return Type::BOTTOM;

Please use curly-braces even for single-line ifs

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1434:

> 1432:                     return float16ToRawShortBits(valueOf(product + float16ToFloat(f16c)));
> 1433:                 });
> 1434:         return shortBitsToFloat16(res);

I don't understand what is happening here. But I leave this to @PaulSandoz to review

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2539863536
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908759602
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908769721
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908771698
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908776380
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908777422
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908779530
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908792237

From epeter at openjdk.org  Thu Jan  9 13:28:51 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 9 Jan 2025 13:28:51 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
 <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
Message-ID: <EA9V_FagegjxMab6HnaEsIfS5HRd2LBl5sc6d6a58cY=.74b119b0-c23d-4fba-a519-31cc7ad37866@github.com>

On Thu, 9 Jan 2025 13:14:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Updating copyright year of modified files.
>
> src/hotspot/share/opto/type.cpp line 460:
> 
>> 458:   RETURN_ADDRESS=make(Return_Address);
>> 459:   FLOAT   = make(FloatBot);     // All floats
>> 460:   HALF_FLOAT   = make(HalfFloatBot); // All half floats
> 
> Suggestion:
> 
>   HALF_FLOAT = make(HalfFloatBot); // All half floats

If alignment is already broken, we might as well just use single spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908778435

From stuefe at openjdk.org  Thu Jan  9 13:30:41 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Jan 2025 13:30:41 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <vjE5u4QOoDtkwHwAt_ka-B9tVldW__kJg0D6tymXtg8=.36dd7b9a-44c5-485e-b7c3-6d1070a4b2b7@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <UxZ4CawQBcm2rKQd0NmJsyNciwkFsgPBJs6TcazZqCI=.6a623faa-f139-41c7-b4e5-a7ce41e86a24@github.com>
 <CfGuXTiqomCI-hiOV8I_6tRNBfqGl6TsAFzEL9vWsQM=.d9756604-c181-43e0-a21c-24cad6c8b33c@github.com>
 <vjE5u4QOoDtkwHwAt_ka-B9tVldW__kJg0D6tymXtg8=.36dd7b9a-44c5-485e-b7c3-6d1070a4b2b7@github.com>
Message-ID: <jmuJREU1JJDS1184M9gI-2jVZ9ybn_D1XT2rHqje3J4=.11f521eb-858e-4799-a322-c8738eececf6@github.com>

On Thu, 9 Jan 2025 13:24:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Nodes are now stable! This was not something I had considered, but it's possible with what Johan suggested above. Previously, keys and values were swapped around between nodes during deletion but now we re-point the node's pointers instead. With this the key and value stays constant in a node through its lifetime, given the user does not themself change the value.
>
> @caspernorrbin @jdksjolen Excellent, thank you. 
> 
> For the Doubting Thomas I am, could you write a little gtest like this:
> 
> - node (key = size) value don't matter I guess.
> - malloc n times, with random sizes, so variable sized, but large enough to hold at least a node structure
> - then in a loop, add or remove a randomly chosen malloc block to the tree.
> 
> If we survive that, I am happy and will use this in the future in Metaspace. Probably also in other areas.

I realize that a simpler test would be to just create random nodes (key=size, value=this node's address), then add/remove randomly while checking that the node address still equals the node value. The old implementation would fail that test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908800097

From cnorrbin at openjdk.org  Thu Jan  9 13:34:38 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 13:34:38 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <jmuJREU1JJDS1184M9gI-2jVZ9ybn_D1XT2rHqje3J4=.11f521eb-858e-4799-a322-c8738eececf6@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <UxZ4CawQBcm2rKQd0NmJsyNciwkFsgPBJs6TcazZqCI=.6a623faa-f139-41c7-b4e5-a7ce41e86a24@github.com>
 <CfGuXTiqomCI-hiOV8I_6tRNBfqGl6TsAFzEL9vWsQM=.d9756604-c181-43e0-a21c-24cad6c8b33c@github.com>
 <vjE5u4QOoDtkwHwAt_ka-B9tVldW__kJg0D6tymXtg8=.36dd7b9a-44c5-485e-b7c3-6d1070a4b2b7@github.com>
 <jmuJREU1JJDS1184M9gI-2jVZ9ybn_D1XT2rHqje3J4=.11f521eb-858e-4799-a322-c8738eececf6@github.com>
Message-ID: <MK2PNE8PUBU-MlSMCFmgH0-oqiwgNP4QNdMvkKcc6g4=.ee2ea868-fe8b-49f5-a8b3-19b49c4f70f8@github.com>

On Thu, 9 Jan 2025 13:28:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> @caspernorrbin @jdksjolen Excellent, thank you. 
>> 
>> For the Doubting Thomas I am, could you write a little gtest like this:
>> 
>> - node (key = size) value don't matter I guess.
>> - malloc n times, with random sizes, so variable sized, but large enough to hold at least a node structure
>> - then in a loop, add or remove a randomly chosen malloc block to the tree.
>> 
>> If we survive that, I am happy and will use this in the future in Metaspace. Probably also in other areas.
>
> I realize that a simpler test would be to just create random nodes (key=size, value=this node's address), then add/remove randomly while checking that the node address still equals the node value. The old implementation would fail that test.

(Forgot to mention) I added a gtest that allocates and stores nodes together with their keys, then performs a bunch of deletions to then check that the value of the nodes remain unchanged. Can add another with addresses too to be extra safe

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908807381

From coleenp at openjdk.org  Thu Jan  9 13:34:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Jan 2025 13:34:39 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
Message-ID: <wwAwF9ePyVJAORFl1RKLcVEnyngfLST0iQoM-e1-Bh0=.4bbff6a3-9664-4ac3-b6f8-d5ce50d1c2d6@github.com>

On Tue, 7 Jan 2025 08:32:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.
>
> Not sure we're allowed to remove a copyright statement, even if not in the usual place.

put copyright back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1908806441

From jsjolen at openjdk.org  Thu Jan  9 13:54:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 9 Jan 2025 13:54:40 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <2aZ3F325V6oldgyjnTu9ToxrL_mJW26LJRWzEKLx3ak=.d61248e2-5f9f-45f0-b494-b2bb00a9f0b4@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <JsAD3IcUMs7Z0e2iUVTY1Bu_B-AgBrfopHHcf3e4MZc=.3ad7dbd8-ffc2-4b4f-bc70-b738109ffd6d@github.com>
 <qj-dBbtwooojct52g48-oc1HX9FbDUS4Ky8Xsvm3s54=.6fb1e652-6284-44d9-a142-09f0aac7dc7f@github.com>
 <2aZ3F325V6oldgyjnTu9ToxrL_mJW26LJRWzEKLx3ak=.d61248e2-5f9f-45f0-b494-b2bb00a9f0b4@github.com>
Message-ID: <_9yN_V21K0ahdD6tdYkUWO0UPAMAh5u97T4fT4G18L4=.d18c557c-15d1-4153-992c-3bf7aa5e6cd8@github.com>

On Thu, 9 Jan 2025 13:02:31 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> In fact, you can pre-size the GA such that it starts with a capacity of 2log(n+1)
>
> I thought the recursive versions looked neater, but changed them now to the iterative version with pre-sized GAs

I agree, they do look neater. The pre-sized GAs are also kinda costly, often you want to keep your allocated GA around for future calls (found this out the hard way), whilst stack allocations are just gonna be kept around and it's unlikely that we'll hit the stack ceiling but... Let's just be safe rather than sorry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908840922

From jsjolen at openjdk.org  Thu Jan  9 13:54:42 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 9 Jan 2025 13:54:42 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <CudSwCIQeCtEuV2FmCNpKUhIcGUJ4TYQFhL26mEcuGU=.d374405f-541a-45d2-a3c7-e3894b01bd55@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <JsAD3IcUMs7Z0e2iUVTY1Bu_B-AgBrfopHHcf3e4MZc=.3ad7dbd8-ffc2-4b4f-bc70-b738109ffd6d@github.com>
 <CudSwCIQeCtEuV2FmCNpKUhIcGUJ4TYQFhL26mEcuGU=.d374405f-541a-45d2-a3c7-e3894b01bd55@github.com>
Message-ID: <iImlMvppSXbkMKxzaF3eTMLOgQwpN1Oiee42gbANMn8=.7d22a846-be64-443a-81a9-8400871f5c84@github.com>

On Thu, 9 Jan 2025 13:05:09 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.inline.hpp line 203:
>> 
>>> 201:       curr = curr->_right;
>>> 202:     }
>>> 203:   }
>> 
>> Replace with `find_node` and write `parent` by reading `_parent`?
>
> `find_node` either returns the node matching the key or `nullptr`, where here we go down the tree and stay on the parent if the exact key wasn't found in order to insert below it. This would be lost if using `find_node`

Good point, thanks!

>> src/hotspot/share/utilities/rbTree.inline.hpp line 237:
>> 
>>> 235: 
>>> 236:     RBNode* uncle = parent->is_left_child() ? grandparent->_right : grandparent->_left;
>>> 237:     if (is_black(uncle)) { // Parent is red, uncle is black
>> 
>> And uncle has to exist (can't be null) as per some invariant? Add assert.
>
> A NIL node (nullptr) is considered black, so `is_black(nullptr)` is valid and returns true.

Oh right, could've found that out if I read the definition of `is_black`, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908838951
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908841641

From cnorrbin at openjdk.org  Thu Jan  9 14:08:00 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 14:08:00 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <MK2PNE8PUBU-MlSMCFmgH0-oqiwgNP4QNdMvkKcc6g4=.ee2ea868-fe8b-49f5-a8b3-19b49c4f70f8@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>
 <UxZ4CawQBcm2rKQd0NmJsyNciwkFsgPBJs6TcazZqCI=.6a623faa-f139-41c7-b4e5-a7ce41e86a24@github.com>
 <CfGuXTiqomCI-hiOV8I_6tRNBfqGl6TsAFzEL9vWsQM=.d9756604-c181-43e0-a21c-24cad6c8b33c@github.com>
 <vjE5u4QOoDtkwHwAt_ka-B9tVldW__kJg0D6tymXtg8=.36dd7b9a-44c5-485e-b7c3-6d1070a4b2b7@github.com>
 <jmuJREU1JJDS1184M9gI-2jVZ9ybn_D1XT2rHqje3J4=.11f521eb-858e-4799-a322-c8738eececf6@github.com>
 <MK2PNE8PUBU-MlSMCFmgH0-oqiwgNP4QNdMvkKcc6g4=.ee2ea868-fe8b-49f5-a8b3-19b49c4f70f8@github.com>
Message-ID: <hpYYiIeLGEezL40dAxNIrvNqiYM_9vK5FvnpCuXrJI0=.bae2a901-bfdc-4aea-8810-af6b0259ca8a@github.com>

On Thu, 9 Jan 2025 13:32:22 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> I realize that a simpler test would be to just create random nodes (key=size, value=this node's address), then add/remove randomly while checking that the node address still equals the node value. The old implementation would fail that test.
>
> (Forgot to mention) I added a gtest that allocates and stores nodes together with their keys, then performs a bunch of deletions to then check that the value of the nodes remain unchanged. Can add another with addresses too to be extra safe

I added a second test which creates nodes and stores their address as values. We then remove ~1/5 of all nodes. We then check that all remaining nodes' value hasn't changed and still equals the address.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908864415

From cnorrbin at openjdk.org  Thu Jan  9 14:08:00 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 14:08:00 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v9]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <zXS9yn9x3fsawyQJxgz_CvysRn_G9H3WplwBEOuluPc=.ecfee5c5-bef3-419b-88f4-2cb7937ef900@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  additonal node stability test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/6a06e15d..d904865b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=07-08

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

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

From cnorrbin at openjdk.org  Thu Jan  9 14:11:59 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 14:11:59 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v10]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <EVEXCjbLxU-NZklGF7TjLeBVvZ4QMQuRliTQ67699Yk=.4cfe4ce0-d0cd-48e6-aee8-88bf8e65b34a@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  chaged assert to EXPECTs in node tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/d904865b..43995578

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=08-09

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

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

From duke at openjdk.org  Thu Jan  9 14:14:54 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 9 Jan 2025 14:14:54 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v14]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <HbqGQieHyntMGFwXUr8KvqwPE5Z7XQthx78gxa5QL7E=.2e77d14d-e4e3-4f86-ba9a-e96e1ad80578@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/threads.hpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/379eaac8..0304668e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=12-13

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

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

From duke at openjdk.org  Thu Jan  9 14:27:56 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 9 Jan 2025 14:27:56 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  small fix to is_single_threaded and whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/0304668e..6e7bf186

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=13-14

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

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

From mdoerr at openjdk.org  Thu Jan  9 14:49:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Jan 2025 14:49:41 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <NO0ZBBV0DNmxT02QpIBcuuWI_pxmWUFfZIgEF1cRQ2Q=.ecd93400-802b-4d94-a39a-0d6f1324eccf@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <Q0Gew_GeNQLcwFQAZ3eiisUOCBMaAv8mHLpQOvSHSsM=.142a184c-5b17-4eef-8c74-497cb26c4635@github.com>
 <1KCTAPpnuy-hlRDH1FSYy4O8N37kYRBkFyQ3wmKPRe8=.2d2a0837-eaa3-4bc9-88db-febe686a6e90@github.com>
 <NO0ZBBV0DNmxT02QpIBcuuWI_pxmWUFfZIgEF1cRQ2Q=.ecd93400-802b-4d94-a39a-0d6f1324eccf@github.com>
Message-ID: <DwvUpRPR-aFUQYycy6FX0MHDND0JZabKdv5nnJLzUaM=.9e090272-1e01-4454-922d-bef9caaf19d1@github.com>

On Wed, 8 Jan 2025 20:48:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> (https://github.com/openjdk/jdk/blob/a641932427cbe8453130593355372837d70a098f/src/java.base/share/classes/com/sun/crypto/provider/GHASH.java#L281) In the java code, the 0 check is handled.
>
> The C2 compiler replaces this Java code by the intrinsic.

`len` is passed to the stub without null check: https://github.com/openjdk/jdk/blob/f9b11332eccd8a8ffb4128308f442b209d07a3b1/src/hotspot/share/opto/library_call.cpp#L7599
But I can see null checks in GHASH.java for all callers of `processBlocks`. So, your assertion should be fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1908942391

From jsjolen at openjdk.org  Thu Jan  9 14:51:47 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 9 Jan 2025 14:51:47 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v10]
In-Reply-To: <EVEXCjbLxU-NZklGF7TjLeBVvZ4QMQuRliTQ67699Yk=.4cfe4ce0-d0cd-48e6-aee8-88bf8e65b34a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <EVEXCjbLxU-NZklGF7TjLeBVvZ4QMQuRliTQ67699Yk=.4cfe4ce0-d0cd-48e6-aee8-88bf8e65b34a@github.com>
Message-ID: <YAohT-I-_QDJGn48k3wan78_HM2q0Ir88pYK5dT9WVo=.235125a1-92dd-477e-bf86-00e0dddb2d23@github.com>

On Thu, 9 Jan 2025 14:11:59 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   chaged assert to EXPECTs in node tests

Could you add a comment saying that nodes are address stable?

src/hotspot/share/utilities/rbTree.hpp line 40:

> 38: // ALLOCATOR must check for oom and exit, as RBTree currently does not handle the
> 39: // allocation failing.
> 40: // Key needs to be of a type that is trivially destructable

destruct**i**ble

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

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2540125280
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1908940840

From mdoerr at openjdk.org  Thu Jan  9 14:55:40 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 9 Jan 2025 14:55:40 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
Message-ID: <CXdKZPttAAgaDryHu78se7P1q1C1Wu75kmGhT0NhWdQ=.073f978b-a90b-4c95-b153-0f98b2dead6e@github.com>

On Thu, 9 Jan 2025 09:07:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

src/hotspot/cpu/ppc/vm_version_ppc.cpp line 310:

> 308: 
> 309:   if (FLAG_IS_DEFAULT(UseGHASHIntrinsics) && VM_Version::has_vsx()) {
> 310:     FLAG_SET_DEFAULT(UseGHASHIntrinsics, true);

An attempt to enable `UseGHASHIntrinsics` should be rejected if `!VM_Version::has_vsx()` and a warning printed. See handling of other flags.
Alternatively, we could require Power8 by doing [JDK-8331859](https://bugs.openjdk.org/browse/JDK-8331859) first (or at least a part of it).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1908953536

From fyang at openjdk.org  Thu Jan  9 15:03:53 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 9 Jan 2025 15:03:53 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines
Message-ID: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>

Hi, Please consider this small refactoring work.

It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range as I find it is within 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where we can do `mv` and `andr` instead.

Testing on Premier P550 SBC:
- [x] tier1-3 and gtest:all (release)
- [x] hotspot:tier1 (fastdebug)

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

Commit messages:
 - 8347352: RISC-V: Cleanup bitwise AND assembler routines

Changes: https://git.openjdk.org/jdk/pull/23008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23008&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347352
  Stats: 34 lines in 5 files changed: 1 ins; 10 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/23008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23008/head:pull/23008

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

From cnorrbin at openjdk.org  Thu Jan  9 15:07:20 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 9 Jan 2025 15:07:20 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v11]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <7KrXaReG3MjpD51XxcNQ0YHEYD6S4V9Go4MdYYcz5pE=.08626f5c-4d33-4273-bef2-0889e8059149@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  Improved comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/43995578..5d151681

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=09-10

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

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

From pchilanomate at openjdk.org  Thu Jan  9 15:13:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 9 Jan 2025 15:13:53 GMT
Subject: [jdk24] RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
Message-ID: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>

Hi all,

This pull request contains a backport of commit [ea495377](https://github.com/openjdk/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Patricio Chilano Mateo on 8 Jan 2025 and was reviewed by David Holmes, Alex Menkov and Serguei Spitsyn.

Thanks!

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

Commit messages:
 - Backport ea49537726db6530f0ddcc04d9938df3d6d18250

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

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

From jwaters at openjdk.org  Thu Jan  9 15:19:40 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Jan 2025 15:19:40 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <Vt0rZRBin3t6xRBRzAc2INqXj5GFG4NnuB978Dh1co4=.765cd8aa-bbb0-40f1-a40d-a7a860f78890@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/d3c09661...9d05cb8e

I believe this is now ready

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2580539653

From mbaesken at openjdk.org  Thu Jan  9 16:08:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 9 Jan 2025 16:08:39 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/194de2f3...9d05cb8e

Hi, the workaround 'disable lto in g1ParScanThreadState because of special inlining/flattening used there'  is removed , why this works now ?

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2580668642

From jsjolen at openjdk.org  Thu Jan  9 16:15:54 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 9 Jan 2025 16:15:54 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v11]
In-Reply-To: <7KrXaReG3MjpD51XxcNQ0YHEYD6S4V9Go4MdYYcz5pE=.08626f5c-4d33-4273-bef2-0889e8059149@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <7KrXaReG3MjpD51XxcNQ0YHEYD6S4V9Go4MdYYcz5pE=.08626f5c-4d33-4273-bef2-0889e8059149@github.com>
Message-ID: <lPj6uRxweE3-ZpTvS6JB1GdcfVwTAhDdySDgz5t_iTw=.b140121c-9ef1-41b9-9e0e-4b849b742df6@github.com>

On Thu, 9 Jan 2025 15:07:20 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved comments

One unclear comment, but I am happy with this now.

Thank you!!!

src/hotspot/share/utilities/rbTree.hpp line 42:

> 40: // Key needs to be of a type that is trivially destructible.
> 41: // The tree will call a value's destructor when its node is removed.
> 42: // Nodes are address stable and will not change during its lifetime unless modified by the user.

How would a node's address be modified by the user? The address never changes!

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2540355029
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1909100250

From cjplummer at openjdk.org  Thu Jan  9 16:30:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 9 Jan 2025 16:30:38 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <2PJDQvsH4HJcxarS6uEfxPdmiqdTTwdfjF-N8eQO544=.bc362092-4acd-48e1-80e1-97c207f6b881@github.com>

On Thu, 9 Jan 2025 05:03:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

src/hotspot/share/prims/jvmtiExport.cpp line 1105:

> 1103: 
> 1104:   if (JavaThread::current()->hide_jvmti_events()) {
> 1105:     return false; // no events should be posted if thread is in VTMS alike transition

I don't think your use of "alike" is what you mean here. Did you mean "VTMS-like", or maybe something like "VTMS transition or similar state".

Also `hide_jvmti_events()` is a pretty self explanatory name already. Probably no comment is needed at the call sites, and instead you should just add a comment where `hide_jvmti_events()` is declared.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1909124132

From aph at openjdk.org  Thu Jan  9 16:37:07 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 9 Jan 2025 16:37:07 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal code
Message-ID: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>

Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.

This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.

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

Commit messages:
 - 8346890: AArch64: Profile counters generate suboptimal code
 - tmp

Changes: https://git.openjdk.org/jdk/pull/23012/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346890
  Stats: 29 lines in 3 files changed: 14 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23012.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23012/head:pull/23012

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

From sspitsyn at openjdk.org  Thu Jan  9 16:37:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Jan 2025 16:37:36 GMT
Subject: [jdk24] RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
References: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
Message-ID: <3kIPqTJxO_qVqWMYdMUMyk0NYGQdgWo6OaDrV9xUgvQ=.255ba8e1-482c-4b85-b181-38d865c5166e@github.com>

On Thu, 9 Jan 2025 14:18:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea495377](https://github.com/openjdk/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Patricio Chilano Mateo on 8 Jan 2025 and was reviewed by David Holmes, Alex Menkov and Serguei Spitsyn.
> 
> Thanks!

This is a clean backport. Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23007#pullrequestreview-2540409022

From duke at openjdk.org  Thu Jan  9 16:38:40 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 9 Jan 2025 16:38:40 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <BlJktc_h0m47MDOqZ47OOYX1fQmJTVfqQXE3ahJGcHI=.142785d4-cfb0-4a5a-935c-dcdff26bc8b9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
 <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
 <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>
 <BlJktc_h0m47MDOqZ47OOYX1fQmJTVfqQXE3ahJGcHI=.142785d4-cfb0-4a5a-935c-dcdff26bc8b9@github.com>
Message-ID: <XDj2DWCi60HZIYDmDX7Ur3jm11-PRfFHbxDR2k5p1YY=.6b2801ff-4b21-44ba-84c3-a3a660d6997c@github.com>

On Tue, 7 Jan 2025 04:40:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> In case my comment within the existing conversations gets missed I will re-state that I don't think you need any new "is bootstrapping" logic because you can just use `Threads::number_of_threads() > 0` to tell you if you need to acquire the NMT lock. Though that assumes that the `WatcherThread` does not use NMT ... but in that case you can use `WatcherThread::watcher_thread() != nullptr` as the bootstrap condition instead.
>> 
>> I think that the `WatcherThread` does use NMT (at least upon starting), since `Thread::call_run() ` calls `register_thread_stack_with_NMT()`. However, it looks like `WatcherThread::stop()` is called early in `before_exit` -- after which point NMT can still  be used. So checking `WatcherThread::watcher_thread() != nullptr` may not work in this case as it could be set back to nullptr too early.
>> 
>> Another solution might be to introduce something like `Threads::is_single_threaded()` which checks for  `WatcherThread`, `Threads::number_of_threads()`, and any other threads that fall outside this set. I'm not sure whether that would be better than the current approach.
>
>> However, it looks like `WatcherThread::stop()` is called early in `before_exit` -- after which point NMT can still be used. 
> 
> Yeah good catch. I just find it frustrating that we already have so many initialization-progress markers but we are looking at adding yet-another-one. Also I'm not sure this is really relevant to mutex itself per-se it is rather about whether mutexes are needed - to that end I don't find `Threads::is_single_threaded() ` a terrible suggestion.

@dholmes-ora I don't think it is enough to check whether we are single threaded.  Some GHA tests are failing with 


Internal Error (d:\a\jdk\jdk\src\hotspot\share\nmt/memTracker.hpp:68), pid=5708, tid=1620
#  assert(Threads::is_single_threaded() || NmtVirtualMemory_lock->owned_by_self()) failed: should have acquired NmtVirtualMemory_lock


Say **thread_A** is the only thread started. It does not acquire the lock (since single threaded) and enters the critical section. While **thread_A** is in the critical section, **thread_B** is started, acquires the lock (no longer single threaded), and joins **thread_A** in the critical section. The spontaneous creation of **thread_B** creates a race and also causes **thread_A** to trigger assertions checking that it is owner of the lock. 

Maybe the old approach is safer since we always acquire the lock as soon as bootstrapping makes it possible to do so.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2580756863

From amitkumar at openjdk.org  Thu Jan  9 16:54:44 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 9 Jan 2025 16:54:44 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
Message-ID: <4yEVwBY9ohA509y6IcFZ0beUtFYxMVGnfMPBp0v6R68=.03eb13a0-39ad-4205-a846-f465c69dc248@github.com>

On Thu, 9 Jan 2025 09:07:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 640:

> 638: //      subkeyH:    R4_ARG2
> 639: //      data: R5_ARG3
> 640: //      blocks: R6_ARG4

How about aligning the comments like this: 

Suggestion:

// Generate stub for GHASH process blocks.
//
// Arguments for generated stub:
//      state:    R3_ARG1 (long[] state)
//      subkeyH:  R4_ARG2 (long[] subH)
//      data:     R5_ARG3 (byte[] data)
//      blocks:   R6_ARG4 (number of 16-byte blocks to process)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1909156084

From kbarrett at openjdk.org  Thu Jan  9 18:32:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 18:32:42 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v7]
In-Reply-To: <X3JbN615LyqQ6XP--iUH-GPjHHq5ml1vmhF6_mhfRN4=.9a0d6182-7d7d-42d1-a3cb-4917b96cec28@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <WLAjyUn1yLQkDX4PtJyB7VoXGlIdeMg2vzq3fTy3Wpk=.1cd1b4b9-6ff9-4475-bdb6-5698a9beee2a@github.com>
 <X3JbN615LyqQ6XP--iUH-GPjHHq5ml1vmhF6_mhfRN4=.9a0d6182-7d7d-42d1-a3cb-4917b96cec28@github.com>
Message-ID: <abkJCWVSDvtDbUxnxS0CC4hFgD6iWC90qE0NWnqL9QE=.85b65c01-ffbe-4bba-b1d5-826cd05a8ad2@github.com>

On Thu, 9 Jan 2025 12:58:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stefank whitespace suggestions
>
> src/hotspot/os/bsd/permitForbiddenFunctions_bsd.hpp line 30:
> 
>> 28: #include "permitForbiddenFunctions_posix.hpp"
>> 29: 
>> 30: #endif // OS_BSD_PERMITFORBIDDENFUNCTIONS_BSD_HPP
> 
> I thought you were eliminating these in favor of #ifdef where included?

Removed the forbid files, forgot the permit files.  Sigh!  I'll push a new commit after running tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1909272432

From matsaave at openjdk.org  Thu Jan  9 19:04:51 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Jan 2025 19:04:51 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <uJRJVx-1cgnpbh7t7yfoncqGEEEbkws2BfWkUFUA7zI=.5e095d4b-0b48-4c3c-a179-e7870d6e61ad@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

>From what I've looked at so far it looks good! I noticed there are several cases where you mix format specifiers with macros. I understand that replacing other macros may not be in the scope of this change but I find it inconsistent in places where we have both. 

I listed out some of the cases below, but if you don't believe this to be necessary you can ignore me.

src/hotspot/os/bsd/os_bsd.cpp line 2527:

> 2525:              "\n\n"
> 2526:              "Do you want to debug the problem?\n\n"
> 2527:              "To debug, run 'gdb /proc/%d/exe %d'; then switch to thread %zd (" INTPTR_FORMAT ")\n"

There is both `%zd` and `INTPTR_FORMAT` in this line. I think it would be more consistent to convert both to format specifiers here.

src/hotspot/os/linux/os_linux.cpp line 5276:

> 5274:                "\n\n"
> 5275:                "Do you want to debug the problem?\n\n"
> 5276:                "To debug, run 'gdb /proc/%d/exe %d'; then switch to thread %zu (" INTPTR_FORMAT ")\n"

Same as above

src/hotspot/os/windows/os_windows.cpp line 533:

> 531:   }
> 532: 
> 533:   log_info(os, thread)("Thread is alive (tid: %zu, stacksize: " SIZE_FORMAT "k).", os::current_thread_id(), thread->stack_size() / K);

Same as above, this time with `SIZE_FORMAT`

src/hotspot/os/windows/os_windows.cpp line 618:

> 616:   thread->set_osthread(osthread);
> 617: 
> 618:   log_info(os, thread)("Thread attached (tid: %zu, stack: "

This line also mixes format specifiers and macros

src/hotspot/os/windows/os_windows.cpp line 3340:

> 3338:     if (Verbose && PrintMiscellaneous) {
> 3339:       reserveTimer.stop();
> 3340:       tty->print_cr("reserve_memory of %zx bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,

Here too

src/hotspot/share/classfile/classLoaderStats.cpp line 115:

> 113:   Klass* parent_klass = (cls._parent == nullptr ? nullptr : cls._parent->klass());
> 114: 
> 115:   _out->print(INTPTR_FORMAT "  " INTPTR_FORMAT "  " INTPTR_FORMAT "  %6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "  ",

Here too

src/hotspot/share/classfile/classLoaderStats.cpp line 126:

> 124:   _out->cr();
> 125:   if (cls._hidden_classes_count > 0) {
> 126:     _out->print_cr(SPACE SPACE SPACE "                                    %6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "   + hidden classes",

And here

src/hotspot/share/classfile/classLoaderStats.cpp line 140:

> 138:   _out->print("Total = %-6zu", _total_loaders);
> 139:   _out->print(SPACE SPACE SPACE "                      ", "", "", "");
> 140:   _out->print_cr("%6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "  ",

And here

src/hotspot/share/code/vtableStubs.cpp line 82:

> 80: 
> 81: void VtableStub::print_on(outputStream* st) const {
> 82:   st->print("vtable stub (index = %d, receiver_location = %zd, code = [" INTPTR_FORMAT ", " INTPTR_FORMAT "])",

And here

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

Changes requested by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2540706941
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909299619
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909300550
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909300883
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909301552
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909301678
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303066
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303216
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303480
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303991

From psandoz at openjdk.org  Thu Jan  9 19:25:53 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 9 Jan 2025 19:25:53 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
 <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
Message-ID: <zX9mex0SPUb8umMa8uRwPvj9nsKwzoOqNio0CF8xPrA=.1c82220b-e200-4654-a67e-7ffbcf7a3bdb@github.com>

On Thu, 9 Jan 2025 13:23:19 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Updating copyright year of modified files.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1434:
> 
>> 1432:                     return float16ToRawShortBits(valueOf(product + float16ToFloat(f16c)));
>> 1433:                 });
>> 1434:         return shortBitsToFloat16(res);
> 
> I don't understand what is happening here. But I leave this to @PaulSandoz to review

Uncertain on what bits, but i am guessing it's mostly related to the fallback code in the lambda. To avoid the intrinsics operating on Float16 instances we instead "unpack" the carrier (16bits) values and pass those as arguments to the intrinsic. The fallback (when intrinsification is not supported) also accepts those carrier values as arguments and we convert the carriers to floats, operate on then, convert to the carrier, and then back to float16 on the result.

The code in the lambda could potentially be simplified if `Float16Math.fma` accepted six arguments the first three being the carrier values used by the intrinsic, and the subsequent three being the float16 values used by the fallback. Then we could express the code in the original source in the lambda. I believe when intrinsified there would be no penalty for those extra arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1909327094

From pchilanomate at openjdk.org  Thu Jan  9 20:13:48 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 9 Jan 2025 20:13:48 GMT
Subject: RFR: 8326236: assert(ce != nullptr) failed in
 Continuation::continuation_bottom_sender
Message-ID: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>

Please review the following fix. In method frame::safe_for_sender() we could read a sender_pc that matches StubRoutines::cont_returnBarrier() but there is no actual continuation in the stack. I added more details in the bug comments on how we can get into this situation. The extra check verifies there is a ContinuationEntry further up in the stack. I run the patch through mach5 tiers 1-2 for sanity testing and tiers 6-7.

Thanks,
Patricio

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

Commit messages:
 - v1

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

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

From aturbanov at openjdk.org  Thu Jan  9 20:23:37 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 9 Jan 2025 20:23:37 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
Message-ID: <qTltTWnWAEiw3Furw730-5pF55QbnuiyPAEI0vWet_o=.d1fc793c-810b-4f2f-a764-159d7a5e8716@github.com>

On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed jdk.internal package prefix from asm

test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/Util.java line 135:

> 133:      */
> 134:     public static void printClassFile(byte[] classFile) {
> 135:         int flags =  org.objectweb.asm.ClassReader.SKIP_DEBUG;

Nit. Pre-existing, buy may be worth to fix
Suggestion:

        int flags = org.objectweb.asm.ClassReader.SKIP_DEBUG;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22946#discussion_r1909386706

From alanb at openjdk.org  Thu Jan  9 20:32:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Jan 2025 20:32:37 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
Message-ID: <4GtzkRBR_ZsI88__nvWdUvW4GXBJKt7bmyNb0gmCOkA=.4eb2a08f-f9da-4c69-a860-64da90d80fce@github.com>

On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed jdk.internal package prefix from asm

Thanks for doing the right thing and reverting the package name and removing the `@modules` from the tests. I sample as many as I could and they look fine. I assume you'll bump the copyright headers of the modified tests before integrating.

Can you say which tiers have been run? I'm sure David can advise but I suspect you'll need to run most of the tiers to ensure that all the modified tests are run.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2581190049

From alanb at openjdk.org  Thu Jan  9 20:36:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Jan 2025 20:36:45 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
Message-ID: <jI5w1r1zMMUTcjMraqE4g0YFALQxLF22YwwV0aU4Hw4=.a7e2c22a-1d53-4613-86b3-cb28dbbdb16b@github.com>

On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed jdk.internal package prefix from asm

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2540875300

From coleenp at openjdk.org  Thu Jan  9 20:39:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Jan 2025 20:39:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <3rsYHTsq8K_5SIPzeMJQJFM6HMWNTz7OdCBgVBwUUD8=.f3b67c30-8ecb-4034-b0b7-8396c5f8b531@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

The intention is to keep INTPTR_FORMAT and some of the other format specifiers that vary by platform.  I have another issue to remove the SIZE_FORMAT ones but that's a bigger change.  So this mixture is intentional.

JLONG_FORMAT might be something we can remove too but I didn't want to do it all at once.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2581199763

From stooke at openjdk.org  Thu Jan  9 20:48:21 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 9 Jan 2025 20:48:21 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v5]
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  no need to force -XX:-UseZGC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22870/files
  - new: https://git.openjdk.org/jdk/pull/22870/files/f62bbd7c..4574a2d0

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

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

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

From lmesnik at openjdk.org  Thu Jan  9 20:53:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 9 Jan 2025 20:53:42 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
Message-ID: <M-zw1oZkCVC8S55fLzmLokFQ7MoNdK1CNqcv8A6U_Zo=.7b4bc528-f7f9-49e1-9c43-ce3d65545aab@github.com>

On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed jdk.internal package prefix from asm

Changes looks good.
The only concern is that jtreg might be fail to correctly compile so huge source set as testlibrary, but it should be addressed  by jtreg. 
Thank you for moving ASM.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2581222597

From lmesnik at openjdk.org  Thu Jan  9 21:05:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 9 Jan 2025 21:05:41 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <sSHgPYC0JMs4NMcgFz8MHFT_CvmADd41NpDFmEn6D2Q=.eabcbc36-3836-4a9f-98d3-00fdec6e4c51@github.com>

On Thu, 9 Jan 2025 05:03:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

Changes requested by lmesnik (Reviewer).

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

> 722:   void set_VTMS_transition_mark(bool val)        { Atomic::store(&_VTMS_transition_mark, val); }
> 723: 
> 724:   bool hide_jvmti_events() const                 { return _is_in_VTMS_transition || _is_disable_suspend; }

The name
hide_jvmti_events()
looks incorrect, like we change thread state to hide jvmti event and fail/return if can't.
I prefer something like
jvmti_events_hidden()
is_jvmti_event_posting_hidden()
or 
should_hide_jvmti_events()
To make clear that we read only some state.
Also, agree with Chris that comments are needed only in the implementation of this method.

Good to know when thread can and can't post events.

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

PR Review: https://git.openjdk.org/jdk/pull/22997#pullrequestreview-2540922332
PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1909428470

From stooke at openjdk.org  Thu Jan  9 21:15:37 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 9 Jan 2025 21:15:37 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v4]
In-Reply-To: <3jOPTXsCDtxgDPDlSW67E2-Sr9bOI-vIrIqoN9O8fns=.19075be5-37c0-4655-8fe4-4c633185d2bf@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <sexTLjbrme-gCVabfKszi9BeME0Chqz4Cg7dOH5GNg8=.9ee2ac81-9246-44e7-bb7b-ac9894be03fc@github.com>
 <3jOPTXsCDtxgDPDlSW67E2-Sr9bOI-vIrIqoN9O8fns=.19075be5-37c0-4655-8fe4-4c633185d2bf@github.com>
Message-ID: <iEV4GdRzWm6XRgAZAYYHyrkFahIy5sPBXG7KAM0W7eQ=.29ea5706-3451-41b7-8c37-3407ae144da7@github.com>

On Thu, 9 Jan 2025 03:05:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test SystemMap with and without ZGC
>
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 39:
> 
>> 37:  *          java.management
>> 38:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
>> 39:  * @run testng/othervm -XX:+UsePerfData -XX:-UseZGC SystemMapTest
> 
> Technically you don't need to disable ZGC as the requires clause means it is already not the selected GC

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1909438912

From lmesnik at openjdk.org  Thu Jan  9 21:26:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 9 Jan 2025 21:26:42 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v5]
In-Reply-To: <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
Message-ID: <YXLtAY6gddyOCfwS85hxwiK1F8Gmvhrb-uQErcnj9JE=.7e96d931-0fd9-4324-b810-02ba59ac415d@github.com>

On Thu, 9 Jan 2025 20:48:21 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to force -XX:-UseZGC

Test changes looks good.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2540955666

From matsaave at openjdk.org  Thu Jan  9 21:52:47 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Jan 2025 21:52:47 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Looks good! I saw the discussion on `UINTPTR_FORMAT_X_0` so I left it alone.

src/hotspot/share/runtime/objectMonitor.cpp line 2500:

> 2498:   // The minimal things to print for markWord printing, more can be added for debugging and logging.
> 2499:   st->print("{contentions=0x%08x,waiters=0x%08x"
> 2500:             ",recursions=%zd,owner=" INT64_FORMAT "}",

Is `INT64_FORMAT` different from `INTX_FORMAT`?

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2540981143
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909469703

From kbarrett at openjdk.org  Thu Jan  9 22:00:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 22:00:59 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
 <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>
Message-ID: <B6oyiuXbdW78wAwUKpFINC4wUo5MUZluKK5LkFwAbSQ=.9488e486-cc73-4f9e-ac86-08be39c525e2@github.com>

On Thu, 9 Jan 2025 21:47:47 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore copyright and macro.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 2500:
> 
>> 2498:   // The minimal things to print for markWord printing, more can be added for debugging and logging.
>> 2499:   st->print("{contentions=0x%08x,waiters=0x%08x"
>> 2500:             ",recursions=%zd,owner=" INT64_FORMAT "}",
> 
> Is `INT64_FORMAT` different from `INTX_FORMAT`?

Currently yes.  The type underlying [u]intx varies by platform, being a 32-bit type on 32-bit platforms and a
64-bit type on 64-bit platforms.  We've been trimming the set of supported 32-bit platforms though, so maybe
someday we won't need that distinction any more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909478987

From kbarrett at openjdk.org  Thu Jan  9 22:07:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 22:07:12 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v8]
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge branch 'master' into new-poison
 - Merge branch 'master' into new-poison
 - remove more os-specific posix forwarding headers
 - stefank whitespace suggestions
 - add permit wrapper for strdup and use in aix
 - remove os-specific posix forwarding headers
 - aix permit patches
 - more fixes for clang noreturn issues
 - Merge branch 'master' into new-poison
 - update copyrights
 - ... and 5 more: https://git.openjdk.org/jdk/compare/02b290ae...6d49abbb

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22890/files
  - new: https://git.openjdk.org/jdk/pull/22890/files/97a56ae6..6d49abbb

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

  Stats: 18325 lines in 471 files changed: 5136 ins; 11130 del; 2059 mod
  Patch: https://git.openjdk.org/jdk/pull/22890.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22890/head:pull/22890

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

From lliu at openjdk.org  Thu Jan  9 23:40:41 2025
From: lliu at openjdk.org (Liming Liu)
Date: Thu, 9 Jan 2025 23:40:41 GMT
Subject: Integrated: 8343978: Update the default value of CodeEntryAlignment
 for Ampere-1A and 1B
In-Reply-To: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
References: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
Message-ID: <Ycn534wSWQy1s6fpdqMD0ItIw49CK4suKJv7BTQ6RaM=.609bb4de-1bf6-40c7-b36d-1abe9e6036b0@github.com>

On Fri, 15 Nov 2024 07:01:23 GMT, Liming Liu <lliu at openjdk.org> wrote:

> This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128.
> 
> Ran JTReg tier1 on Ampere-1A and no new issues were found.

This pull request has now been integrated.

Changeset: 89ee1a55
Author:    Liming Liu <lliu at openjdk.org>
Committer: Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89ee1a5517ea1e3915f4362ada3d2086b63c107e
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8343978: Update the default value of CodeEntryAlignment for Ampere-1A and 1B

Reviewed-by: dlong, kvn

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

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

From sspitsyn at openjdk.org  Fri Jan 10 01:51:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 01:51:45 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <2PJDQvsH4HJcxarS6uEfxPdmiqdTTwdfjF-N8eQO544=.bc362092-4acd-48e1-80e1-97c207f6b881@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <2PJDQvsH4HJcxarS6uEfxPdmiqdTTwdfjF-N8eQO544=.bc362092-4acd-48e1-80e1-97c207f6b881@github.com>
Message-ID: <3kgFYEHLWogjTf_7G5ozn99ySOFbQ_pLBcAh2bEB6qE=.119f486e-a519-4ee3-a00a-15666c234461@github.com>

On Thu, 9 Jan 2025 16:28:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1105:
> 
>> 1103: 
>> 1104:   if (JavaThread::current()->hide_jvmti_events()) {
>> 1105:     return false; // no events should be posted if thread is in VTMS alike transition
> 
> I don't think your use of "alike" is what you mean here. Did you mean "VTMS-like", or maybe something like "VTMS transition or similar state".
> 
> Also `hide_jvmti_events()` is a pretty self explanatory name already. Probably no comment is needed at the call sites, and instead you should just add a comment where `hide_jvmti_events()` is declared.

Thanks. Good suggestion. Will address.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1909665062

From sspitsyn at openjdk.org  Fri Jan 10 01:55:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 01:55:38 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <sSHgPYC0JMs4NMcgFz8MHFT_CvmADd41NpDFmEn6D2Q=.eabcbc36-3836-4a9f-98d3-00fdec6e4c51@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <sSHgPYC0JMs4NMcgFz8MHFT_CvmADd41NpDFmEn6D2Q=.eabcbc36-3836-4a9f-98d3-00fdec6e4c51@github.com>
Message-ID: <20aXW3vlQ-uGIZqVPQxx41SSifFMEcMxGw0w9OuTo3I=.a2e01672-c5ad-4e5d-b8ed-ecc67f2ea1b8@github.com>

On Thu, 9 Jan 2025 21:01:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> src/hotspot/share/runtime/javaThread.hpp line 724:
> 
>> 722:   void set_VTMS_transition_mark(bool val)        { Atomic::store(&_VTMS_transition_mark, val); }
>> 723: 
>> 724:   bool hide_jvmti_events() const                 { return _is_in_VTMS_transition || _is_disable_suspend; }
> 
> The name
> hide_jvmti_events()
> looks incorrect, like we change thread state to hide jvmti event and fail/return if can't.
> I prefer something like
> jvmti_events_hidden()
> is_jvmti_event_posting_hidden()
> or 
> should_hide_jvmti_events()
> To make clear that we read only some state.
> Also, agree with Chris that comments are needed only in the implementation of this method.
> 
> Good to know when thread can and can't post events.

Thank you for the comment.
I like this suggestion: `should_hide_jvmti_events()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1909668564

From sspitsyn at openjdk.org  Fri Jan 10 02:13:09 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 02:13:09 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v2]
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <XZSRdHFIqus75jIFOExEw4uFU-gLjMqG6dJIq0f7rRM=.5089b448-7075-45e4-ba64-e33b471318e7@github.com>

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: renamed to should_hide_jvmti_events; removed assert and unneeded comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22997/files
  - new: https://git.openjdk.org/jdk/pull/22997/files/2aa84d48..8cc92a90

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

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

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

From sspitsyn at openjdk.org  Fri Jan 10 02:27:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 02:27:16 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: tweak some assert messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22997/files
  - new: https://git.openjdk.org/jdk/pull/22997/files/8cc92a90..46527318

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

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

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

From fyang at openjdk.org  Fri Jan 10 02:29:45 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Jan 2025 02:29:45 GMT
Subject: [jdk24] RFR: 8346838: RISC-V:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crash with
 debug VMs
In-Reply-To: <iS5rhstmtYDqv5ndUWcW652k4zpugEKh0osXcwM6hOI=.a43e37ee-6e0b-49b2-852e-1e32337ab9bb@github.com>
References: <iS5rhstmtYDqv5ndUWcW652k4zpugEKh0osXcwM6hOI=.a43e37ee-6e0b-49b2-852e-1e32337ab9bb@github.com>
Message-ID: <fXfb6Bz0621gVgrKpvHjQIsRSAOVskPPMIGpyglina0=.8c151edc-23ce-4cd0-93ce-ea13750e7525@github.com>

On Tue, 7 Jan 2025 10:44:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi all,
> 
> Same issue is there in jdk24 repo.
> 
> This pull request contains a backport of commit [379ac349](https://github.com/openjdk/jdk/commit/379ac349d13e2c0c6986eb0787f33b9a7a2a3749) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Fei Yang on 7 Jan 2025 and was reviewed by Feilong Jiang and Robbin Ehn.
> 
> Thanks!

@feilongjiang @robehn : Could you please take another look? I think this is a P3 bug and should be backported to jdk24. It could trigger for release build as well depending on where the libjvm.so is loaded. Sanity tested.

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

PR Comment: https://git.openjdk.org/jdk/pull/22944#issuecomment-2581615796

From fyang at openjdk.org  Fri Jan 10 03:18:35 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Jan 2025 03:18:35 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads
In-Reply-To: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
Message-ID: <znCg8e_m5MrKlvSBFSM9eC-_n0DM-JlKA-m3ll5zubY=.876c4413-1d01-4e29-8b08-95ad2045191b@github.com>

On Thu, 9 Jan 2025 12:55:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
> 
> If we need them before hwprobe we can add a flag for manually enabling them.
> 
> Sanity tested.
> 
> Thanks!

Thanks. One minor comment.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1338:

> 1336: 
> 1337: void MacroAssembler::csrr(Register Rd, unsigned csr) {
> 1338:   assert((csr != CSR_INSTRET && csr != CSR_CYCLE && csr != CSR_TIME) || VM_Version::ext_Zicntr.enabled(), "sanity");

Personally, I perfer to check a JVM option here (Say `UseZicntr` of diagnostic type). When we have hwprobe for this extension, we can further hook up this option to `VM_Version::ext_Zicntr`. And the user could still enable on command line before that. What do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/23003#pullrequestreview-2541469983
PR Review Comment: https://git.openjdk.org/jdk/pull/23003#discussion_r1909743262

From kbarrett at openjdk.org  Fri Jan 10 03:35:40 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Jan 2025 03:35:40 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
Message-ID: <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>

On Thu, 9 Jan 2025 16:06:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi, the workaround 'disable lto in g1ParScanThreadState because of special inlining/flattening used there' is removed , why this works now ?

The issue there was the `-Wattribute-warning` warnings that were being generated.  But this change is suppressing
those warnings in the LTO link:
https://github.com/openjdk/jdk/blame/9d05cb8eff344fea3c6b9a9686b728ec53963978/make/hotspot/lib/JvmFeatures.gmk#L176C11-L176C11
Note that won't work with the new portable forbidding mechanism based on `deprecated` attributes.

I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans.
The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2581673261

From gcao at openjdk.org  Fri Jan 10 07:13:56 2025
From: gcao at openjdk.org (Gui Cao)
Date: Fri, 10 Jan 2025 07:13:56 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v7]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <5y1CSV4O4pH0v5KUkkEjV-i2pI9P_hm25Oylyt2Vl6U=.e1a259ab-1d85-40b2-8a53-8bc1b419a572@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8342881
 - Update code comment
 - Update for RealFYang's comment
 - Merge remote-tracking branch 'upstream/master' into JDK-8342881
 - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

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

Changes: https://git.openjdk.org/jdk/pull/21922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=06
  Stats: 355 lines in 5 files changed: 281 ins; 23 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/21922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21922/head:pull/21922

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

From dholmes at openjdk.org  Fri Jan 10 07:18:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Jan 2025 07:18:37 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <MBXafo0I882JS7AW3TRT-vZcUhr1Zwg_aiWeErvtma0=.8e867441-b738-4d9d-975c-a07e6934b316@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
 <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
 <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>
 <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>
 <MBXafo0I882JS7AW3TRT-vZcUhr1Zwg_aiWeErvtma0=.8e867441-b738-4d9d-975c-a07e6934b316@github.com>
Message-ID: <012w8uAs0fzFh52ycdTUSBLh0Kv-TgwiCSAdWA5sBDM=.16e4e1be-6fbe-4543-b565-499fd7c40f63@github.com>

On Thu, 9 Jan 2025 06:31:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yes, I think it's fine to say !WINDOWS instead of listing all the posix ports.  We've been avoiding dispatch files and once it reaches a threshold of too many #ifdef !WINDOWS #include posix.hpp one, then we could add another macro like the OS_CPU one.
>> 
>> Also the copyright script added 2025 for these because they started with 2024 so it's sort of a bug in the script but not really solvable because it doesn't know that you didn't check this in in 2024.
>
> @coleenp The copyrights on the new files being 2024-2025 is intentional. They were first published (in this PR)
> in 2024, so I think are supposed to have that starting year.

@kimbarrett I understand. I also don't like the includer needing to know about this, and maybe it is time to add OS_FAMILY_HEADER to deal with it. But in the absence of the new macro I prefer this break of abstraction to the creation of a bunch of tiny forwarding files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1909925627

From gcao at openjdk.org  Fri Jan 10 07:18:39 2025
From: gcao at openjdk.org (Gui Cao)
Date: Fri, 10 Jan 2025 07:18:39 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v6]
In-Reply-To: <zRj1T_lGvUVtr0G9IiNmb1Jf9vL_y4sQRkijV7xDHTo=.a6cc6021-7c28-4c75-846d-6f7fd5d36845@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <vQqj01yERuZXYKDqyu9OOJnRaKQUJ_jQfePafsRTgvo=.877c8fb5-249e-4804-8d17-ad0ff3151d7e@github.com>
 <zRj1T_lGvUVtr0G9IiNmb1Jf9vL_y4sQRkijV7xDHTo=.a6cc6021-7c28-4c75-846d-6f7fd5d36845@github.com>
Message-ID: <X30Ts1ASV8HPy6kqjDZnxyK3UCSSbHX0uxmj_o8uGbE=.1452303c-8ab7-4364-8afc-81f5a7bf6abe@github.com>

On Thu, 9 Jan 2025 11:39:43 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Could you please merge master? Then we can rename this routine to: `void ror(Register dst, Register src, Register shift, Register tmp = t0);`

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1909925773

From dholmes at openjdk.org  Fri Jan 10 07:21:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Jan 2025 07:21:42 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <SQUEdE1fFiWXLWxBQIDvCikr0Ynw5UP_evoTeNkQdiI=.15525857-a5f9-48fc-b02b-a7e9562a5569@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <uQZFy3A5oc4sHZ14IY-dAv6isIbRT176whMAYBNxVRc=.15aaf160-51d6-40b5-b4d9-e8842be358bb@github.com>
 <zpmO8SXwIHkeuwFe6mAisGmGLwXKfMyUWAtgGcxAUM0=.1d6c3660-d191-474c-b527-dbd4d145abd0@github.com>
 <YBl0QWTX01LYMxsH7mOrFVfRJDUOl0PJErdyO5VA9Ow=.9dd25af9-c4df-4a38-bf79-d1bf88155edc@github.com>
 <SQUEdE1fFiWXLWxBQIDvCikr0Ynw5UP_evoTeNkQdiI=.15525857-a5f9-48fc-b02b-a7e9562a5569@github.com>
Message-ID: <x8JmNju6MP1KzBu2TFMnCJ5H7ncBnJl4x37_H6495-I=.36e13324-6bcd-4f4a-8c7d-62811564eea9@github.com>

On Thu, 9 Jan 2025 09:36:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hmmm ... okay ... I see something "special" is done only on x86_32, but what is done seems to have nothing to do with x87 code.
>> 
>> Just to be clear these Java methods still get intrinsified, it is just handled in a different way - right?
>
> It *is* about x87 handling of NaNs, a common problem for x86_32 code in Hotspot, you can read about this mess in [JDK-8076373](https://bugs.openjdk.org/browse/JDK-8076373), if you are interested. If we allow to use native implementations of these conversion methods, we get into trouble with NaNs. What these interpreter intrinsics do on x86_32: going for SSE if available, thus avoiding x87. Since this is a correctness problem, these intrinsics go all the way down to interpreter as well. There is still a gaping hole when SSE is not available, but then we have no choice than to use x87 and have all the relevant issues. 
> 
> But all of this is only a headache for x86_32, all other platforms do not have these interpreter intrinsics implemented. With x86_32 going away, we can finally yank these and relevant scaffolding out.
> 
> The C1/C2 intrinsics are still up and enabled for supported platforms: those are for performance :)

Okay now I get. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1909928264

From dholmes at openjdk.org  Fri Jan 10 07:24:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Jan 2025 07:24:45 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <XDj2DWCi60HZIYDmDX7Ur3jm11-PRfFHbxDR2k5p1YY=.6b2801ff-4b21-44ba-84c3-a3a660d6997c@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
 <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
 <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>
 <BlJktc_h0m47MDOqZ47OOYX1fQmJTVfqQXE3ahJGcHI=.142785d4-cfb0-4a5a-935c-dcdff26bc8b9@github.com>
 <XDj2DWCi60HZIYDmDX7Ur3jm11-PRfFHbxDR2k5p1YY=.6b2801ff-4b21-44ba-84c3-a3a660d6997c@github.com>
Message-ID: <ZHVTDvHqC88pptUappNNRoQAUEHfyShcABIlJSX-5DQ=.24762956-3b68-4ab3-aa73-01d5f2367408@github.com>

On Thu, 9 Jan 2025 16:34:08 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> Say **thread_A** is the only thread started. It does not acquire the lock (since single threaded) and enters the critical section. While **thread_A** is in the critical section, **thread_B** is started,

Hold on there - who is starting thread B? Only thread A exists and it won't create thread B from within the critical section.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2581949574

From dholmes at openjdk.org  Fri Jan 10 07:26:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Jan 2025 07:26:42 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v5]
In-Reply-To: <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
Message-ID: <DZ7jtKPxUoloPYfY5PHXBq6hRZi0aE4QccvXkePIimE=.e0e21569-12ef-46e7-90b5-c0bc742f78a6@github.com>

On Thu, 9 Jan 2025 20:48:21 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to force -XX:-UseZGC

Looks good. Let's get this integrated! :) Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2541709646

From lliu at openjdk.org  Fri Jan 10 07:47:55 2025
From: lliu at openjdk.org (Liming Liu)
Date: Fri, 10 Jan 2025 07:47:55 GMT
Subject: [jdk24] RFR: 8343978: Update the default value of CodeEntryAlignment
 for Ampere-1A and 1B
Message-ID: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>

Hi all,

This pull request contains a backport of commit 89ee1a55 from the openjdk/jdk repository.

The commit being backported was authored by Liming Liu on 9 Jan 2025 and was reviewed by Dean Long and Vladimir Kozlov.

Thanks!

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

Commit messages:
 - Backport 89ee1a5517ea1e3915f4362ada3d2086b63c107e

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

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

From gcao at openjdk.org  Fri Jan 10 08:16:09 2025
From: gcao at openjdk.org (Gui Cao)
Date: Fri, 10 Jan 2025 08:16:09 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v8]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <K4CWBLZiCvgiPHwY-JXbp3FJl4kc1rEeZBIolQfJvt4=.256ff38e-6b90-408f-b0a0-e8e6db184575@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request incrementally with one additional commit since the last revision:

  Add MacroAssembler::ror function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21922/files
  - new: https://git.openjdk.org/jdk/pull/21922/files/3bcd76e4..82024b31

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

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

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

From rehn at openjdk.org  Fri Jan 10 08:44:35 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Jan 2025 08:44:35 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads
In-Reply-To: <znCg8e_m5MrKlvSBFSM9eC-_n0DM-JlKA-m3ll5zubY=.876c4413-1d01-4e29-8b08-95ad2045191b@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <znCg8e_m5MrKlvSBFSM9eC-_n0DM-JlKA-m3ll5zubY=.876c4413-1d01-4e29-8b08-95ad2045191b@github.com>
Message-ID: <aUfiIuOyL-K3w2D-NyYHSo5yQMH8LxbAzfqpqKbqAvE=.14ae35c7-9d03-4b0a-9287-f35630fa171d@github.com>

On Fri, 10 Jan 2025 03:13:41 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
>> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
>> 
>> If we need them before hwprobe we can add a flag for manually enabling them.
>> 
>> Sanity tested.
>> 
>> Thanks!
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1338:
> 
>> 1336: 
>> 1337: void MacroAssembler::csrr(Register Rd, unsigned csr) {
>> 1338:   assert((csr != CSR_INSTRET && csr != CSR_CYCLE && csr != CSR_TIME) || VM_Version::ext_Zicntr.enabled(), "sanity");
> 
> Personally, I perfer to check a JVM option here (Say `UseZicntr` of diagnostic type). When we have hwprobe for this extension, we can further hook up this option to `VM_Version::ext_Zicntr`. And the user could still enable on command line before that. What do you think?

As these instructions are unused, no need to enable them, I'm hesitant to add an NO-OP option.
I figured that when we add uses fom them we can add that option, if needed.

Should I really add such dummy option?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23003#discussion_r1910005242

From rehn at openjdk.org  Fri Jan 10 08:48:36 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Jan 2025 08:48:36 GMT
Subject: [jdk24] RFR: 8346838: RISC-V:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crash with
 debug VMs
In-Reply-To: <iS5rhstmtYDqv5ndUWcW652k4zpugEKh0osXcwM6hOI=.a43e37ee-6e0b-49b2-852e-1e32337ab9bb@github.com>
References: <iS5rhstmtYDqv5ndUWcW652k4zpugEKh0osXcwM6hOI=.a43e37ee-6e0b-49b2-852e-1e32337ab9bb@github.com>
Message-ID: <uvQOVuYGRs57XMAAqkAazNIIhATPy9BQC-WuMwnnFJs=.b88dc185-7964-41aa-93f2-4ab4af3598c7@github.com>

On Tue, 7 Jan 2025 10:44:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi all,
> 
> Same issue is there in jdk24 repo.
> 
> This pull request contains a backport of commit [379ac349](https://github.com/openjdk/jdk/commit/379ac349d13e2c0c6986eb0787f33b9a7a2a3749) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Fei Yang on 7 Jan 2025 and was reviewed by Feilong Jiang and Robbin Ehn.
> 
> Thanks!

Thanks!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22944#pullrequestreview-2541838847

From shade at openjdk.org  Fri Jan 10 09:53:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 09:53:35 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal
 code
In-Reply-To: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
Message-ID: <SnpFIORGv1jPZ1gP5LOUmmibfhIiFfWRdvQFF5s_J8M=.58ac474b-0a8c-4270-a15c-9d6b79138644@github.com>

On Thu, 9 Jan 2025 16:30:49 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.
> 
> This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.

Can you explain a bit more here? I think I get why would we want to rewrite `lea+ldr` to `slot_at`. 

I do not quite understand why do we rewrite this one:


-    Address data_addr(mdo, md->byte_offset_of_slot(data, ReceiverTypeData::receiver_count_offset(i)));
-    __ addptr(data_addr, DataLayout::counter_increment);
+    __ addptr(slot_at(ReceiverTypeData::receiver_count_offset(i)),
+              DataLayout::counter_increment);


Does it really optimize anything to rewrite it to `slot_at`? If so, shouldn't this one in the other hunk also get rewritten?


         Address data_addr(mdo, md->byte_offset_of_slot(data, VirtualCallData::receiver_count_offset(i)));
          __ addptr(data_addr, DataLayout::counter_increment);

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

PR Review: https://git.openjdk.org/jdk/pull/23012#pullrequestreview-2542002023

From shade at openjdk.org  Fri Jan 10 09:56:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 09:56:44 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal
 code
In-Reply-To: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
Message-ID: <muvLByBEF7OcVJFpum0xSokmGoO5gRWFSOcsLoggiro=.0a371ecc-a05e-430c-886c-1eabda54a34f@github.com>

On Thu, 9 Jan 2025 16:30:49 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.
> 
> This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1384:

> 1382:     vtable_offset_in_bytes += vtable_index.as_constant() * wordSize;
> 1383:     ldr(method_result,
> 1384:         form_address(rscratch1, recv_klass, vtable_offset_in_bytes, LogBytesPerWord));

What is this change? Does not look equivalent to current code. Is this a bug fix?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23012#discussion_r1910119819

From cnorrbin at openjdk.org  Fri Jan 10 10:03:22 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 10 Jan 2025 10:03:22 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  clarified comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/5d151681..b2835590

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=10-11

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

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

From cnorrbin at openjdk.org  Fri Jan 10 10:03:22 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 10 Jan 2025 10:03:22 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v11]
In-Reply-To: <lPj6uRxweE3-ZpTvS6JB1GdcfVwTAhDdySDgz5t_iTw=.b140121c-9ef1-41b9-9e0e-4b849b742df6@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <7KrXaReG3MjpD51XxcNQ0YHEYD6S4V9Go4MdYYcz5pE=.08626f5c-4d33-4273-bef2-0889e8059149@github.com>
 <lPj6uRxweE3-ZpTvS6JB1GdcfVwTAhDdySDgz5t_iTw=.b140121c-9ef1-41b9-9e0e-4b849b742df6@github.com>
Message-ID: <9RfxPXCpvKj9SVdP3lcrm9TzQFuaQYwJ2PinLbpUoFQ=.35c471e3-10ff-499a-9c68-7c28a659779c@github.com>

On Thu, 9 Jan 2025 16:12:30 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved comments
>
> src/hotspot/share/utilities/rbTree.hpp line 42:
> 
>> 40: // Key needs to be of a type that is trivially destructible.
>> 41: // The tree will call a value's destructor when its node is removed.
>> 42: // Nodes are address stable and will not change during its lifetime unless modified by the user.
> 
> How would a node's address be modified by the user? The address never changes!

Removed the last part. I was trying to say that the content of a node never changes (unlike previously) unless the user explicitly changes the value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1910123322

From jsjolen at openjdk.org  Fri Jan 10 10:03:22 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 10 Jan 2025 10:03:22 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v11]
In-Reply-To: <9RfxPXCpvKj9SVdP3lcrm9TzQFuaQYwJ2PinLbpUoFQ=.35c471e3-10ff-499a-9c68-7c28a659779c@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <7KrXaReG3MjpD51XxcNQ0YHEYD6S4V9Go4MdYYcz5pE=.08626f5c-4d33-4273-bef2-0889e8059149@github.com>
 <lPj6uRxweE3-ZpTvS6JB1GdcfVwTAhDdySDgz5t_iTw=.b140121c-9ef1-41b9-9e0e-4b849b742df6@github.com>
 <9RfxPXCpvKj9SVdP3lcrm9TzQFuaQYwJ2PinLbpUoFQ=.35c471e3-10ff-499a-9c68-7c28a659779c@github.com>
Message-ID: <lgUJ06PJ83vrUeXnh2hzTrXJ7x4d1cIqSeO_pOd0XxY=.ca985db6-ecf5-4dc2-aa9d-e356f66be153@github.com>

On Fri, 10 Jan 2025 09:56:50 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.hpp line 42:
>> 
>>> 40: // Key needs to be of a type that is trivially destructible.
>>> 41: // The tree will call a value's destructor when its node is removed.
>>> 42: // Nodes are address stable and will not change during its lifetime unless modified by the user.
>> 
>> How would a node's address be modified by the user? The address never changes!
>
> Removed the last part. I was trying to say that the content of a node never changes (unlike previously) unless the user explicitly changes the value.

Yeah, I think that can be more confusing than not mentioning it :).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1910125824

From jsjolen at openjdk.org  Fri Jan 10 10:03:22 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 10 Jan 2025 10:03:22 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
Message-ID: <E6_kM1ccjc8NeKlOT-BO0zEslDIpR60Fy6xFDm7HGS8=.8e82284b-2e25-4f82-b831-a27a92cd8401@github.com>

On Fri, 10 Jan 2025 10:00:14 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified comment

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2542018746

From fyang at openjdk.org  Fri Jan 10 10:16:37 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Jan 2025 10:16:37 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v8]
In-Reply-To: <K4CWBLZiCvgiPHwY-JXbp3FJl4kc1rEeZBIolQfJvt4=.256ff38e-6b90-408f-b0a0-e8e6db184575@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <K4CWBLZiCvgiPHwY-JXbp3FJl4kc1rEeZBIolQfJvt4=.256ff38e-6b90-408f-b0a0-e8e6db184575@github.com>
Message-ID: <uhbKtG0Mt_ilPqweQKyOP9unoJjQg6wOF5AmEVbYisc=.d3db499e-87bb-4e50-b5f1-8092f99b3956@github.com>

On Fri, 10 Jan 2025 08:16:09 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add MacroAssembler::ror function

Looks good. Thanks for the update!

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21922#pullrequestreview-2542052807

From mli at openjdk.org  Fri Jan 10 10:27:01 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 10 Jan 2025 10:27:01 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe [v2]
In-Reply-To: <m-sbsXrg9J4sFny906TXhtBIt7YSaNlC7knipXcR6sg=.7af90449-83f1-4db0-bc9e-635eab80c557@github.com>
References: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
 <m-sbsXrg9J4sFny906TXhtBIt7YSaNlC7knipXcR6sg=.7af90449-83f1-4db0-bc9e-635eab80c557@github.com>
Message-ID: <sDxW4Q1KnFMXv9yOt_pVcUzLf9kdKYD_RHDUFx649x4=.506ffd66-a967-478d-9ae9-96b846dd8d5a@github.com>

On Fri, 20 Dec 2024 10:31:08 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review the patch?
>> Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.
>> 
>> Thanks!
>> 
>> Tests running so far so good.
>
> Hamlin Li 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 master
>  - only enable Zicboz
>  - initial commit

I've run specjbb and a simple jmh test, but seems not obvious improvement, I'll investigate further and update later when make any progress. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22474#issuecomment-2582304941

From fyang at openjdk.org  Fri Jan 10 10:44:44 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Jan 2025 10:44:44 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads
In-Reply-To: <aUfiIuOyL-K3w2D-NyYHSo5yQMH8LxbAzfqpqKbqAvE=.14ae35c7-9d03-4b0a-9287-f35630fa171d@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <znCg8e_m5MrKlvSBFSM9eC-_n0DM-JlKA-m3ll5zubY=.876c4413-1d01-4e29-8b08-95ad2045191b@github.com>
 <aUfiIuOyL-K3w2D-NyYHSo5yQMH8LxbAzfqpqKbqAvE=.14ae35c7-9d03-4b0a-9287-f35630fa171d@github.com>
Message-ID: <vKWSxKhceZw84Vm3eNFdOLDE-jceb7b5_saEgEYxQfo=.7b9883a3-f75a-422f-a46f-de1ea8c68d3f@github.com>

On Fri, 10 Jan 2025 08:41:34 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1338:
>> 
>>> 1336: 
>>> 1337: void MacroAssembler::csrr(Register Rd, unsigned csr) {
>>> 1338:   assert((csr != CSR_INSTRET && csr != CSR_CYCLE && csr != CSR_TIME) || VM_Version::ext_Zicntr.enabled(), "sanity");
>> 
>> Personally, I perfer to check a JVM option here (Say `UseZicntr` of diagnostic type). When we have hwprobe for this extension, we can further hook up this option to `VM_Version::ext_Zicntr`. And the user could still enable on command line before that. What do you think?
>
> As these instructions are unused, no need to enable them, I'm hesitant to add an NO-OP option.
> I figured that when we add uses fom them we can add that option, if needed.
> 
> Should I really add such dummy option?

Or simply remove this `VM_Version::ext_Zicntr.enabled()` check from the assert for now? We can add it back together with option `UseZicntr` when we have hwprobe for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23003#discussion_r1910183455

From kbarrett at openjdk.org  Fri Jan 10 10:45:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Jan 2025 10:45:47 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
Message-ID: <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>

On Fri, 10 Jan 2025 03:33:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I'm trying this new version, and I still get a few other warnings and then seem to have a process hang in lto1-ltrans. The switch from `-flto=auto` to `-flto=$(JOBS)` doesn't seem to have helped in that respect.

Turns out I didn't wait long enough.  It does terminate after about 40 minutes, though not successfully.  Instead the
build crashes with a failed assert:

#  Internal Error (../../src/hotspot/share/runtime/handles.inline.hpp:76), pid=4017588, tid=4017620
#  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?

I've not tried to debug this.  Maybe it's a consequence of one of those problems of bypassing an intentional implicit
noinline in our code (by ensuring a function definition is in a different TU from all callers), with LTO breaking that.
Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
by normal compilation).

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2582389338

From fyang at openjdk.org  Fri Jan 10 10:48:45 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Jan 2025 10:48:45 GMT
Subject: [jdk24] Integrated: 8346838: RISC-V:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crash with
 debug VMs
In-Reply-To: <iS5rhstmtYDqv5ndUWcW652k4zpugEKh0osXcwM6hOI=.a43e37ee-6e0b-49b2-852e-1e32337ab9bb@github.com>
References: <iS5rhstmtYDqv5ndUWcW652k4zpugEKh0osXcwM6hOI=.a43e37ee-6e0b-49b2-852e-1e32337ab9bb@github.com>
Message-ID: <2MiCOEYzMVCzG0isZOjUIo8sIUwgNIIeF_qEpOVqJfY=.892ca859-3543-440f-997a-b959ba1e0159@github.com>

On Tue, 7 Jan 2025 10:44:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi all,
> 
> Same issue is there in jdk24 repo.
> 
> This pull request contains a backport of commit [379ac349](https://github.com/openjdk/jdk/commit/379ac349d13e2c0c6986eb0787f33b9a7a2a3749) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Fei Yang on 7 Jan 2025 and was reviewed by Feilong Jiang and Robbin Ehn.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 92a4e234
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92a4e2346788c682c29a8dab3fe36f8c2a323732
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8346838: RISC-V: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crash with debug VMs

Reviewed-by: rehn
Backport-of: 379ac349d13e2c0c6986eb0787f33b9a7a2a3749

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

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

From aph at openjdk.org  Fri Jan 10 11:03:41 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 10 Jan 2025 11:03:41 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal
 code
In-Reply-To: <SnpFIORGv1jPZ1gP5LOUmmibfhIiFfWRdvQFF5s_J8M=.58ac474b-0a8c-4270-a15c-9d6b79138644@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
 <SnpFIORGv1jPZ1gP5LOUmmibfhIiFfWRdvQFF5s_J8M=.58ac474b-0a8c-4270-a15c-9d6b79138644@github.com>
Message-ID: <TbZwXHXdlKuNzMxWuModZltzqNfwemBxQxMtfCadFu8=.5abe18cd-6415-4e19-a8a5-58d4f871dc92@github.com>

On Fri, 10 Jan 2025 09:51:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Can you explain a bit more here? I think I get why would we want to rewrite `lea+ldr` to `slot_at`.
> 
> I do not quite understand why do we rewrite this one:
> 
> ```
> -    Address data_addr(mdo, md->byte_offset_of_slot(data, ReceiverTypeData::receiver_count_offset(i)));
> -    __ addptr(data_addr, DataLayout::counter_increment);
> +    __ addptr(slot_at(ReceiverTypeData::receiver_count_offset(i)),
> +              DataLayout::counter_increment);
> ```
> 
> Does it really optimize anything to rewrite it to `slot_at`? If so, shouldn't this one in the other hunk also get rewritten?

It's a safety in depth patch.
It's good practice always to check variable offsets in order to ensure that they are reachable. `addptr` has an embedded `form_address`, so this is not strictly necessary. It is, however, harmless.

> ```
>          Address data_addr(mdo, md->byte_offset_of_slot(data, VirtualCallData::receiver_count_offset(i)));
>           __ addptr(data_addr, DataLayout::counter_increment);
> ```

Yes, it should.

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

PR Comment: https://git.openjdk.org/jdk/pull/23012#issuecomment-2582431283

From rehn at openjdk.org  Fri Jan 10 11:04:42 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Jan 2025 11:04:42 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads
In-Reply-To: <vKWSxKhceZw84Vm3eNFdOLDE-jceb7b5_saEgEYxQfo=.7b9883a3-f75a-422f-a46f-de1ea8c68d3f@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <znCg8e_m5MrKlvSBFSM9eC-_n0DM-JlKA-m3ll5zubY=.876c4413-1d01-4e29-8b08-95ad2045191b@github.com>
 <aUfiIuOyL-K3w2D-NyYHSo5yQMH8LxbAzfqpqKbqAvE=.14ae35c7-9d03-4b0a-9287-f35630fa171d@github.com>
 <vKWSxKhceZw84Vm3eNFdOLDE-jceb7b5_saEgEYxQfo=.7b9883a3-f75a-422f-a46f-de1ea8c68d3f@github.com>
Message-ID: <p77-lECffw0ELPCjAYNZHAi3JXEB4VVbGR8We1COCa0=.45a4fc71-68f2-4ae6-b5be-52cd98de11d2@github.com>

On Fri, 10 Jan 2025 10:38:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> As these instructions are unused, no need to enable them, I'm hesitant to add an NO-OP option.
>> I figured that when we add uses fom them we can add that option, if needed.
>> 
>> Should I really add such dummy option?
>
> Or simply remove this `VM_Version::ext_Zicntr.enabled()` check from the assert for now? (It's a NO-OP too as it always returns false :-)) We can add it back together with option `UseZicntr` when we have hwprobe for this.

Ok!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23003#discussion_r1910214055

From rehn at openjdk.org  Fri Jan 10 11:42:15 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Jan 2025 11:42:15 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads [v2]
In-Reply-To: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
Message-ID: <ki3A7W2g6xuY-jNFQe4dw0AXfhHG0XJELgF7NChD8Vo=.c92fc0e5-585c-46e9-9a09-7b70a5489327@github.com>

> Hi, please consider.
> 
> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
> 
> If we need them before hwprobe we can add a flag for manually enabling them.
> 
> Sanity tested.
> 
> Thanks!

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23003/files
  - new: https://git.openjdk.org/jdk/pull/23003/files/f05fd1f9..d3d141a4

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

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

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

From fyang at openjdk.org  Fri Jan 10 11:50:46 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Jan 2025 11:50:46 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads [v2]
In-Reply-To: <ki3A7W2g6xuY-jNFQe4dw0AXfhHG0XJELgF7NChD8Vo=.c92fc0e5-585c-46e9-9a09-7b70a5489327@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <ki3A7W2g6xuY-jNFQe4dw0AXfhHG0XJELgF7NChD8Vo=.c92fc0e5-585c-46e9-9a09-7b70a5489327@github.com>
Message-ID: <fKYZTRKmRdPbuE-oHx9W2uPEts2d7DnchSiuTmr2osM=.d56aeb2e-13e7-48e5-8e65-d28babbafc7e@github.com>

On Fri, 10 Jan 2025 11:42:15 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
>> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
>> 
>> If we need them before hwprobe we can add a flag for manually enabling them.
>> 
>> Sanity tested.
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks for the update.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 52:

> 50: #include "runtime/sharedRuntime.hpp"
> 51: #include "runtime/stubRoutines.hpp"
> 52: #include "vm_version_riscv.hpp"

Do we still need this header then?

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23003#pullrequestreview-2542246223
PR Review Comment: https://git.openjdk.org/jdk/pull/23003#discussion_r1910266143

From rehn at openjdk.org  Fri Jan 10 11:59:10 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Jan 2025 11:59:10 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads [v3]
In-Reply-To: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
Message-ID: <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>

> Hi, please consider.
> 
> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
> 
> If we need them before hwprobe we can add a flag for manually enabling them.
> 
> Sanity tested.
> 
> Thanks!

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Remove header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23003/files
  - new: https://git.openjdk.org/jdk/pull/23003/files/d3d141a4..ad9c43ec

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

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

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

From fyang at openjdk.org  Fri Jan 10 11:59:10 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 10 Jan 2025 11:59:10 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads [v3]
In-Reply-To: <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>
Message-ID: <QjJ88qBBdGdXS-5VZ_CS_GfxyypK_wRE2wbVu4UM2DM=.c5f7c67f-7bec-4a22-a7ee-ce09a2a3ba6e@github.com>

On Fri, 10 Jan 2025 11:55:54 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
>> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
>> 
>> If we need them before hwprobe we can add a flag for manually enabling them.
>> 
>> Sanity tested.
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove header

Looks good.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23003#pullrequestreview-2542257229

From rehn at openjdk.org  Fri Jan 10 11:59:10 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Jan 2025 11:59:10 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads [v2]
In-Reply-To: <fKYZTRKmRdPbuE-oHx9W2uPEts2d7DnchSiuTmr2osM=.d56aeb2e-13e7-48e5-8e65-d28babbafc7e@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <ki3A7W2g6xuY-jNFQe4dw0AXfhHG0XJELgF7NChD8Vo=.c92fc0e5-585c-46e9-9a09-7b70a5489327@github.com>
 <fKYZTRKmRdPbuE-oHx9W2uPEts2d7DnchSiuTmr2osM=.d56aeb2e-13e7-48e5-8e65-d28babbafc7e@github.com>
Message-ID: <TK2eae-KLbQcJ2awvaLG2WavbgtZVs1qEDx560TSPjo=.fec3f65f-c68c-425d-811c-9a21f86bc7bc@github.com>

On Fri, 10 Jan 2025 11:47:48 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 52:
> 
>> 50: #include "runtime/sharedRuntime.hpp"
>> 51: #include "runtime/stubRoutines.hpp"
>> 52: #include "vm_version_riscv.hpp"
> 
> Do we still need this header then?

No, thanks, fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23003#discussion_r1910270785

From rehn at openjdk.org  Fri Jan 10 12:01:48 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 10 Jan 2025 12:01:48 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads [v3]
In-Reply-To: <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>
Message-ID: <zEUte85uLSGzTMRS83WA6-U9PLHP8jytNlfAfxH8tTQ=.f0a55cd6-177b-473a-995a-fec0b152b95c@github.com>

On Fri, 10 Jan 2025 11:59:10 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
>> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
>> 
>> If we need them before hwprobe we can add a flag for manually enabling them.
>> 
>> Sanity tested.
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove header

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/23003#issuecomment-2582542184

From aph at openjdk.org  Fri Jan 10 12:04:34 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 10 Jan 2025 12:04:34 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal
 code
In-Reply-To: <muvLByBEF7OcVJFpum0xSokmGoO5gRWFSOcsLoggiro=.0a371ecc-a05e-430c-886c-1eabda54a34f@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
 <muvLByBEF7OcVJFpum0xSokmGoO5gRWFSOcsLoggiro=.0a371ecc-a05e-430c-886c-1eabda54a34f@github.com>
Message-ID: <woAiBYsw5eYhnLQXC35Y_Vw8oSjkWJH4Zto9CYOPNzM=.8e6f0de3-27a8-4547-b929-a21c8014cbdc@github.com>

On Fri, 10 Jan 2025 09:54:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.
>> 
>> This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1384:
> 
>> 1382:     vtable_offset_in_bytes += vtable_index.as_constant() * wordSize;
>> 1383:     ldr(method_result,
>> 1384:         form_address(rscratch1, recv_klass, vtable_offset_in_bytes, LogBytesPerWord));
> 
> What is this change? Does not look equivalent to current code. Is this a bug fix?

It's just something I noticed while scanning all of the calls to form_address. The shift should match the operand size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23012#discussion_r1910283059

From aph at openjdk.org  Fri Jan 10 12:42:23 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 10 Jan 2025 12:42:23 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal
 code [v2]
In-Reply-To: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
Message-ID: <t5pUMo34G9wNor8JuSVzBZQBcwBOjq6t4SL4uDI8BYE=.0cc58040-5e72-4482-bfd5-8621c05cf9a0@github.com>

> Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.
> 
> This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Leave for later

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23012/files
  - new: https://git.openjdk.org/jdk/pull/23012/files/3b93519f..0e84904f

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

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

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

From aph at openjdk.org  Fri Jan 10 12:45:42 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 10 Jan 2025 12:45:42 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal
 code [v2]
In-Reply-To: <t5pUMo34G9wNor8JuSVzBZQBcwBOjq6t4SL4uDI8BYE=.0cc58040-5e72-4482-bfd5-8621c05cf9a0@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
 <t5pUMo34G9wNor8JuSVzBZQBcwBOjq6t4SL4uDI8BYE=.0cc58040-5e72-4482-bfd5-8621c05cf9a0@github.com>
Message-ID: <tqMJMDxTdDepNEB-fSk6VdAbgkpUhWOg0puuhTNVXyw=.fc1287e4-cb0f-4930-b7bb-2e641d5a9072@github.com>

On Fri, 10 Jan 2025 12:42:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.
>> 
>> This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leave for later

For clarity: every variable-sized load/store offset generated by C1 should be range-checked, and when it is out of range the load/store should be split. We already do this in C2. I'll wrap up any missing examples in a later patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/23012#issuecomment-2582625833

From ihse at openjdk.org  Fri Jan 10 12:54:43 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 10 Jan 2025 12:54:43 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
Message-ID: <QYePeOmRFnH3T3CIoQP8jcppjgh4kAGqZFavxO1tAzc=.096253a0-559b-4c6a-9e8e-f720e3435a59@github.com>

On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed jdk.internal package prefix from asm

I'm wondering about the build implications of this. This will move ASM from pre-compiled java classes in the JDK, into on-the-fly compiled classes in JTreg. I'm just back from vacation, so I have not had much time to look at this, but it does not seem as simple as "just move the files", and I'd like to get some more consideration about this change before it is pushed.

For instance, maybe we could rely on upstream ASM for the tests? I assume it gets distributed as a jar, that we could add as a dependency. (I guess that removing the `jdk.internal` prefix from the package name would be a pre-requisite for such a change, so that might also give the suggestion to this some more weight.)

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2582643101

From coleenp at openjdk.org  Fri Jan 10 12:57:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 12:57:51 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <r_LpVoELuStl0SNSzjpRLO2q9UxluZ0pbSb1zt6V1Z4=.1705d0d1-f485-46e8-a7b9-4eb75619a643@github.com>

On Sat, 4 Jan 2025 09:41:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> src/hotspot/share/oops/klass.cpp line 1308:
> 
>> 1306:   if (secondary_supers() != nullptr) {
>> 1307:     st->print("  - "); st->print("%d elements;", _secondary_supers->length());
>> 1308:     st->print_cr(" bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap);
> 
> Same as in instanceKlass - maybe this shouldn't be changed at all.

I restored this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1910340969

From coleenp at openjdk.org  Fri Jan 10 13:03:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 13:03:44 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <012w8uAs0fzFh52ycdTUSBLh0Kv-TgwiCSAdWA5sBDM=.16e4e1be-6fbe-4543-b565-499fd7c40f63@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
 <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
 <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>
 <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>
 <MBXafo0I882JS7AW3TRT-vZcUhr1Zwg_aiWeErvtma0=.8e867441-b738-4d9d-975c-a07e6934b316@github.com>
 <012w8uAs0fzFh52ycdTUSBLh0Kv-TgwiCSAdWA5sBDM=.16e4e1be-6fbe-4543-b565-499fd7c40f63@github.com>
Message-ID: <gu5jjSEtHWUDxpCCcn-aOndlvUBKQK-6QoBcYl9amMk=.205262d3-6cbf-4d39-a137-54648572ea57@github.com>

On Fri, 10 Jan 2025 07:15:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @coleenp The copyrights on the new files being 2024-2025 is intentional. They were first published (in this PR)
>> in 2024, so I think are supposed to have that starting year.
>
> @kimbarrett I understand. I also don't like the includer needing to know about this, and maybe it is time to add OS_FAMILY_HEADER to deal with it. But in the absence of the new macro I prefer this break of abstraction to the creation of a bunch of tiny forwarding files.

I prefer the opposite.  If you break these up into a bunch of forwarding files, do all the rest of the VM the same way.

It may be my problem but I don't have a good IDE to have to navigate through a slew of similarly named files to find the real implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1910347603

From aph at openjdk.org  Fri Jan 10 13:10:48 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 10 Jan 2025 13:10:48 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
Message-ID: <W6x-htemcgUrhZXpzllqxD8azf9eglIvLlgrlqQTxYs=.84f59b57-3a55-4363-997f-13aee029c21b@github.com>

On Thu, 9 Jan 2025 09:07:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

The commenting here is poor.

GHASH uses little-endian for the byte order, but big-endian for the bit order.  For example, the polynomial 1 is represented as the 16-byte string 80 00 00 00 | 12 bytes of 00. So, we must either reverse the bytes in each word and do everything big-endian or reverse the bits in each byte and do it little-endian. Which do you do?

Sure, I could figure it out by reading the code, but please say.

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

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2582675700

From ihse at openjdk.org  Fri Jan 10 13:11:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 10 Jan 2025 13:11:42 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <BKIb9kihzxnp1RWkICVITv98wEn7CD0e_ez11O1t2jU=.161b9b28-57d1-4f62-a832-d94d85e98c88@github.com>
 <tQo6COzCB1LHPUJwrsKlD2DZ7HPDeFJ8yPrYYJWGpqM=.757b5b06-4eff-444e-9b49-5ad3007d43c8@github.com>
 <WIiwVmb5YYwSZM_SfZ_U1xSKVzdRFDXcvHxNWbbsxhc=.5772dad9-3deb-41a4-80ef-76858f68dbc0@github.com>
Message-ID: <nl-9XnXNdKojzkdOpjparSzplqrOCwwsCbDqbPsDX-4=.64c55819-bf88-42c3-a5f3-2edc1a3f99e0@github.com>

On Fri, 10 Jan 2025 10:42:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Or maybe LTO is breaking us in some other way (such as taking advantage of no-UB constraints that aren't found
by normal compilation).

That seems definitely likely. With LTO the linker has a whole lot of room to try many exciting optimizations. I think it is more than likely that this can trigger some UB holes.

The question is: should we decouple "fixing LTO build" from "fixing a working LTO JVM"? I tend to think so; that the problem for the build system is to be able to build the product, and if it then crashes during use, it's the problem of the component owners instead. OTOH, this fix is relatively trivial, and if the JVM is DOA so we can't even finish the build, then maybe it makes no point to integrate it until that is fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2582678823

From duke at openjdk.org  Fri Jan 10 13:29:48 2025
From: duke at openjdk.org (duke)
Date: Fri, 10 Jan 2025 13:29:48 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v5]
In-Reply-To: <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
Message-ID: <3JLn86WueKwmXw1dAa55zg8daMP_hN6rtOOuiXCdGiQ=.c0fcf30a-4d06-43b7-ae01-158d7d0e2e51@github.com>

On Thu, 9 Jan 2025 20:48:21 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to force -XX:-UseZGC

@stooke 
Your change (at version 4574a2d00f365f4c77af3a719a23c237ee102fe8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22870#issuecomment-2582711707

From coleenp at openjdk.org  Fri Jan 10 13:32:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 13:32:40 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

I reviewed the template interpreter changes. They look great.

src/hotspot/cpu/x86/templateTable_x86.cpp line 330:

> 328: void TemplateTable::dconst(int value) {
> 329:   transition(vtos, dtos);
> 330:   if (UseSSE >= 2) {

I admit that I don't know what UseSSE is but now this is unconditional?  Is there a further cleanup necessary for this option?

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

PR Review: https://git.openjdk.org/jdk/pull/22567#pullrequestreview-2542434532
PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910374250

From shade at openjdk.org  Fri Jan 10 13:57:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 13:57:46 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
Message-ID: <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>

On Fri, 10 Jan 2025 13:23:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
>> 
>> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
>> 
>> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
>> 
>> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
>> 
>> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
>> 
>> x86_32 is the only platform that has special cases for x87 FPU.
>> 
>> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
>> 
>> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
>> 
>> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
>> 
>> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of...
>
> src/hotspot/cpu/x86/templateTable_x86.cpp line 330:
> 
>> 328: void TemplateTable::dconst(int value) {
>> 329:   transition(vtos, dtos);
>> 330:   if (UseSSE >= 2) {
> 
> I admit that I don't know what UseSSE is but now this is unconditional?  Is there a further cleanup necessary for this option?

Yes, now it is unconditional. x86_64 [requires](https://github.com/openjdk/jdk/blob/ec7393e9190c1b93ca08e1107f734c869f400b89/src/hotspot/cpu/x86/vm_version_x86.cpp#L896-L903) UseSSE >= 2. Only x86_32 cared about UseSSE < 2, so now we can eliminate these checks. I think I got the majority, if not all of the cases where these checks are now redundant: there are more in various assemblers and compiler code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910408581

From pchilanomate at openjdk.org  Fri Jan 10 15:29:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Jan 2025 15:29:47 GMT
Subject: [jdk24] RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
References: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
Message-ID: <hLidDqyoujg5apREhJ-M3cnyoA1vZ9-EiJgOqNJbh7E=.77f794f2-3345-4f01-b2d9-73307b12c8a5@github.com>

On Thu, 9 Jan 2025 14:18:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea495377](https://github.com/openjdk/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Patricio Chilano Mateo on 8 Jan 2025 and was reviewed by David Holmes, Alex Menkov and Serguei Spitsyn.
> 
> Thanks!

Thanks Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/23007#issuecomment-2582958425

From pchilanomate at openjdk.org  Fri Jan 10 15:29:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Jan 2025 15:29:47 GMT
Subject: [jdk24] Integrated: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
References: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
Message-ID: <lz6dxxgrPcsgMdzQ3G5mWx0JRvfl7KiYidnym4VYakI=.c98aeada-3e4d-4000-aa36-f9d5fdbbfa0d@github.com>

On Thu, 9 Jan 2025 14:18:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea495377](https://github.com/openjdk/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Patricio Chilano Mateo on 8 Jan 2025 and was reviewed by David Holmes, Alex Menkov and Serguei Spitsyn.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f0a89c5d
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0a89c5d8e00609db6a25b69dab04a1c955b23c5
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8310340: assert(_thread->is_interp_only_mode() || stub_caller) failed: expected a stub-caller

Reviewed-by: sspitsyn
Backport-of: ea49537726db6530f0ddcc04d9938df3d6d18250

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

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

From asotona at openjdk.org  Fri Jan 10 15:48:19 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Jan 2025 15:48:19 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v4]
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <bpaUM5pEpE_QcHQvs-8pCDgXlFpGvx1Yu5vxqlMbwio=.0e95ed42-ccd1-4054-ac54-5839321597c1@github.com>

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/Util.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22946/files
  - new: https://git.openjdk.org/jdk/pull/22946/files/13267e26..ac5063c9

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

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

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

From asotona at openjdk.org  Fri Jan 10 15:48:19 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Jan 2025 15:48:19 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
Message-ID: <OSq1YldrcO-ez-oInhrsS0fSPkIgw7-8pLq7wrHrzWo=.e0b0f360-7495-4338-88ff-e8213c382ab2@github.com>

On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed jdk.internal package prefix from asm

Thanks for the reviews. I'll update the copyright years and run again tier1 - 4 tests (just to be sure).

Jtreg seems to have no problems to use ASM as a declared library. This PR primary purpose is to remove the ASM from java.base.  Further improvements of hotspot tests using ASM can follow. However I would prefer to see further conversions of the hotspot tests to use Class-File API instead. Long-term goal is to remove ASM from JDK completely.

FYI: Regarding the merge of this PR I've been asked to wait until some downstream projects dependent on jdk.internal.objectweb.asm are fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2582985694

From asotona at openjdk.org  Fri Jan 10 16:04:41 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Jan 2025 16:04:41 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v5]
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <TNe4cX7av81QQKm1CuOJCUNxhK5VR-Dt4-z9XaTiR1M=.43e75430-6739-46c4-b432-eecbd23dc843@github.com>

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22946/files
  - new: https://git.openjdk.org/jdk/pull/22946/files/ac5063c9..98f90462

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

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

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

From asotona at openjdk.org  Fri Jan 10 16:12:54 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Jan 2025 16:12:54 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v6]
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <N1pN8y5dmQHODRQnB_qLwkc3euRUI5MFA9jc2vmjNYU=.d43b438d-74ae-4b6c-a699-073ded6e2344@github.com>

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22946/files
  - new: https://git.openjdk.org/jdk/pull/22946/files/98f90462..d3559630

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

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

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

From coleenp at openjdk.org  Fri Jan 10 16:24:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 16:24:47 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
Message-ID: <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>

On Fri, 10 Jan 2025 13:54:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/x86/templateTable_x86.cpp line 330:
>> 
>>> 328: void TemplateTable::dconst(int value) {
>>> 329:   transition(vtos, dtos);
>>> 330:   if (UseSSE >= 2) {
>> 
>> I admit that I don't know what UseSSE is but now this is unconditional?  Is there a further cleanup necessary for this option?
>
> Yes, now it is unconditional. x86_64 [requires](https://github.com/openjdk/jdk/blob/ec7393e9190c1b93ca08e1107f734c869f400b89/src/hotspot/cpu/x86/vm_version_x86.cpp#L896-L903) UseSSE >= 2. Only x86_32 cared about UseSSE < 2, so now we can eliminate these checks. I think I got the majority, if not all of the cases where these checks are now redundant: there are more in various assemblers and compiler code.

Maybe this should change from range (2,4) then.
  product(int, UseSSE, 4,                                                   \
          "Highest supported SSE instructions set on x86/x64")              \
          range(0, 4)                                                       \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910614336

From lmesnik at openjdk.org  Fri Jan 10 16:29:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 10 Jan 2025 16:29:46 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
Message-ID: <VnLtpEw7owhDPfS9IUJi6xVFRPSe1ZdiKsusTejjst0=.1fd7eced-88b9-4fec-922f-fcbdea61deb2@github.com>

On Fri, 10 Jan 2025 02:27:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak some assert messages

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22997#pullrequestreview-2542895372

From ihse at openjdk.org  Fri Jan 10 17:07:48 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 10 Jan 2025 17:07:48 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <OSq1YldrcO-ez-oInhrsS0fSPkIgw7-8pLq7wrHrzWo=.e0b0f360-7495-4338-88ff-e8213c382ab2@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
 <OSq1YldrcO-ez-oInhrsS0fSPkIgw7-8pLq7wrHrzWo=.e0b0f360-7495-4338-88ff-e8213c382ab2@github.com>
Message-ID: <lddN60zPLvVxA4GBgsq_ND3H7mJrBLqueEWFcTykWEo=.6629b01c-7eec-4927-aec0-8fff39dfe895@github.com>

On Fri, 10 Jan 2025 15:39:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Jtreg seems to have no problems to use ASM as a declared library.

Whan you say "no problems", I guess you are referring to the pass rate of the tests. But how does it affect the runtime spent doing testing?

I must insist that "just moving" code from `src` to `test` is not at all like moving code internally inside `src` or inside `test`, and that it is not at all an obviously trivial operation.

I understand that you want to remove ASM from the source base, and I do not object to that goal. I'm just saying that having tests that rely on code being present is basically just the same as having code in `src` relying on it, and that moving the entire source base to ASM is perhaps not the right way to deal with this remaining dependency.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2583277826

From ihse at openjdk.org  Fri Jan 10 17:17:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 10 Jan 2025 17:17:46 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <O_VOLucblf3jOEpsqa4f9s_eyW57wGm_5E9BMhHuGKc=.97f30eb1-3ba2-458f-9e2a-59fd1e9c44d5@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

Don't forget the 32-bit x86 classes under `src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot`. There might be other x86-specific code in other JDK libraries as well, and not just in Hotspot.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2583294294

From shade at openjdk.org  Fri Jan 10 17:38:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 17:38:55 GMT
Subject: RFR: 8337978: Verify OopHandles oops on access
Message-ID: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>

Detecting failures like [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941) would be more convenient if we verified the oops we put/get to/from `OopHandles`-s explicitly. This will stop the leakage of incorrect oops (e.g. bad Java klass mirrors seen in [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941)) to the runtime.

I was curious how this affects testing time, and I cannot see a big difference at least on `tier1`:


# Baseline
CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60427.40s user 4604.67s system 3775% cpu 28:42.39 total
CONF=linux-aarch64-server-fastdebug make test TEST=tier1  61364.50s user 4563.23s system 3806% cpu 28:52.20 total
CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60192.57s user 4610.89s system 3788% cpu 28:30.51 total

# With OopHandle verification
CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60410.88s user 4601.52s system 3740% cpu 28:58.20 total
CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60389.57s user 4572.23s system 3752% cpu 28:50.96 total
CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60845.41s user 4578.50s system 3757% cpu 29:01.08 total


Additional testing:
 - [x] Linux AArch64 server fastdebug, `tier1`
 - [ ] Linux AArch64 server fastdebug, `all`
 - [ ] Linux x86_64 server fastdebug, `all`

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

Commit messages:
 - Fix

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

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

From cjplummer at openjdk.org  Fri Jan 10 18:13:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 10 Jan 2025 18:13:45 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
Message-ID: <9EOC6fmFv6C-XLDA2Ac1q9G5TNxLlggrJiyzpf5dA3w=.cf03f3d1-ba15-4ab4-9668-62baa7aed90b@github.com>

On Fri, 10 Jan 2025 02:27:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak some assert messages

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

> 722:   void set_VTMS_transition_mark(bool val)        { Atomic::store(&_VTMS_transition_mark, val); }
> 723: 
> 724:   // Temporarily skip posting JVMTI events for safety reasons when executions is in ia critical section:

Suggestion:

  // Temporarily skip posting JVMTI events for safety reasons when execution is in a critical section:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1910796441

From shade at openjdk.org  Fri Jan 10 18:23:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 10 Jan 2025 18:23:49 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
Message-ID: <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>

On Fri, 10 Jan 2025 16:22:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, now it is unconditional. x86_64 [requires](https://github.com/openjdk/jdk/blob/ec7393e9190c1b93ca08e1107f734c869f400b89/src/hotspot/cpu/x86/vm_version_x86.cpp#L896-L903) UseSSE >= 2. Only x86_32 cared about UseSSE < 2, so now we can eliminate these checks. I think I got the majority, if not all of the cases where these checks are now redundant: there are more in various assemblers and compiler code.
>
> Maybe this should change from range (2,4) then.
>   product(int, UseSSE, 4,                                                   \
>           "Highest supported SSE instructions set on x86/x64")              \
>           range(0, 4)                                                       \

Right. Now that I am thinking more deeply about it, maybe that would be a first step here: lift UseSSE >= 2 for x86_32 ahead of this JEP, eliminate all UseSSE < 2 parts. I can see how intrusive this gets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910843574

From kbarrett at openjdk.org  Fri Jan 10 18:33:47 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Jan 2025 18:33:47 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
 <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
Message-ID: <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>

On Fri, 10 Jan 2025 18:21:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Maybe this should change from range (2,4) then.
>>   product(int, UseSSE, 4,                                                   \
>>           "Highest supported SSE instructions set on x86/x64")              \
>>           range(0, 4)                                                       \
>
> Right. Now that I am thinking more deeply about it, maybe that would be a first step here: lift UseSSE >= 2 for x86_32 ahead of this JEP, eliminate all UseSSE < 2 parts. I can see how intrusive this gets.

[not reviewing, just a drive-by comment] Does UseSSE < 2 provide a way to _avoid_ using relevant parts of
SSE on x86_64, perhaps for debugging?  Or does x86_64 effectively hard-wire UseSSE >= 2?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1910878630

From duke at openjdk.org  Fri Jan 10 19:18:44 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 10 Jan 2025 19:18:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
Message-ID: <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>

On Thu, 9 Jan 2025 14:27:56 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small fix to is_single_threaded and whitespace

Yes, good point. 
However, I think there is actually another problem: Threads may use NMT before `Threads::add` or `NonJavaThread::add_to_the_list()` is called. This means `is_single_threaded()` could erroneously return `true`, and the lock/asserts won't be used when they should be.

For JavaThreads:
In `attach_current_thread`, `create_stack_guard_pages()` and `register_thread_stack_with_NMT()` are called before `Threads::add`.

For NonJavaThreads:
In `Thread::call_run()`, `register_thread_stack_with_NMT()` is called before `NonJavaThread::pre_run()` which later calls `NonJavaThread::add_to_the_list()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2583681726

From vlivanov at openjdk.org  Fri Jan 10 20:28:49 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 10 Jan 2025 20:28:49 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
Message-ID: <e5dZJ-8ac5OI13uat___OEjV2_dm6318ZNAwyjcv07I=.80ba1613-c5fe-4fcf-a133-ffaf85792c2d@github.com>

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

Personally, I'd prefer to see initial x86-32 removal changeset as straighforward as possible: x86-32-specific files, plus (optionally) x86-32-specific code in x86-specific files.

IMO it's better to cover the rest (getting rid of unused features after x86-32 removal) as follow-up cleanups.

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

PR Comment: https://git.openjdk.org/jdk/pull/22567#issuecomment-2584013803

From kvn at openjdk.org  Fri Jan 10 20:28:49 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 10 Jan 2025 20:28:49 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
 <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
 <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>
Message-ID: <n1T3-oYkjfqOI26aGnecypZ_WE-bAAHLD9f7UTBxQ9Q=.ac3db5ba-06b9-4c1e-b871-361210d0cc38@github.com>

On Fri, 10 Jan 2025 18:30:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Right. Now that I am thinking more deeply about it, maybe that would be a first step here: lift UseSSE >= 2 for x86_32 ahead of this JEP, eliminate all UseSSE < 2 parts. I can see how intrusive this gets.
>
> [not reviewing, just a drive-by comment] Does UseSSE < 2 provide a way to _avoid_ using relevant parts of
> SSE on x86_64, perhaps for debugging?  Or does x86_64 effectively hard-wire UseSSE >= 2?

By default all 64-bits x86 CPU (starting from AMD64) supports all instructions up to SSE2. 32-bit x86 CPU may not support SSE2.

We can generated sse1 or use FPU instructions in 64-bit VM but we decided not to do that -  SSE2 instructions version were much easier to use. We purged all uses of FPU in JDK 15: [JDK-7175279](https://bugs.openjdk.org/browse/JDK-7175279) by using SSE set of instructions because we did not want to mess (save/restore state) with FPU anymore in 64-bit VM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1911258635

From kvn at openjdk.org  Fri Jan 10 20:33:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 10 Jan 2025 20:33:46 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <n1T3-oYkjfqOI26aGnecypZ_WE-bAAHLD9f7UTBxQ9Q=.ac3db5ba-06b9-4c1e-b871-361210d0cc38@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
 <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
 <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>
 <n1T3-oYkjfqOI26aGnecypZ_WE-bAAHLD9f7UTBxQ9Q=.ac3db5ba-06b9-4c1e-b871-361210d0cc38@github.com>
Message-ID: <L1phFk81yC2_neRh6doHpgXem1gI9o0WvZ11bK5uRLc=.ac76ed96-e35d-408c-befa-856742f2a2ad@github.com>

On Fri, 10 Jan 2025 20:23:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [not reviewing, just a drive-by comment] Does UseSSE < 2 provide a way to _avoid_ using relevant parts of
>> SSE on x86_64, perhaps for debugging?  Or does x86_64 effectively hard-wire UseSSE >= 2?
>
> By default all 64-bits x86 CPU (starting from AMD64) supports all instructions up to SSE2. 32-bit x86 CPU may not support SSE2.
> 
> We can generated sse1 or use FPU instructions in 64-bit VM but we decided not to do that -  SSE2 instructions version were much easier to use. We purged all uses of FPU in JDK 15: [JDK-7175279](https://bugs.openjdk.org/browse/JDK-7175279) by using SSE set of instructions because we did not want to mess (save/restore state) with FPU anymore in 64-bit VM.

I think there are several places in 64-bit VM where we assume SSE2 instructions are always available.
So if you set `UseSSE=1 or = 0` in debugger VM may crash.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1911279275

From coleenp at openjdk.org  Fri Jan 10 21:52:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 21:52:07 GMT
Subject: RFR: 8293123: Include of jvm.h breaks include block sort order
Message-ID: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>

There were only a couple of files that violated the alphabetical sort order, where jvm.h is sorted as j.
Testing with tier1 sanity.

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

Commit messages:
 - 8293123: Include of jvm.h breaks include block sort order

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

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

From mdoerr at openjdk.org  Fri Jan 10 23:08:44 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 10 Jan 2025 23:08:44 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <rSyVcKNjnifMg_TN6_eQe1xDPiFaY30A-7Klq1khJu4=.498caa84-c6b4-41d6-bd35-46793398d842@github.com>

On Wed, 25 Dec 2024 15:40:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

`sh make/scripts/update_copyright_year.sh` says "No files were changed". All changes in this PR were done in 2024, so Copyright year changes are only needed for files which are changed in 2025.

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

PR Comment: https://git.openjdk.org/jdk/pull/22881#issuecomment-2584710307

From sspitsyn at openjdk.org  Fri Jan 10 23:51:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 23:51:48 GMT
Subject: Integrated: 8346143: add ClearAllFramePops function to speedup
 debugger single stepping in some cases
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <rGoUVLP3JSCG9njmYMtxkFpDNCLsn6tmB-Cc4gKP8nI=.281469bf-d156-42f6-8377-b624a6b596e0@github.com>

On Fri, 13 Dec 2024 20:50:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

This pull request has now been integrated.

Changeset: 761774a1
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/761774a120f4aa326da3c55a000dacc5549762e9
Stats:     398 lines in 11 files changed: 362 ins; 12 del; 24 mod

8346143: add ClearAllFramePops function to speedup debugger single stepping in some cases

Reviewed-by: cjplummer, amenkov

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

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

From sspitsyn at openjdk.org  Sat Jan 11 06:01:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 06:01:33 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v4]
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: fixed a typo in new comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22997/files
  - new: https://git.openjdk.org/jdk/pull/22997/files/46527318..a85b5985

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

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

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

From sspitsyn at openjdk.org  Sat Jan 11 06:01:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 06:01:35 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
Message-ID: <ZwUc37p3sSJ83kI_SKymNgXiyo38X_QIBfYt7DaRptQ=.c294358c-1f03-4ff5-ad28-71c3bd83ea45@github.com>

On Fri, 10 Jan 2025 02:27:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak some assert messages

Leonid, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22997#issuecomment-2585098218

From sspitsyn at openjdk.org  Sat Jan 11 06:01:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 06:01:36 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <9EOC6fmFv6C-XLDA2Ac1q9G5TNxLlggrJiyzpf5dA3w=.cf03f3d1-ba15-4ab4-9668-62baa7aed90b@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
 <9EOC6fmFv6C-XLDA2Ac1q9G5TNxLlggrJiyzpf5dA3w=.cf03f3d1-ba15-4ab4-9668-62baa7aed90b@github.com>
Message-ID: <iFOnUG99PvEljDbvsWsmdv0S97-fqZITbExKZp7fiGY=.ddf787de-1a60-45dc-8794-30cc024085ba@github.com>

On Fri, 10 Jan 2025 18:10:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweak some assert messages
>
> src/hotspot/share/runtime/javaThread.hpp line 724:
> 
>> 722:   void set_VTMS_transition_mark(bool val)        { Atomic::store(&_VTMS_transition_mark, val); }
>> 723: 
>> 724:   // Temporarily skip posting JVMTI events for safety reasons when executions is in ia critical section:
> 
> Suggestion:
> 
>   // Temporarily skip posting JVMTI events for safety reasons when execution is in a critical section:

Thank you. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1911903539

From cjplummer at openjdk.org  Sat Jan 11 06:42:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 11 Jan 2025 06:42:35 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v4]
In-Reply-To: <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>
Message-ID: <zPkvJuM-pVt4qFesN8ZH5zi3ltspmu6T7SxPsxrLk30=.ecdfe208-60e1-4044-a6cd-a7388eef80d7@github.com>

On Sat, 11 Jan 2025 06:01:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: fixed a typo in new comment

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22997#pullrequestreview-2544580274

From sspitsyn at openjdk.org  Sat Jan 11 07:10:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 07:10:45 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v4]
In-Reply-To: <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>
Message-ID: <D81TPa_DzynhDl_LoM7j97KjO0_aa8Zoc3jiwuNpe0s=.66d2a74c-c1f8-4b7a-a8ba-4be23714fc75@github.com>

On Sat, 11 Jan 2025 06:01:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: fixed a typo in new comment

Thank you for review, Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/22997#issuecomment-2585126654

From sspitsyn at openjdk.org  Sat Jan 11 07:10:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 07:10:46 GMT
Subject: Integrated: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <hWT6ikGnGXJNKnHorByizPC7WXu-VxII1FSZBBhvxkg=.7e0cbb96-95c4-4b8f-bd07-387331df4a01@github.com>

On Thu, 9 Jan 2025 05:03:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

This pull request has now been integrated.

Changeset: 31452788
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3145278847428ad3a855a3e2c605b77f74ebe113
Stats:     57 lines in 2 files changed: 5 ins; 2 del; 50 mod

8346727: JvmtiVTMSTransitionDisabler deadlock

Reviewed-by: cjplummer, lmesnik

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

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

From kbarrett at openjdk.org  Sat Jan 11 14:11:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 11 Jan 2025 14:11:48 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <0T6dqXyqum7hEpCvg97-WsP_zVfOO9JkBCnze1f3sxE=.9b5c6ba1-9f58-4e74-bee8-5478809216cc@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2544851802

From coleenp at openjdk.org  Sat Jan 11 15:29:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 11 Jan 2025 15:29:48 GMT
Subject: RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port
In-Reply-To: <L1phFk81yC2_neRh6doHpgXem1gI9o0WvZ11bK5uRLc=.ac76ed96-e35d-408c-befa-856742f2a2ad@github.com>
References: <bpVKvXGIroa5l6ytgedtvYFRkzTp1GrQDLmaFSNuI3I=.982cd22c-ec21-4f0f-b9d0-b84bdf989ee7@github.com>
 <SlBfaG-OzFQm8J3XzYdpkjWHeRqDtWpqT8RIPTEVTzk=.4b055202-ffd8-46f7-8c19-e0d31c1b5817@github.com>
 <uD8qbz7f2uXkeOFJhThHl2w7Q8BOxP3I3jM9XqJVI5Y=.da0b4909-5743-40c7-8a45-2253d5a3af86@github.com>
 <jJPkLbugqps1zTdHtjNN-bcgPWiSifq2ZeIT1pFY5c4=.ac07713c-d240-444c-b527-34e17f1aa005@github.com>
 <njqSOIZwExXe2mvdI2Pu-9vHFAeqP59iejPNq7DiCqw=.ee244eb4-9c78-4892-992f-8b350c837cc0@github.com>
 <g59GnbsNQshHouZb5Ok699SXJUi9xBsGXA79X-ThM8A=.46dacc55-935c-4591-b28a-8675d843c0bf@github.com>
 <n1T3-oYkjfqOI26aGnecypZ_WE-bAAHLD9f7UTBxQ9Q=.ac3db5ba-06b9-4c1e-b871-361210d0cc38@github.com>
 <L1phFk81yC2_neRh6doHpgXem1gI9o0WvZ11bK5uRLc=.ac76ed96-e35d-408c-befa-856742f2a2ad@github.com>
Message-ID: <X2SBabT6-X1s2RECVr3P90h__wCsdYr_94Ni_fT3oyo=.1a5070cc-63fc-4b5c-830f-c1f2b2168c4c@github.com>

On Fri, 10 Jan 2025 20:30:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> By default all 64-bits x86 CPU (starting from AMD64) supports all instructions up to SSE2. 32-bit x86 CPU may not support SSE2.
>> 
>> We can generated sse1 or use FPU instructions in 64-bit VM but we decided not to do that -  SSE2 instructions version were much easier to use. We purged all uses of FPU in JDK 15: [JDK-7175279](https://bugs.openjdk.org/browse/JDK-7175279) by using SSE set of instructions because we did not want to mess (save/restore state) with FPU anymore in 64-bit VM.
>
> I think there are several places in 64-bit VM where we assume SSE2 instructions are always available.
> So if you set `UseSSE=1 or = 0` in debugger VM may crash.

Having some kind of pre-JEP patch for this this might be helpful so that we don't drill down on this rather than the whole patch.  Maybe the JEP patch could simply be what @iwanowww  suggests.  Then have a post-JEP patch to remove everything else.  Sort of like what we did with Security Manager.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1912067239

From iklam at openjdk.org  Sat Jan 11 19:23:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 11 Jan 2025 19:23:53 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v5]
In-Reply-To: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
Message-ID: <O62O1xMsS50vuykwbHP6veG22HE8AS7YY3P_TRGGuQ4=.98e117ea-7eb1-454b-841b-810e0b5c6e60@github.com>

> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
> 
> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
> 
> Note to reviewers:
> 
> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Updated copyright
 - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
 - @ashu-mehra comments
 - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8344140-consolidate-aot-artifact-gathering-discovery
 - Fixe 32-bit builds; removed unused function
 - more clean up
 - tmp
 - More clean up
 - Removed unnecessary code
 - ... and 1 more: https://git.openjdk.org/jdk/compare/31452788...e246276c

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

Changes: https://git.openjdk.org/jdk/pull/22291/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22291&range=04
  Stats: 1354 lines in 29 files changed: 560 ins; 678 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/22291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22291/head:pull/22291

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

From fjiang at openjdk.org  Sun Jan 12 03:03:40 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sun, 12 Jan 2025 03:03:40 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines
In-Reply-To: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
Message-ID: <urgmofCWWaM2L6ZIm9R5TiaBtEn5OUdnX59WbpJ-jDQ=.2a46915c-54c0-4cfe-9a8e-efb4e8cccc6a@github.com>

On Thu, 9 Jan 2025 14:38:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Please consider this small refactoring work.
> 
> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range as I find it is within 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where we can do `mv` and `andr` instead.
> 
> Testing on Premier P550 SBC:
> - [x] tier1-3 and gtest:all (release)
> - [x] hotspot:tier1 (fastdebug)

Looks more consistent now, thanks!

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

Marked as reviewed by fjiang (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23008#pullrequestreview-2545327024

From gcao at openjdk.org  Sun Jan 12 05:29:27 2025
From: gcao at openjdk.org (Gui Cao)
Date: Sun, 12 Jan 2025 05:29:27 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v9]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <dI-pXeXQsCJNyxDVlKVXgXcJoSobOfoxgGqMcoBPL-U=.2a4c5374-2b4b-44ca-a89b-f89cdebc9f38@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request incrementally with one additional commit since the last revision:

  Fix for Feilong's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21922/files
  - new: https://git.openjdk.org/jdk/pull/21922/files/82024b31..2d74b280

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=07-08

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

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

From gcao at openjdk.org  Sun Jan 12 05:29:27 2025
From: gcao at openjdk.org (Gui Cao)
Date: Sun, 12 Jan 2025 05:29:27 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v8]
In-Reply-To: <ZgcJc6BVMpWYRa1JstuYCd12DU3FOxO7BM9n2_S8kyY=.5fc80c0f-6400-4d4b-a516-1a2024bdd970@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <K4CWBLZiCvgiPHwY-JXbp3FJl4kc1rEeZBIolQfJvt4=.256ff38e-6b90-408f-b0a0-e8e6db184575@github.com>
 <ZgcJc6BVMpWYRa1JstuYCd12DU3FOxO7BM9n2_S8kyY=.5fc80c0f-6400-4d4b-a516-1a2024bdd970@github.com>
Message-ID: <JwfVp7S7jopnS40EGGdDWZTzlM30evrKS2miv43VVKI=.2c8b45b5-4ed3-4bd3-962b-1eeb73db3010@github.com>

On Sun, 12 Jan 2025 02:49:56 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> I think we should use `rorr` here.

Thanks so much, Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1912370762

From lmesnik at openjdk.org  Sun Jan 12 06:13:16 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 12 Jan 2025 06:13:16 GMT
Subject: RFR: 8338428: Print final VM flags for task
Message-ID: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>

Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.

I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".

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

Commit messages:
 - updated VMProps

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

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

From stuefe at openjdk.org  Sun Jan 12 08:48:44 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 12 Jan 2025 08:48:44 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
Message-ID: <ASFEErBM3DQ7JMDpoXWoGOq2F1s6mAN9kyPyEuqTNu4=.8bb909ac-710f-4d52-a108-ed3510bd8825@github.com>

On Fri, 10 Jan 2025 10:03:22 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified comment

I am playing around with this tree to replace the backing storage of the compilation memory statistics. Some notes:

Why does the tree _own_ the allocator? Why is its lifetime bound to the tree? This restricts the usefulness of an allocator. Two trees have two different allocator instances, but since we have no way of telling apart the caller tree instances in the allocator code, there is no point in that. We might just as well make the allocator AllStatic then and call via `ALLOCATOR::allocate`.

Consider this scenario: I want to have two short-lived trees, nodes live longer than their trees they temporarily occupy, and I want the nodes to reside in physically different preallocated pools. I want to use the same allocator and tree classes, though, so template parameters must be the same.

There are two ways to do this. The most obvious would be to keep a _reference_ to an allocator instance that the caller hands in via constructor. So, make `_allocator` a pointer, and if omitted by the caller use your own C-heap allocator. Otherwise, use the caller's allocator.

Another way would be to make the Allocator AllStatic and give each tree a caller-defined token (e.g. void*, think pthread_create), then hand this into all allocator functions. Tbh, the first variant sounds easier.

The node tree must also handle OOM because maybe I don't want to exit on OOM. An OOM from the node allocator itself may be a normal and expected behavior. 

Consider this example: I want to use nodes from a limited pre-allocated buffer, and I want to handle buffer OOM by, e.g., deleting the leftmost nodes and retrying. Maybe I want to keep the N largest "somethings" during a VM run within a limited buffer. In that case, an allocator OOM would be the most natural and understandable way to implement this. As the tree works now, we would need to predict and forestall an OOM by counting nodes *before* adding a new one. That is awkward and maybe not even possible if the allocator OOM is not easily predictable (think variable-sized nodes, or allocator fragmentation issues).

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

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2585643391

From stuefe at openjdk.org  Sun Jan 12 09:13:45 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 12 Jan 2025 09:13:45 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
Message-ID: <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>

On Fri, 10 Jan 2025 10:03:22 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified comment

Thinking about this some more, the fact that tree nodes are allocated internally and are separate entities from the key/value holders precludes the using this tree for memory management (address stable or not). It works, but the separate allocation defeats the purpose. It would be good if, on `upsert`, I could hand in optionally the future node memory itself, and the node should then be placed into/at the start of this memory. And it must be able to deal with the handed-in node memory be variable-sized, of course.

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

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2585651927

From fjiang at openjdk.org  Sun Jan 12 10:07:42 2025
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sun, 12 Jan 2025 10:07:42 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v9]
In-Reply-To: <dI-pXeXQsCJNyxDVlKVXgXcJoSobOfoxgGqMcoBPL-U=.2a4c5374-2b4b-44ca-a89b-f89cdebc9f38@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <dI-pXeXQsCJNyxDVlKVXgXcJoSobOfoxgGqMcoBPL-U=.2a4c5374-2b4b-44ca-a89b-f89cdebc9f38@github.com>
Message-ID: <yciR6khpbkfjQyTtvQd-b8g1iOROaaoapvnpVWz_VdI=.691e5112-ecd2-4a48-a231-0827feb0af90@github.com>

On Sun, 12 Jan 2025 05:29:27 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for Feilong's review

Marked as reviewed by fjiang (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21922#pullrequestreview-2545394373

From lmesnik at openjdk.org  Sun Jan 12 15:47:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 12 Jan 2025 15:47:15 GMT
Subject: RFR: 8338428: Print final VM flags for task [v2]
In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
Message-ID: <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>

> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
> 
> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
> 
> Update:
> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  The test lib is not ued

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23054/files
  - new: https://git.openjdk.org/jdk/pull/23054/files/6af3f1c6..919c870e

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

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

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

From stooke at openjdk.org  Sun Jan 12 21:42:41 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Sun, 12 Jan 2025 21:42:41 GMT
Subject: Integrated: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id"
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <l26xG9ppLBxmrNSlDevMUv7N1j3NxHI2cp6gXTo54HE=.4c2fd2a8-e786-448c-a3e4-3d2a19b45d02@github.com>

On Mon, 23 Dec 2024 18:43:07 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

This pull request has now been integrated.

Changeset: f04a6422
Author:    Simon Tooke <stooke at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f04a6422469709d22bd92bf5d00655f741956efd
Stats:     16 lines in 2 files changed: 13 ins; 0 del; 3 mod

8346717: serviceability/dcmd/vm/SystemDumpMapTest.java failing on Windows with "Stack base not yet set for thread id"

Reviewed-by: lmesnik, dholmes

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

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

From dholmes at openjdk.org  Mon Jan 13 02:30:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 02:30:46 GMT
Subject: RFR: 8293123: Include of jvm.h breaks include block sort order
In-Reply-To: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>
References: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>
Message-ID: <dB9ZWvfw3RcSTli1R8p18pB111AzIot6qc0qrAfvohg=.50f671bc-cee9-475c-a702-49cffa4a7f73@github.com>

On Fri, 10 Jan 2025 21:47:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There were only a couple of files that violated the alphabetical sort order, where jvm.h is sorted as j.
> Testing with tier1 sanity.

Some of these changes are not related to the listed JBS issue but I will leave it up to you if you want to broaden the scope of the issue to cover the more general out-of-order-include problem.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23048#pullrequestreview-2545612191

From dholmes at openjdk.org  Mon Jan 13 02:36:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 02:36:42 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v8]
In-Reply-To: <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
Message-ID: <Rnf5QA0fVfSbFACMVhUScaQdBim-N6R3QNgRYdhs8mU=.f29f6e61-990e-40ec-972b-65494bb6a494@github.com>

On Thu, 9 Jan 2025 22:07:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into new-poison
>  - Merge branch 'master' into new-poison
>  - remove more os-specific posix forwarding headers
>  - stefank whitespace suggestions
>  - add permit wrapper for strdup and use in aix
>  - remove os-specific posix forwarding headers
>  - aix permit patches
>  - more fixes for clang noreturn issues
>  - Merge branch 'master' into new-poison
>  - update copyrights
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/5e6fd8ba...6d49abbb

Nothing further from me.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22890#pullrequestreview-2545615287

From dholmes at openjdk.org  Mon Jan 13 02:36:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 02:36:43 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <gu5jjSEtHWUDxpCCcn-aOndlvUBKQK-6QoBcYl9amMk=.205262d3-6cbf-4d39-a137-54648572ea57@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
 <qFCjjDQQLU3E8XdRzmoWBgF-GzOxj4SFPssWlt2qv6c=.c0ea6112-9612-4641-af36-62facd956a8c@github.com>
 <fntDEzWPg1dpoBcY2DVX30-Hjrm5jzIx2ple7C1Urog=.f2ccc71c-e984-4d30-9600-3957492612a4@github.com>
 <PGZivoLhSwkreh7GIN2Gqq1nDE7WbtwHH-IZceWsCFM=.81171c3d-4299-4917-8455-fdc85eab7649@github.com>
 <8gxnsZYbqEJ7T3N637tjijrVbmQgbu8BrHHmVAjCt5M=.f98893f3-692a-4168-80f0-997f522ec4b0@github.com>
 <7w5uOtMR8ROpBIYdJHf4L44ANnxawhijM_iBCHpUtcI=.46e22653-732f-4edd-ad2f-c947d5928f6d@github.com>
 <haknCcMas6g5uBwl7l8jQtj9QcBbQEOyPWKtnPBjcm4=.00cb04e2-20e9-48f0-bd0b-e198d0df8c26@github.com>
 <MBXafo0I882JS7AW3TRT-vZcUhr1Zwg_aiWeErvtma0=.8e867441-b738-4d9d-975c-a07e6934b316@github.com>
 <012w8uAs0fzFh52ycdTUSBLh0Kv-TgwiCSAdWA5sBDM=.16e4e1be-6fbe-4543-b565-499fd7c40f63@github.com>
 <gu5jjSEtHWUDxpCCcn-aOndlvUBKQK-6QoB
 cYl9amMk=.205262d3-6cbf-4d39-a137-54648572ea57@github.com>
Message-ID: <-kyK-7ucrlR3C41y8P9m1FnG4TGZhPNEqWYdd0bWIT8=.e475314f-3b78-43a5-80ca-5e53bb100bf7@github.com>

On Fri, 10 Jan 2025 13:00:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> @kimbarrett I understand. I also don't like the includer needing to know about this, and maybe it is time to add OS_FAMILY_HEADER to deal with it. But in the absence of the new macro I prefer this break of abstraction to the creation of a bunch of tiny forwarding files.
>
> I prefer the opposite.  If you break these up into a bunch of forwarding files, do all the rest of the VM the same way.
> 
> It may be my problem but I don't have a good IDE to have to navigate through a slew of similarly named files to find the real implementation.

@coleenp I thought you and I were on the same page not liking the creation of all these little files that just forward to the posix one. ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1912608160

From dholmes at openjdk.org  Mon Jan 13 02:45:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 02:45:36 GMT
Subject: RFR: 8337978: Verify OopHandles oops on access
In-Reply-To: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>
References: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>
Message-ID: <8tiUnAs9279Yx4jdB8pBmKHdvI2LUEJE-KZC3uCX8Ec=.8ab7ab19-f604-456b-9fe2-7ec20b62d8ce@github.com>

On Fri, 10 Jan 2025 17:32:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Detecting failures like [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941) would be more convenient if we verified the oops we put/get to/from `OopHandles`-s explicitly. This will stop the leakage of incorrect oops (e.g. bad Java klass mirrors seen in [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941)) to the runtime.
> 
> I was curious how this affects testing time, and I cannot see a big difference at least on `tier1`:
> 
> 
> # Baseline
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60427.40s user 4604.67s system 3775% cpu 28:42.39 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  61364.50s user 4563.23s system 3806% cpu 28:52.20 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60192.57s user 4610.89s system 3788% cpu 28:30.51 total
> 
> # With OopHandle verification
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60410.88s user 4601.52s system 3740% cpu 28:58.20 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60389.57s user 4572.23s system 3752% cpu 28:50.96 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60845.41s user 4578.50s system 3757% cpu 29:01.08 total
> 
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `all`
>  - [ ] Linux x86_64 server fastdebug, `all`

Seems reasonable.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23043#pullrequestreview-2545619370

From dholmes at openjdk.org  Mon Jan 13 02:49:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 02:49:39 GMT
Subject: RFR: 8338428: Print final VM flags for task [v2]
In-Reply-To: <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
Message-ID: <bguxOEdIdVqArmqdWrfTh-1Gc0awW4y5VrNLb9lKo8w=.1f9f3af1-8465-468b-a498-529ae5233942@github.com>

On Sun, 12 Jan 2025 15:47:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The test lib is not ued

Does this mean that the execution of every single test must now first exec a new VM and use it to dump the flags?

And where does this output go?

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

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2586078059

From dholmes at openjdk.org  Mon Jan 13 02:58:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 02:58:41 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
Message-ID: <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>

On Fri, 10 Jan 2025 19:15:29 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> For JavaThreads:
In attach_current_thread, create_stack_guard_pages() and register_thread_stack_with_NMT() are called before Threads::add.

You can't attach to a VM until a certain point deep into initialization has been reached.

> For NonJavaThreads:
In Thread::call_run(), register_thread_stack_with_NMT() is called before NonJavaThread::pre_run() which later calls NonJavaThread::add_to_the_list().

Yes it is a problem that the created thread adds itself to the list.

So a simple solution would be to just use `Thread::number_of_threads() > 0` as the guard. That means we will skip the lock whilst it is unsafe to try and use it, then start using it once the main thread has "attached" even though it is not technically needed until there is another thread created.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2586086059

From dholmes at openjdk.org  Mon Jan 13 04:55:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 04:55:37 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v6]
In-Reply-To: <N1pN8y5dmQHODRQnB_qLwkc3euRUI5MFA9jc2vmjNYU=.d43b438d-74ae-4b6c-a699-073ded6e2344@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <N1pN8y5dmQHODRQnB_qLwkc3euRUI5MFA9jc2vmjNYU=.d43b438d-74ae-4b6c-a699-073ded6e2344@github.com>
Message-ID: <q0kziR0TCrOeU-iSkjpliAT9vmCf-D2NkZ1kMSkHfZE=.203d97a6-744b-4bf6-aaaf-ed1004b4ef17@github.com>

On Fri, 10 Jan 2025 16:12:54 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright years

Like @magicus  I am also having some doubts about the ability of jtreg to manage this. In particular the test/hotspot/jtreg/runtime/SelectionResolution/ tests. The testcases in these tests do not use ASM themselves, ASM is used by the selectionresolution/classes library that is also used by the tests. I'm not even clear how the library directives are making this work.

There is also the overhead as Magnus raised as we know jtreg does not handle compilation dependencies the way we would expect.

That said I'm okay with looking at using an ASM binary jar as a follow-up to this, provided we do not get a lot of failures triggered by this change. To that end I would want to see full tiers 1-8 testing carried out before this gets integrated.

Using an ASM jar could either be a downstream dependency as Magnus suggested, or we could pre-build into the test-image as part of Leonid's work in that area.

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

PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2545705480

From dholmes at openjdk.org  Mon Jan 13 05:05:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 05:05:49 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <z6KX0QT-sCHVU0qxP9FANjzknbPOXPi8X-wNzGqDZO4=.ebcb8ad4-f9e2-4d46-abff-e7aec4f3c8da@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Sorry for a "dumb" question but `%z` is for size_t arguments, so why are we using it to replace INTX/UINTX_FORMAT ??? I get that size_t and intx happen to be the same size but still ... if I see  `%z` I expect to see a size_t argument passed in.

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

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2545711471

From alanb at openjdk.org  Mon Jan 13 06:54:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Jan 2025 06:54:50 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v3]
In-Reply-To: <OSq1YldrcO-ez-oInhrsS0fSPkIgw7-8pLq7wrHrzWo=.e0b0f360-7495-4338-88ff-e8213c382ab2@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com>
 <OSq1YldrcO-ez-oInhrsS0fSPkIgw7-8pLq7wrHrzWo=.e0b0f360-7495-4338-88ff-e8213c382ab2@github.com>
Message-ID: <Quqx2d3yL2kNSk92c9J93punSyoo1m3XArqrHXI9dF4=.2b69e91d-eb8d-41fe-b904-788338063b7a@github.com>

On Fri, 10 Jan 2025 15:39:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed jdk.internal package prefix from asm
>
> Thanks for the reviews. I'll update the copyright years and run again tier1 - 4 tests (just to be sure).
> 
> Jtreg seems to have no problems to use ASM as a declared library. This PR primary purpose is to remove the ASM from java.base.  Further improvements of hotspot tests using ASM can follow. However I would prefer to see further conversions of the hotspot tests to use Class-File API instead. Long-term goal is to remove ASM from JDK completely.
> 
> FYI: Regarding the merge of this PR I've been asked to wait until some downstream projects dependent on jdk.internal.objectweb.asm are fixed.

@asotona Can you add to your list to move src/java.base/share/legal/asm.md so that it's not included in the JDK build.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586328809

From lmesnik at openjdk.org  Mon Jan 13 07:03:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 13 Jan 2025 07:03:39 GMT
Subject: RFR: 8338428: Print final VM flags for task [v2]
In-Reply-To: <bguxOEdIdVqArmqdWrfTh-1Gc0awW4y5VrNLb9lKo8w=.1f9f3af1-8465-468b-a498-529ae5233942@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
 <bguxOEdIdVqArmqdWrfTh-1Gc0awW4y5VrNLb9lKo8w=.1f9f3af1-8465-468b-a498-529ae5233942@github.com>
Message-ID: <NghmxLOdqMxaDh_9Yr7ZqKxJXn6ws_QE7X4l_zv4W8U=.321044c3-7b9d-45a1-849c-c2ff0843fc01@github.com>

On Mon, 13 Jan 2025 02:46:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Does this mean that the execution of every single test must now first exec a new VM and use it to dump the flags?
> 
Yes, you are correct. If it looks like a problem, it could be added by requires with java property. So it could be off by default and switched on only when needed.
> And where does this output go?
The  jvm.flags.final.log will be located in the scratch directory near with vmprops.log.

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

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2586338903

From dholmes at openjdk.org  Mon Jan 13 07:20:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 07:20:40 GMT
Subject: RFR: 8326236: assert(ce != nullptr) failed in
 Continuation::continuation_bottom_sender
In-Reply-To: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>
References: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>
Message-ID: <Q4uJtAJoHRkX984SEVmro3znMXvAJ0EbfxEMvBU0bfk=.5e9f7629-7b62-4c6e-bfbc-643e8d782138@github.com>

On Thu, 9 Jan 2025 19:48:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method frame::safe_for_sender() we could read a sender_pc that matches StubRoutines::cont_returnBarrier() but there is no actual continuation in the stack. I added more details in the bug comments on how we can get into this situation. The extra check verifies there is a ContinuationEntry further up in the stack. I run the patch through mach5 tiers 1-2 for sanity testing and tiers 6-7.
> 
> Thanks,
> Patricio

Based on the analysis this seems quite reasonable.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23017#pullrequestreview-2545870840

From stuefe at openjdk.org  Mon Jan 13 07:35:42 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Jan 2025 07:35:42 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
Message-ID: <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>

On Sun, 12 Jan 2025 09:08:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Thinking about this some more, the fact that tree nodes are allocated internally and are separate entities from the key/value holders precludes the using this tree for memory management (address stable or not). It works, but the separate allocation defeats the purpose. It would be good if, on `upsert`, I could hand in optionally the future node memory itself, and the node should then be placed into/at the start of this memory. And it must be able to deal with the handed-in node memory be variable-sized, of course.

Or, much simpler, let me construct the node itself and hand it into the tree.

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

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2586392855

From asotona at openjdk.org  Mon Jan 13 07:40:06 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 Jan 2025 07:40:06 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v7]
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <KrOIzTniMCePXpcViUh-_CxrCWB5Bu52-JUGvJ6b9_M=.7be79892-b749-4d0a-bb68-187b8846571a@github.com>

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed asm.md

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22946/files
  - new: https://git.openjdk.org/jdk/pull/22946/files/d3559630..72ed71d6

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

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

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

From stuefe at openjdk.org  Mon Jan 13 07:42:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Jan 2025 07:42:53 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
Message-ID: <zE0jVVKb2TKAXnNtW3OLYacDLqz2SUYcd5LmhW7xEZw=.c9ef823d-cbac-417d-b89a-7774a73f7c9a@github.com>

On Thu, 9 Jan 2025 14:27:56 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small fix to is_single_threaded and whitespace

Do we still think using hotspot Mutexes is a good goal? As opposed to Roberts's original attempt of using a non-asserting platform mutex? What do people think? I myself am not so sure anymore.

We get deadlock prevention but also get brittle at initialization.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2586403297

From asotona at openjdk.org  Mon Jan 13 07:54:41 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 Jan 2025 07:54:41 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v7]
In-Reply-To: <KrOIzTniMCePXpcViUh-_CxrCWB5Bu52-JUGvJ6b9_M=.7be79892-b749-4d0a-bb68-187b8846571a@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <KrOIzTniMCePXpcViUh-_CxrCWB5Bu52-JUGvJ6b9_M=.7be79892-b749-4d0a-bb68-187b8846571a@github.com>
Message-ID: <S2xjouErZhaPJNk4g7npss6YsrQiCTswCQ_t8ygFhqk=.ab0dadba-bb7a-4b9b-a03d-6ec0cad75333@github.com>

On Mon, 13 Jan 2025 07:40:06 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed asm.md

Across JDK tests I see two tests use @library pointing to compiled jars, however in both cases the jars are a part of the tests source tree. Is there a way to pre-compile a test library and point related tests (or maybe all hotspot tests) to the library jar?

FYI: I've triggered full tiers 1 - 8 testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586419903

From alanb at openjdk.org  Mon Jan 13 08:01:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Jan 2025 08:01:43 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v7]
In-Reply-To: <KrOIzTniMCePXpcViUh-_CxrCWB5Bu52-JUGvJ6b9_M=.7be79892-b749-4d0a-bb68-187b8846571a@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <KrOIzTniMCePXpcViUh-_CxrCWB5Bu52-JUGvJ6b9_M=.7be79892-b749-4d0a-bb68-187b8846571a@github.com>
Message-ID: <PeVHFzelBXKGxNL_CO_ebFxwW6AMK3-szom1N-4FpVM=.8c695321-5b1f-4e62-8a28-9040bc68cd30@github.com>

On Mon, 13 Jan 2025 07:40:06 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed asm.md

I see you've removed asm.md in 72ed71d but I assume it should move to the test tree. skynet.md and acvp.md are two examples to look at.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586429925

From asotona at openjdk.org  Mon Jan 13 08:14:08 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 Jan 2025 08:14:08 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v8]
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  moved asm.md to the testlibrary/asm

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22946/files
  - new: https://git.openjdk.org/jdk/pull/22946/files/72ed71d6..92b93fc5

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

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

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

From asotona at openjdk.org  Mon Jan 13 08:14:08 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 Jan 2025 08:14:08 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v7]
In-Reply-To: <KrOIzTniMCePXpcViUh-_CxrCWB5Bu52-JUGvJ6b9_M=.7be79892-b749-4d0a-bb68-187b8846571a@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <KrOIzTniMCePXpcViUh-_CxrCWB5Bu52-JUGvJ6b9_M=.7be79892-b749-4d0a-bb68-187b8846571a@github.com>
Message-ID: <wL110KibLTcoFq13lGmarpx3QjlT9cAlB-kKyvXJNkI=.aa907ff1-c1fe-4a47-aec1-f05c2e9e9679@github.com>

On Mon, 13 Jan 2025 07:40:06 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed asm.md

> I see you've removed asm.md in [72ed71d](https://github.com/openjdk/jdk/commit/72ed71d6bcc570b600ac7c591e7b6d69a3bf2559) but I assume it should move to the test tree. skynet.md and acvp.md are two examples to look at.

Oh, right, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586440763

From jbhateja at openjdk.org  Mon Jan 13 09:06:12 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 13 Jan 2025 09:06:12 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v10]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <XXiawoYZ_cVsSFEIuuTq-LZNZLPmvNz3MaWVN2mbCbA=.d3a55936-5121-461b-b6b7-671aabc10030@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/175f4ed2..43aa3eb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=08-09

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

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

From jbhateja at openjdk.org  Mon Jan 13 09:06:13 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 13 Jan 2025 09:06:13 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
 <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
Message-ID: <88_pE_E7P1iOkpSUuLuou6wH9UxWvPx83MFo033dY2Y=.d942086a-e87f-45dd-8c1d-72b8fd9c85d6@github.com>

On Thu, 9 Jan 2025 13:13:30 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Updating copyright year of modified files.
>
> src/hotspot/share/opto/superword.cpp line 2567:
> 
>> 2565:     // half float to float, in such a case back propagation of narrow type (SHORT)
>> 2566:     // may not be possible.
>> 2567:     if (n->Opcode() == Op_ConvF2HF || n->Opcode() == Op_ReinterpretHF2S) {
> 
> Is this relevant, or does that belong to a different (vector) RFE?

It makes sure to assign a SHORT container type to the ReinterpretHF2S node which could be succeeded by a ConvHF2F IR which expects its inputs to be of SHORT type. During early phase of SLP extraction we get into a control flow querying the implemented vector IR opcode through split_packs_only_implemented_with_smaller_size
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectornode.cpp#L1446
 
This scenario is tested by following JTREG
[test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java](https://github.com/openjdk/jdk/pull/22754/files#diff-7e7404a977d8ca567f8005b80bd840ea2e722c022e7187fa2dd21df4a5837faaR49)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1912858395

From jbhateja at openjdk.org  Mon Jan 13 09:06:14 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 13 Jan 2025 09:06:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <zX9mex0SPUb8umMa8uRwPvj9nsKwzoOqNio0CF8xPrA=.1c82220b-e200-4654-a67e-7ffbcf7a3bdb@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
 <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
 <zX9mex0SPUb8umMa8uRwPvj9nsKwzoOqNio0CF8xPrA=.1c82220b-e200-4654-a67e-7ffbcf7a3bdb@github.com>
Message-ID: <j0cnWHdkWhJSs8CvM6EbIQpPld66a-mRHKbXKl-cOZw=.edc40acc-c892-4e46-8bbf-b6205336ecad@github.com>

On Thu, 9 Jan 2025 19:22:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1434:
>> 
>>> 1432:                     return float16ToRawShortBits(valueOf(product + float16ToFloat(f16c)));
>>> 1433:                 });
>>> 1434:         return shortBitsToFloat16(res);
>> 
>> I don't understand what is happening here. But I leave this to @PaulSandoz to review
>
> Uncertain on what bits, but i am guessing it's mostly related to the fallback code in the lambda. To avoid the intrinsics operating on Float16 instances we instead "unpack" the carrier (16bits) values and pass those as arguments to the intrinsic. The fallback (when intrinsification is not supported) also accepts those carrier values as arguments and we convert the carriers to floats, operate on then, convert to the carrier, and then back to float16 on the result.
> 
> The code in the lambda could potentially be simplified if `Float16Math.fma` accepted six arguments the first three being the carrier values used by the intrinsic, and the subsequent three being the float16 values used by the fallback. Then we could express the code in the original source in the lambda. I believe when intrinsified there would be no penalty for those extra arguments.

Hi @PaulSandoz , In the current scheme we are passing unboxed carriers to intrinsic entry point, in the fallback implementation carrier type is first converted to floating point value using Float.float16ToFloat API which expects to receive a short type argument,  after the operation we again convert float value to carrier type (short) using Float.floatToFloat16 API which expects a float argument,  thus our intent here is to perform unboxing and boxing outside the intrinsic thereby avoiding all complexities around boxing by compiler. Even if we pass 3 additional parameters we still need to use Float16.floatValue which invokes Float.float16ToFloat underneath, thus this minor modification on Java side is on account of optimizing the intrinsic interface.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1912858286

From ihse at openjdk.org  Mon Jan 13 12:20:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 13 Jan 2025 12:20:44 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v7]
In-Reply-To: <S2xjouErZhaPJNk4g7npss6YsrQiCTswCQ_t8ygFhqk=.ab0dadba-bb7a-4b9b-a03d-6ec0cad75333@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <KrOIzTniMCePXpcViUh-_CxrCWB5Bu52-JUGvJ6b9_M=.7be79892-b749-4d0a-bb68-187b8846571a@github.com>
 <S2xjouErZhaPJNk4g7npss6YsrQiCTswCQ_t8ygFhqk=.ab0dadba-bb7a-4b9b-a03d-6ec0cad75333@github.com>
Message-ID: <aYv-2-AXLtn1r8riGviqTFvi4qeBrPpaKgDHAzJV7iQ=.9dd08434-f7aa-4d5b-8e6e-d2e1a31c2d4d@github.com>

On Mon, 13 Jan 2025 07:52:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Is there a way to pre-compile a test library and point related tests (or maybe all hotspot tests) to the library jar?

My initial thought was just to add the jar to the classpath, but maybe it is better to use an explicit `@library` tag. I guess we need to check how jtreg works, if it is possible to have it look for libraries outside the test root. Maybe we can send in an additional path in which to look for libraries as an argument. (Or maybe jtreg can be fixed to accept such a path.)

If that works, then the build system can provide the "glue" to accept in an argument to configure pointing out the ASM jar, and then pass it on to jtreg.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586954447

From stefank at openjdk.org  Mon Jan 13 12:54:36 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 Jan 2025 12:54:36 GMT
Subject: RFR: 8293123: Include of jvm.h breaks include block sort order
In-Reply-To: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>
References: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>
Message-ID: <3FnC4PX-6_FtwhK8tkDXve6hPL0TVm0E2w_vhHEjyCU=.a88c793a-0f60-4cc5-a4c8-5c2487a645a8@github.com>

On Fri, 10 Jan 2025 21:47:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There were only a couple of files that violated the alphabetical sort order, where jvm.h is sorted as j.
> Testing with tier1 sanity.

Looks good (after David's comment about the title). Thanks for fixing!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23048#pullrequestreview-2546531627

From jsjolen at openjdk.org  Mon Jan 13 13:02:42 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 13 Jan 2025 13:02:42 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
 <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
Message-ID: <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>

On Mon, 13 Jan 2025 07:33:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Thinking about this some more, the fact that tree nodes are allocated internally and are separate entities from the key/value holders precludes the using this tree for memory management (address stable or not). It works, but the separate allocation defeats the purpose. It would be good if, on `upsert`, I could hand in optionally the future node memory itself, and the node should then be placed into/at the start of this memory. And it must be able to deal with the handed-in node memory be variable-sized, of course.
>
>> Thinking about this some more, the fact that tree nodes are allocated internally and are separate entities from the key/value holders precludes the using this tree for memory management (address stable or not). It works, but the separate allocation defeats the purpose. It would be good if, on `upsert`, I could hand in optionally the future node memory itself, and the node should then be placed into/at the start of this memory. And it must be able to deal with the handed-in node memory be variable-sized, of course.
> 
> Or, much simpler, let me construct the node itself and hand it into the tree.

Hi @tstuefe ,

>Consider this scenario: I want to have two short-lived trees, nodes live longer than their trees they temporarily occupy, and I want the nodes to reside in physically different preallocated pools. I want to use the same allocator and tree classes, though, so template parameters must be the same.

>There are two ways to do this. The most obvious would be to keep a reference to an allocator instance that the caller hands in via constructor. So, make _allocator a pointer, and if omitted by the caller use your own C-heap allocator. Otherwise, use the caller's allocator.

Or you have a reference as the template type and you alter the constructor of the `RBTree` to take such a type to construct its own allocator with.

It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.

I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes. You could also, for example, avoid the cost of freeing separate elements and eliminate the whole tree at once when the lifetime of the tree has ended (since the lifetime of the allocator is identical). In short: When your tree isn't intrusive, it's very nice to have a custom allocator.

For your use case, you basically need a very similar addition to the API. It'd look something like this in pseudo-code:

```c++
// I hold the data, but the node holds the key
struct IntrusiveHolder {
  int data;
  RBNode node;
  static IntrusiveHolder* cast_to_self(RBNode* node) ; // offset_of() magic
};

struct Compare {
  int cmp(int a, int b);
}

template<typename K, typename V, typename Cmp, typename Allocator>
struct RBTree{
public:
  enum Dir { left, right };
  // Describes the parent node and whether the next node is to be inserted on the left or the right.
  struct InsertionCursor {
   RBNode* parent; Dir dir;
   RBNode* position(); // Get the node (potentially nullptr)
  };

  // Walks the tree in the obvious order, using Comparator::cmp overload to find the place to insert.
  // However does not allocate.
  InsertionCursor find_insertion_point(K k);
  // Inserts the node at the position and rebalances the tree.
  void insert_at_cursor(InsertionCursor, RBNode* node);

  // For removals we need to unlink the node from the tree, but keep it alive and then just return the pointer.
  RBNode* remove(K k);
};

// An intrusive RBTree doesn't store any V, and it should not use a custom allocator.
struct Empty{};
struct NoopAlloc {
  void* allocate(size_t sz) {
    assert(false, "no");
    return nullptr;
  }
  void free(void* ptr) {
    assert(false, "no");
    return;
  }
};
template<typename K, typename Cmp>
using IntrusiveRBTree = RBTree<K, Empty, Cmp, NoopAlloc>;

void insert_and_then_remove(IntrusiveRBTree<int, Compare>& tree, int key, int data) {
  InsertionCursor cursor = tree.find_insertion_point(key);
  if (cursor.position() != nullptr) {
    IntrusiveHolder::cast_to_self(cursor.position())->data = data;
  } else {
    // Our custom allocation scheme is just malloc here
    IntrusiveHolder* place = os::malloc(sizeof(IntrusiveHolder), mtTest);
    new (place) IntrusiveHolder(data, RBNode());
    tree.insert_at_cursor(cursor, key, place->node);
  }
  
  RBNode* node = tree.remove(key);
  if (node != nullptr) {
    os::free(IntrusiveHolder::cast_to_self(node)); // Find the outer structure which malloc knows how to free.
  }
}


We could also change the comparator so that it takes `(RBNode*, RBNode*)`, then the key can also be stored in the `IntrusiveHolder` and we can make `K = Empty`. The details on that are slightly fuzzy.

Casper already is working on supporting an intrusive RBTree with an API similar to what I sketched out above, but I'd like it if we can integrate the current version of the tree as it is. With this change we can already remove the NMT Treap and replace it, so that's a nice use case. Plus, there'll always be new features, we can't wait with integration until all possible features are implemented :).

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

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2587043371

From coleenp at openjdk.org  Mon Jan 13 13:12:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 13:12:57 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v8]
In-Reply-To: <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
Message-ID: <0werdci3K7vyrFZq2vjxDyVRQf5u6_2_mfwriae1Ds8=.c74f077e-7325-454a-b611-684db9f5b583@github.com>

On Thu, 9 Jan 2025 22:07:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into new-poison
>  - Merge branch 'master' into new-poison
>  - remove more os-specific posix forwarding headers
>  - stefank whitespace suggestions
>  - add permit wrapper for strdup and use in aix
>  - remove os-specific posix forwarding headers
>  - aix permit patches
>  - more fixes for clang noreturn issues
>  - Merge branch 'master' into new-poison
>  - update copyrights
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/3c60d213...6d49abbb

This looks good for me too.  I think you should allow GHA to run for this change.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22890#pullrequestreview-2546569987

From coleenp at openjdk.org  Mon Jan 13 13:16:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 13:16:38 GMT
Subject: RFR: 8293123: Fix various include file ordering
In-Reply-To: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>
References: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>
Message-ID: <n9kZ6ZQOwDpp8lM0rMG7n07uVmG8M9iW311WG5x-Pq8=.20ff45a9-8766-472d-acf1-c7aab683395f@github.com>

On Fri, 10 Jan 2025 21:47:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There were only a couple of files that violated the alphabetical sort order, where jvm.h is sorted as j.
> Testing with tier1 sanity.

Thanks for reviewing Stefan and David.  I changed the title.

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

PR Comment: https://git.openjdk.org/jdk/pull/23048#issuecomment-2587073072

From coleenp at openjdk.org  Mon Jan 13 13:16:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 13:16:38 GMT
Subject: Integrated: 8293123: Fix various include file ordering
In-Reply-To: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>
References: <bVQadyKypb_h5exA2JXk6eCOc94nCgs19DgTbfH0M3U=.251767be-8038-4631-9447-91e50f196aaa@github.com>
Message-ID: <z-dFIdjQ97aCFPCONJZj-DzIXQZ0G60l1gwtv9VUPis=.f67cee6a-67d0-46c9-8f05-fc4dde49e170@github.com>

On Fri, 10 Jan 2025 21:47:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There were only a couple of files that violated the alphabetical sort order, where jvm.h is sorted as j.
> Testing with tier1 sanity.

This pull request has now been integrated.

Changeset: cc198972
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc198972022c94199d698461e2ac42afc0058fd7
Stats:     23 lines in 7 files changed: 8 ins; 8 del; 7 mod

8293123: Fix various include file ordering

Reviewed-by: dholmes, stefank

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

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

From asotona at openjdk.org  Mon Jan 13 13:26:45 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 Jan 2025 13:26:45 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v8]
In-Reply-To: <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
Message-ID: <k4EuI5xh93eCMI53JhgVMYo-ImGAsPg7MAb6Tux3v80=.86f9b459-bd6b-4084-8a37-9f1db4675113@github.com>

On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved asm.md to the testlibrary/asm

I did some manual benchmarking and created two sets of 100 no-op Jtreg tests. The first set references compiled j.l.classfile.ClassModel and the second set references org.objectweb.asm.ClassWriter declared as a @library.
The difference in execution of the tests is ~3 seconds on my computer (~30ms per test).

Given the limited number of tests affected, I would estimate that the overall performance regression will be in the single digit seconds range.

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2587096026

From coleenp at openjdk.org  Mon Jan 13 13:29:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 13:29:45 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <HDHz6YY_yMee4MQtLcxHM-k_h7wyG2x3Y0aDtPSizjA=.f328bf5f-b5d7-444a-b7d5-e8dacdad2fcb@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

They are interchangeable and some places  used UINTX_FORMAT when they should have used SIZE_FORMAT.
Better to have just one and just use %zu, which looks better in the format specifiers. I'm going to do SIZE_FORMAT next but still negotiating how to handle review tedium.

The error message can be confusing though because the error message for %z refers to size_t.   But some of our use of intx should probably be size_t.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2587101349

From adinn at openjdk.org  Mon Jan 13 13:34:15 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 13 Jan 2025 13:34:15 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v10]
In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
Message-ID: <DtvZPYfGhFyBmPSEGbRJ-G4O14_sTAptlnsYnX5nHiM=.af9edbdd-1367-4ad5-8402-aba748a5a2bf@github.com>

> Implementation of JDK-8343767

Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:

 - correct errors in stubgen blob sizes
 - merge
 - increase compiler stub space for macos x86_64
 - adjust x86 blob sizes to allow for relocated stubs
 - fix issue with x86 avx3 array copy
 - Merge branch 'master' into iterate_stubs
 - fix element sizes in s390 copy routines
 - fix stub is and align flags for s390
 - fix comments and remove unused stubid on riscv
 - locate super lookup stubs in same blob for all arches
 - ... and 50 more: https://git.openjdk.org/jdk/compare/1ef77cdd...2bc580ce

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

Changes: https://git.openjdk.org/jdk/pull/21957/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=09
  Stats: 6950 lines in 57 files changed: 4066 ins; 1533 del; 1351 mod
  Patch: https://git.openjdk.org/jdk/pull/21957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957

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

From adinn at openjdk.org  Mon Jan 13 13:54:45 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 13 Jan 2025 13:54:45 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <kBUMTZM_oooYkibxwKfTJ7kvEqmIemr0ir0DSSQWi9s=.4bae0b8c-54be-4467-a1c6-60560b8fdcd9@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
 <kBUMTZM_oooYkibxwKfTJ7kvEqmIemr0ir0DSSQWi9s=.4bae0b8c-54be-4467-a1c6-60560b8fdcd9@github.com>
Message-ID: <XBjAqYPHWr15lHZuQAL55qC98y4XD-qUEbZoDuvKaXI=.4ac1c4c2-9a44-4f2c-92c0-07183b9ef654@github.com>

On Tue, 3 Dec 2024 02:45:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   increase compiler stub space for macos x86_64
>
> Looks good. 
> 
> Testing results (hs-tier1 - hs-tier4) are clean.

@iwanowww I pinned down the problem with the MacOS x86_64 tests. It happens in the StringIndexOf test because we have UseAVX == 2 && EnableX86CoreOpts=true. The latter flag controls generation of the string_indexof_linear_ll/ul/uu stubs. I can reproduce the same error on my x86 corei7 box if I set EnableX86CoreOpts=true. The stubs add over 10000 bytes to the compiler stub blob -- without them there is only 8000 to spare. I have tweaked up the compiler blob sizing slightly (under LP64_ONLY) to allow room for them.

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

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2587161084

From adinn at openjdk.org  Mon Jan 13 13:58:52 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 13 Jan 2025 13:58:52 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <kILFdiUs-nQLzJaCs0J18D3ue9eTLZsFcW2fIUE1uyA=.4798b477-18e8-41bc-aea5-88a7dc3266d8@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
 <kILFdiUs-nQLzJaCs0J18D3ue9eTLZsFcW2fIUE1uyA=.4798b477-18e8-41bc-aea5-88a7dc3266d8@github.com>
Message-ID: <IWlATKRlRs1zm1hRnqQWAtho4zPuizw7EuhkSGyH3-M=.a5f1276f-acc8-4924-a526-d1c91e4544ec@github.com>

On Wed, 4 Dec 2024 20:52:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   increase compiler stub space for macos x86_64
>
> I think I found the problem on PPC64: `TEST_FILL` should only run when `OptimizeFill` is enabled. Note that this feature is unsupported on PPC64.
> In addition, feel free to remove `zero_words_aligned8` completely. It's dead code.

@TheRealMDoerr Thanks for running the ppc tests and pinning down the array fill issue. I am not fully clear what the problem and associated solution is. Does the runtime stubs test need modifying so that it only runs `TEST_FILL` when `OptimizeFill` is set? Or is it a question of bypassing the test using a config option?

I will happily remove `zero_words_aligned8` before pushing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2587171114

From mdoerr at openjdk.org  Mon Jan 13 14:01:53 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Jan 2025 14:01:53 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <kILFdiUs-nQLzJaCs0J18D3ue9eTLZsFcW2fIUE1uyA=.4798b477-18e8-41bc-aea5-88a7dc3266d8@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
 <kILFdiUs-nQLzJaCs0J18D3ue9eTLZsFcW2fIUE1uyA=.4798b477-18e8-41bc-aea5-88a7dc3266d8@github.com>
Message-ID: <3xxvywdFYdXjT9GFCEY1SoWTKyTk7WDzUeInWlIOPag=.238b78d6-eda3-484b-8a03-db915af0e2b0@github.com>

On Wed, 4 Dec 2024 20:52:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   increase compiler stub space for macos x86_64
>
> I think I found the problem on PPC64: `TEST_FILL` should only run when `OptimizeFill` is enabled. Note that this feature is unsupported on PPC64.
> In addition, feel free to remove `zero_words_aligned8` completely. It's dead code.

> @TheRealMDoerr Thanks for running the ppc tests and pinning down the array fill issue. I am not fully clear what the problem and associated solution is.

The stubs are not generated because `OptimizeFill` is forced off on PPC64.

> Does the runtime stubs test need modifying so that it only runs `TEST_FILL` when `OptimizeFill` is set?

That sounds like the right solution to me.

> I will happily remove `zero_words_aligned8` before pushing.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2587179596

From kbarrett at openjdk.org  Mon Jan 13 15:23:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 15:23:45 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v8]
In-Reply-To: <0werdci3K7vyrFZq2vjxDyVRQf5u6_2_mfwriae1Ds8=.c74f077e-7325-454a-b611-684db9f5b583@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
 <0werdci3K7vyrFZq2vjxDyVRQf5u6_2_mfwriae1Ds8=.c74f077e-7325-454a-b611-684db9f5b583@github.com>
Message-ID: <AgkOOwWHezfaeEYCkunUCbL7jA0DuFBV3rJsQHk2Ic0=.46a879d2-871f-4595-9707-ddac0fb5f52a@github.com>

On Mon, 13 Jan 2025 13:09:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks good for me too. I think you should allow GHA to run for this change.

I ran GHA tests on at least one early version, but I'll do another run before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2587404905

From galder at openjdk.org  Mon Jan 13 15:37:44 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 13 Jan 2025 15:37:44 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
Message-ID: <lSZElVvEoVt9hni2dr_X6MYUiqWcq84omtpv71m_sPc=.5c077608-64fb-4754-a779-1feebed7be18@github.com>

On Thu, 9 Jan 2025 12:18:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`)
>
> @galderz So you want me to review again?

@eme64 Yes please

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2587450313

From galder at openjdk.org  Mon Jan 13 15:45:46 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 13 Jan 2025 15:45:46 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
Message-ID: <JRSWMFhwMOAvKq08ovoKZCOOBj3oSk4TeNHdRhH4GXY=.9e704453-469a-4e0c-a627-0eac0a8ba9a5@github.com>

On Thu, 9 Jan 2025 12:18:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`)
>
> @galderz So you want me to review again?

@eme64 I've noticed some failures in CI, I'll check those and ping you when it's ready for a review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2587472207

From coleenp at openjdk.org  Mon Jan 13 15:49:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 15:49:15 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

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

  Add Oracle copyright to shenandoah files for this change.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/ae9d9f6f..763c3908

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

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

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

From ihse at openjdk.org  Mon Jan 13 16:04:51 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 13 Jan 2025 16:04:51 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v8]
In-Reply-To: <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
Message-ID: <929j76hroJpqOdYZuJWij42cPeWBNXfYTOdQLqhCSqY=.4ab4ada8-b556-42f7-9f93-742b9cd68bbd@github.com>

On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved asm.md to the testlibrary/asm

In that case I have no more objections for the build part of this PR.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2547103022

From duke at openjdk.org  Mon Jan 13 16:39:46 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 13 Jan 2025 16:39:46 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <zE0jVVKb2TKAXnNtW3OLYacDLqz2SUYcd5LmhW7xEZw=.c9ef823d-cbac-417d-b89a-7774a73f7c9a@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <zE0jVVKb2TKAXnNtW3OLYacDLqz2SUYcd5LmhW7xEZw=.c9ef823d-cbac-417d-b89a-7774a73f7c9a@github.com>
Message-ID: <rClbYbW97ffmPAQRTuwm28NuPgKIAGpuMZYfl_eEM-o=.d8f30ad5-e145-45cb-a896-76657c343a59@github.com>

On Mon, 13 Jan 2025 07:40:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small fix to is_single_threaded and whitespace
>
> Do we still think using hotspot Mutexes is a good goal? As opposed to Roberts's original attempt of using a non-asserting platform mutex? What do people think? I myself am not so sure anymore.
> 
> We get deadlock prevention but also get brittle at initialization.

@tstuefe 
> Do we still think using hotspot Mutexes is a good goal? As opposed to Roberts's original attempt of using a non-asserting platform mutex? What do people think? I myself am not so sure anymore.
We get deadlock prevention but also get brittle at initialization.

Being brittle at initialization is unfortunate, and there is also the point @kimbarrett mentions about this [only working with VM threads](https://github.com/openjdk/jdk/pull/22745#discussion_r1894657610). I am not exactly sure what the best choice is here, but I do think deadlock detection is very nice since the NMT locking is quite broad in scope. I believe, in most cases, we lock around both the NMT accounting and the actual memory operation.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2587616074

From psandoz at openjdk.org  Mon Jan 13 16:53:45 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 13 Jan 2025 16:53:45 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <j0cnWHdkWhJSs8CvM6EbIQpPld66a-mRHKbXKl-cOZw=.edc40acc-c892-4e46-8bbf-b6205336ecad@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
 <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
 <zX9mex0SPUb8umMa8uRwPvj9nsKwzoOqNio0CF8xPrA=.1c82220b-e200-4654-a67e-7ffbcf7a3bdb@github.com>
 <j0cnWHdkWhJSs8CvM6EbIQpPld66a-mRHKbXKl-cOZw=.edc40acc-c892-4e46-8bbf-b6205336ecad@github.com>
Message-ID: <dwyK1YzhzuD35JrKaxQdjACVH6-BgEQZCdvclQKhra4=.27cd66d0-b881-435e-b369-1c081e6a4444@github.com>

On Mon, 13 Jan 2025 09:02:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Uncertain on what bits, but i am guessing it's mostly related to the fallback code in the lambda. To avoid the intrinsics operating on Float16 instances we instead "unpack" the carrier (16bits) values and pass those as arguments to the intrinsic. The fallback (when intrinsification is not supported) also accepts those carrier values as arguments and we convert the carriers to floats, operate on then, convert to the carrier, and then back to float16 on the result.
>> 
>> The code in the lambda could potentially be simplified if `Float16Math.fma` accepted six arguments the first three being the carrier values used by the intrinsic, and the subsequent three being the float16 values used by the fallback. Then we could express the code in the original source in the lambda. I believe when intrinsified there would be no penalty for those extra arguments.
>
> Hi @PaulSandoz , In the current scheme we are passing unboxed carriers to intrinsic entry point, in the fallback implementation carrier type is first converted to floating point value using Float.float16ToFloat API which expects to receive a short type argument,  after the operation we again convert float value to carrier type (short) using Float.floatToFloat16 API which expects a float argument,  thus our intent here is to perform unboxing and boxing outside the intrinsic thereby avoiding all complexities around boxing by compiler. Even if we pass 3 additional parameters we still need to use Float16.floatValue which invokes Float.float16ToFloat underneath, thus this minor modification on Java side is on account of optimizing the intrinsic interface.

Yes, i understand the approach. It's about clarity of the fallback implementation retaining what was expressed in the original code:

        short res = Float16Math.fma(fa, fb, fc, a, b, c,
                (a_, b_, c_) -> {
                    double product = (double)(a_.floatValue() * b._floatValue());
                    return valueOf(product + c_.doubleValue());
                });

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1913502565

From kbarrett at openjdk.org  Mon Jan 13 16:54:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 16:54:53 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <DCTXOr09_AWxG0ET1DP5q5n8B6TN29PM4_Cj6DGHB6o=.b4cedcdd-90c7-4fff-a100-aa49761c5e41@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Still good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2547230951

From lmesnik at openjdk.org  Mon Jan 13 16:57:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 13 Jan 2025 16:57:48 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v8]
In-Reply-To: <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
Message-ID: <KKwQ6xZxzMgmQ-AKrwAsrLn4rNsmV6pua4cIfQr4AX4=.6bf8e370-494c-411f-9cbd-9c5725353658@github.com>

On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved asm.md to the testlibrary/asm

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2547237930

From galder at openjdk.org  Mon Jan 13 17:12:31 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Mon, 13 Jan 2025 17:12:31 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v9]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:

  Make sure it runs with cpus with either avx512 or asimd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/c0491987..abbaf875

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=07-08

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

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

From duke at openjdk.org  Mon Jan 13 17:49:27 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 13 Jan 2025 17:49:27 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v16]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <aeAn4lTnQ5cJeSkbU6olE07bYeZzSfILzCfg96k3P_U=.6523a762-c243-4ddc-85f8-9688a2580994@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  fix concurrency bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/6e7bf186..3fbacd6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=14-15

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

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

From kbarrett at openjdk.org  Mon Jan 13 18:28:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 18:28:48 GMT
Subject: Integrated: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <Xtz79LNg95K1zHEGSJXizcveRGJEc0dK-NW5zeMxAIo=.14c5fe0f-e8e9-4487-87ac-3fe4bf6cfcce@github.com>

On Sun, 29 Dec 2024 08:11:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

This pull request has now been integrated.

Changeset: e0f2f4b2
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e0f2f4b216bc9358caa65975204aee086e4fcbd2
Stats:     592 lines in 32 files changed: 415 ins; 64 del; 113 mod

8313396: Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: coleenp, dholmes, jsjolen

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

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

From kbarrett at openjdk.org  Mon Jan 13 18:28:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 18:28:46 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v8]
In-Reply-To: <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
Message-ID: <z3fAyIkOFmso5g7H0KCbftirfrphE0TZ_ORfw1Uwx8Q=.2a0ccf8e-fb5b-44c5-92ee-91cb116e9d93@github.com>

On Thu, 9 Jan 2025 22:07:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into new-poison
>  - Merge branch 'master' into new-poison
>  - remove more os-specific posix forwarding headers
>  - stefank whitespace suggestions
>  - add permit wrapper for strdup and use in aix
>  - remove os-specific posix forwarding headers
>  - aix permit patches
>  - more fixes for clang noreturn issues
>  - Merge branch 'master' into new-poison
>  - update copyrights
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/f7e23973...6d49abbb

Thanks for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2587889007

From coleenp at openjdk.org  Mon Jan 13 18:52:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 18:52:56 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier
Message-ID: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>

Please review this change that replaces SSIZE_FORMAT with %zd.
Tested with tier1 on Oracle supported platforms (and here with GHA).

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

Commit messages:
 - 8347566: Replace SSIZE_FORMAT with 'z' length modifier

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

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

From dlong at openjdk.org  Mon Jan 13 19:35:43 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 13 Jan 2025 19:35:43 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier
In-Reply-To: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
Message-ID: <hVCY58k48zW-5o8GQh2jj62FYPNOXHiGV7EcL0_Yn8M=.90ba6845-ad87-450e-9f3f-43df3fd433b5@github.com>

On Mon, 13 Jan 2025 18:47:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change that replaces SSIZE_FORMAT with %zd.
> Tested with tier1 on Oracle supported platforms (and here with GHA).

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 160:

> 158:   uintx free_bits = mutator_bits | collector_bits | old_collector_bits;
> 159:   uintx notfree_bits =  ~free_bits;
> 160:   log_debug(gc)("%6zu : " SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0,

Why is this %6zu instead of %6zd?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23084#discussion_r1913708708

From coleenp at openjdk.org  Mon Jan 13 20:39:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 20:39:53 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
Message-ID: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>

> Please review this change that replaces SSIZE_FORMAT with %zd.
> Tested with tier1 on Oracle supported platforms (and here with GHA).

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

  Fix one zu -> zd.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23084/files
  - new: https://git.openjdk.org/jdk/pull/23084/files/1cf9c88e..011ab8d2

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

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

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

From coleenp at openjdk.org  Mon Jan 13 20:39:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 20:39:53 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <hVCY58k48zW-5o8GQh2jj62FYPNOXHiGV7EcL0_Yn8M=.90ba6845-ad87-450e-9f3f-43df3fd433b5@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <hVCY58k48zW-5o8GQh2jj62FYPNOXHiGV7EcL0_Yn8M=.90ba6845-ad87-450e-9f3f-43df3fd433b5@github.com>
Message-ID: <HdJtYLqVu4VM84WRo132ZbnYFL38qWpoOn-jh2flklY=.dccec54b-1e74-4a97-abc4-2affce9a0755@github.com>

On Mon, 13 Jan 2025 19:32:06 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix one zu -> zd.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 160:
> 
>> 158:   uintx free_bits = mutator_bits | collector_bits | old_collector_bits;
>> 159:   uintx notfree_bits =  ~free_bits;
>> 160:   log_debug(gc)("%6zu : " SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0 " 0x" SIZE_FORMAT_X_0,
> 
> Why is this %6zu instead of %6zd?

I must have done this one by hand.  Thank you for spotting it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23084#discussion_r1913773820

From dlong at openjdk.org  Mon Jan 13 20:44:40 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 13 Jan 2025 20:44:40 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <GnHSd3B0aTvgBFz_ouq9tGgRY19JZG7iuM1yZeXhPiE=.26a8ae55-d052-4d74-bd33-84fd84f782b6@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23084#pullrequestreview-2547837099

From duke at openjdk.org  Mon Jan 13 20:56:47 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 13 Jan 2025 20:56:47 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
 <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>
Message-ID: <bRN_qDUZQ_a4iGZaze7HWIPY4IZ94AjA4Hj-6XZyGSI=.35ae15f4-3ffb-46ef-b608-ff3cf4fcc846@github.com>

On Mon, 13 Jan 2025 02:56:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So a simple solution would be to just use Thread::number_of_threads() > 0 as the guard. That means we will skip the lock whilst it is unsafe to try and use it, then start using it once the main thread has "attached" even though it is not technically needed until there is another thread created.

Hi @dholmes-ora, I think it would still be problem that NonJavaThreads (such as `WatcherThread` and `AsyncLogWriter`) may use NMT before main_thread is "attached" and detectable with `Thread::number_of_threads()`. 

Both JavaThreads and NonJavaThreads can use NMT before being detectable by `Thread::number_of_threads()` or `NonJavaThread::end()`. Threads also use NMT after `Threads::remove` or `NonJavaThread::remove_from_the_list()` is called.  So it seems that even checking both `Thread::number_of_threads()` and `NonJavaThread::end()` doesn't reliably tell us whether the lock needs to be taken.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2588176443

From dholmes at openjdk.org  Mon Jan 13 21:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 21:07:44 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <9iKSUKvDXxUoqoAxOYVEqzUGmf2PQwDLy_MfbFABs88=.30a14b62-a21e-4a6e-bf32-31454689a33f@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2547892700

From dholmes at openjdk.org  Mon Jan 13 21:10:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 21:10:42 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v8]
In-Reply-To: <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
Message-ID: <XgT1s7rOz3JqjslYbiglxmcS8iwWV8sTLdp09n3hHdM=.7734a837-a547-4573-a27b-3beda8226cca@github.com>

On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved asm.md to the testlibrary/asm

Okay lets give this a whirl and see how it goes.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2547901035

From dholmes at openjdk.org  Mon Jan 13 21:24:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 21:24:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <bRN_qDUZQ_a4iGZaze7HWIPY4IZ94AjA4Hj-6XZyGSI=.35ae15f4-3ffb-46ef-b608-ff3cf4fcc846@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
 <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>
 <bRN_qDUZQ_a4iGZaze7HWIPY4IZ94AjA4Hj-6XZyGSI=.35ae15f4-3ffb-46ef-b608-ff3cf4fcc846@github.com>
Message-ID: <SqAh3fJ9CvLSSH_HnhENLsRCeStQsQ2Lzmvr8Meqr7I=.1885ea66-cf29-498e-9594-24afd0c5beaa@github.com>

On Mon, 13 Jan 2025 20:53:32 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> I think it would still be problem that NonJavaThreads (such as WatcherThread and AsyncLogWriter) may use NMT before main_thread is "attached" 

Sorry yes of course that is how we started on this current round - the WatcherThread is created before the main thread is "attached". <sigh>

I need to rewind a few steps and see exactly what it is we need to be initialized before this lock can be used ...

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2588242206

From ccheung at openjdk.org  Mon Jan 13 21:36:50 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 13 Jan 2025 21:36:50 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v5]
In-Reply-To: <O62O1xMsS50vuykwbHP6veG22HE8AS7YY3P_TRGGuQ4=.98e117ea-7eb1-454b-841b-810e0b5c6e60@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <O62O1xMsS50vuykwbHP6veG22HE8AS7YY3P_TRGGuQ4=.98e117ea-7eb1-454b-841b-810e0b5c6e60@github.com>
Message-ID: <ArfJSrqUmevHBVnB2fLa7NHDLzYn0sJyOk7JqDeR4xs=.bf92cd58-67b8-4065-99bc-086ab8459748@github.com>

On Sat, 11 Jan 2025 19:23:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
>> 
>> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
>> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
>> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
>> 
>> Note to reviewers:
>> 
>> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Updated copyright
>  - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
>  - @ashu-mehra comments
>  - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8344140-consolidate-aot-artifact-gathering-discovery
>  - Fixe 32-bit builds; removed unused function
>  - more clean up
>  - tmp
>  - More clean up
>  - Removed unnecessary code
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/31452788...e246276c

Some minor comments below.

src/hotspot/share/cds/aotArtifactFinder.hpp line 71:

> 69: // Note1: See TODO comments in HeapShared::archive_object() for exceptions to this rule.
> 70: //
> 71: // Note2: The scanning of Java objects is done in heapShared.cpp. Please see calls into the HeapShared class

Note2 isn't referenced by the comment above. Perhaps line 62 should reference it?

src/hotspot/share/cds/heapShared.cpp line 320:

> 318:     if (k->is_instance_klass()) {
> 319:       // Whenever we see a non-array Java object of type X, we mark X to be aot-initialized.
> 320:       // This ensures that during the production run, whenever Java code seens a cached object

typo: s/seens/sees

src/hotspot/share/cds/heapShared.cpp line 327:

> 325:         // we must store them as AOT-initialized.
> 326:         AOTArtifactFinder::add_aot_inited_class(InstanceKlass::cast(k));
> 327:       } else if (subgraph_info == _dump_time_special_subgraph) {

Can this be an "or" condition rather than "else if" since the same function is called for either on of the conditions?

src/hotspot/share/cds/heapShared.cpp line 784:

> 782: 
> 783:   if (orig_k->is_instance_klass()) {
> 784:     InstanceKlass* ik = InstanceKlass::cast(orig_k);

Should this be inside a "#if ASSERT" since `ik` is used only in the `assert` statements?

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

PR Review: https://git.openjdk.org/jdk/pull/22291#pullrequestreview-2547949837
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1913827272
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1913828722
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1913830983
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1913833806

From coleenp at openjdk.org  Mon Jan 13 22:02:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 22:02:36 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <dxeMy5zlOeZkj14vDUWM3AaErUk5hkFVIy7H6hKZKRs=.d6bfc8ce-ada3-42bf-9204-02738bb45005@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Thanks Dean.

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

PR Comment: https://git.openjdk.org/jdk/pull/23084#issuecomment-2588311136

From coleenp at openjdk.org  Mon Jan 13 22:06:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 22:06:49 GMT
Subject: Integrated: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <VmPON0_Nu8ZAN4fnn9hVsqXUld7G0_30HXd3mMO2Qc0=.47ab2394-eab0-4aea-9cd4-a68efb95e5c2@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

This pull request has now been integrated.

Changeset: 379d05bc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/379d05bcc130446086786ecf6ca5a6b8e977386c
Stats:     344 lines in 83 files changed: 6 ins; 19 del; 319 mod

8346990: Remove INTX_FORMAT and UINTX_FORMAT macros

Reviewed-by: kbarrett, dholmes, matsaave

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

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

From coleenp at openjdk.org  Mon Jan 13 22:06:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 22:06:48 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <etmswFtqnPXNzddiLOqeIxwK6Qk-Z0oi6ldpjTB1icQ=.bc830122-dddb-4c0c-964a-f0d2a4116535@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Thank you Matias, Kim and David.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2588312123

From duke at openjdk.org  Mon Jan 13 22:18:44 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 13 Jan 2025 22:18:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <SqAh3fJ9CvLSSH_HnhENLsRCeStQsQ2Lzmvr8Meqr7I=.1885ea66-cf29-498e-9594-24afd0c5beaa@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
 <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>
 <bRN_qDUZQ_a4iGZaze7HWIPY4IZ94AjA4Hj-6XZyGSI=.35ae15f4-3ffb-46ef-b608-ff3cf4fcc846@github.com>
 <SqAh3fJ9CvLSSH_HnhENLsRCeStQsQ2Lzmvr8Meqr7I=.1885ea66-cf29-498e-9594-24afd0c5beaa@github.com>
Message-ID: <Gtc3-Qb3m0UWUg-q4d7kHoGdXo_2Fnj6ij22dqnwuxw=.ec1625c2-63c4-4207-a877-f03b71ba032f@github.com>

On Mon, 13 Jan 2025 21:21:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>I need to rewind a few steps and see exactly what it is we need to be initialized before this lock can be used

Before `NmtVirtualMemoryLocker` can be used, Hotspot mutexes must be initialized (`vm_init_globals()`) and `main_thread->initialize_thread_current()` must be called.  This happens relatively early in `create_vm`.

Hmmm I'm not sure anymore if introducing `is_single_threaded()` is the best approach.  [The original intention](https://github.com/openjdk/jdk/pull/22745#issuecomment-2574379871) was to avoid introducing yet another initialization-progress marker by pivoting from the old approach of setting `Mutex::is_bootstrapping_done()` as soon as it is safe to use `NmtVirtualMemoryLocker` . The downside I've discovered is that there doesn't seem to be a good way to reliably implement `is_single_threaded()` such that it's safe to guard `NmtVirtualMemoryLocker` usage.  And the various workarounds that seem to be necessary make me feel like this approach is more brittle than the original, while at the same time end up tailoring `is_single_threaded()` specifically to this NMT use case - which goes against our original goal.  What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2588335419

From dholmes at openjdk.org  Tue Jan 14 01:18:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Jan 2025 01:18:43 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <yM_EWXlhNXi16bxEFqX_NIw0ja9wU2iI5g7ZT0gljA8=.45b47ef6-43aa-400b-a68a-84608478880a@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

We have belatedly discovered that `0x%zx` and `%#zx` behave differently in their handling of zero. The former prints `0x0` while the latter just prints `0`. This has broken the compiler replay tests as the parsing of 0 no longer works.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2588550581

From iklam at openjdk.org  Tue Jan 14 01:24:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 14 Jan 2025 01:24:05 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v6]
In-Reply-To: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
Message-ID: <xK-d_p1Eld7zB8B99n6oum2DtnqAYu9kiW34LXIAnQM=.9e86aa29-5b4d-4655-ae5d-130f70fda55c@github.com>

> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
> 
> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
> 
> Note to reviewers:
> 
> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.

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/22291/files
  - new: https://git.openjdk.org/jdk/pull/22291/files/e246276c..6275013b

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

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

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

From iklam at openjdk.org  Tue Jan 14 01:24:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 14 Jan 2025 01:24:09 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v5]
In-Reply-To: <ArfJSrqUmevHBVnB2fLa7NHDLzYn0sJyOk7JqDeR4xs=.bf92cd58-67b8-4065-99bc-086ab8459748@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <O62O1xMsS50vuykwbHP6veG22HE8AS7YY3P_TRGGuQ4=.98e117ea-7eb1-454b-841b-810e0b5c6e60@github.com>
 <ArfJSrqUmevHBVnB2fLa7NHDLzYn0sJyOk7JqDeR4xs=.bf92cd58-67b8-4065-99bc-086ab8459748@github.com>
Message-ID: <c-14Q1m51ye7xQLAoZ-KCwzbC75oR05kZNDEWOZzwaI=.b1f4bb3f-2cab-4146-9f31-d7b4d4026028@github.com>

On Mon, 13 Jan 2025 21:27:17 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Updated copyright
>>  - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
>>  - @ashu-mehra comments
>>  - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8344140-consolidate-aot-artifact-gathering-discovery
>>  - Fixe 32-bit builds; removed unused function
>>  - more clean up
>>  - tmp
>>  - More clean up
>>  - Removed unnecessary code
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/31452788...e246276c
>
> src/hotspot/share/cds/aotArtifactFinder.hpp line 71:
> 
>> 69: // Note1: See TODO comments in HeapShared::archive_object() for exceptions to this rule.
>> 70: //
>> 71: // Note2: The scanning of Java objects is done in heapShared.cpp. Please see calls into the HeapShared class
> 
> Note2 isn't referenced by the comment above. Perhaps line 62 should reference it?

Fixed.

> src/hotspot/share/cds/heapShared.cpp line 320:
> 
>> 318:     if (k->is_instance_klass()) {
>> 319:       // Whenever we see a non-array Java object of type X, we mark X to be aot-initialized.
>> 320:       // This ensures that during the production run, whenever Java code seens a cached object
> 
> typo: s/seens/sees

Fixed.

> src/hotspot/share/cds/heapShared.cpp line 327:
> 
>> 325:         // we must store them as AOT-initialized.
>> 326:         AOTArtifactFinder::add_aot_inited_class(InstanceKlass::cast(k));
>> 327:       } else if (subgraph_info == _dump_time_special_subgraph) {
> 
> Can this be an "or" condition rather than "else if" since the same function is called for either on of the conditions?

Fixed.

> src/hotspot/share/cds/heapShared.cpp line 784:
> 
>> 782: 
>> 783:   if (orig_k->is_instance_klass()) {
>> 784:     InstanceKlass* ik = InstanceKlass::cast(orig_k);
> 
> Should this be inside a "#if ASSERT" since `ik` is used only in the `assert` statements?

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1913998325
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1913998305
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1913998270
PR Review Comment: https://git.openjdk.org/jdk/pull/22291#discussion_r1913998258

From dholmes at openjdk.org  Tue Jan 14 03:33:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Jan 2025 03:33:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v16]
In-Reply-To: <aeAn4lTnQ5cJeSkbU6olE07bYeZzSfILzCfg96k3P_U=.6523a762-c243-4ddc-85f8-9688a2580994@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <aeAn4lTnQ5cJeSkbU6olE07bYeZzSfILzCfg96k3P_U=.6523a762-c243-4ddc-85f8-9688a2580994@github.com>
Message-ID: <fhSwicib-dt0Zb3lQkUGr2XvnevaR51wRaFEynzowwE=.084d00d1-03c1-4a38-bda3-a98368458fe5@github.com>

On Mon, 13 Jan 2025 17:49:27 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix concurrency bug

I agree `is_single_threaded` has not worked out - unfortunately.

But I'd prefer to see `Mutex::is_bootstrapping_done` implemented as `NMTVirtualMemoryTracker::is_bootstrapping_done` as this doesn't really reflect something that Mutex is relying on.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2588844400

From fyang at openjdk.org  Tue Jan 14 03:58:36 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Jan 2025 03:58:36 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines
In-Reply-To: <urgmofCWWaM2L6ZIm9R5TiaBtEn5OUdnX59WbpJ-jDQ=.2a46915c-54c0-4cfe-9a8e-efb4e8cccc6a@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
 <urgmofCWWaM2L6ZIm9R5TiaBtEn5OUdnX59WbpJ-jDQ=.2a46915c-54c0-4cfe-9a8e-efb4e8cccc6a@github.com>
Message-ID: <T9Wsh4Zx4Mbo0MDYYeoCUMALq0qOUN0IA66u8JdgWUc=.19a79353-e748-4387-a47a-3500c2475379@github.com>

On Sun, 12 Jan 2025 03:00:35 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Hi, Please consider this small refactoring work.
>> 
>> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
>> 
>> Testing on linux-riscv64:
>> - [x] tier1-3 and gtest:all (release)
>> - [x] hotspot:tier1 (fastdebug)
>
> Looks more consistent now, thanks!

@feilongjiang : Thanks for the review! Could we have a Reviewer please? Maybe @Hamlin-Li @robehn ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23008#issuecomment-2588891937

From rehn at openjdk.org  Tue Jan 14 04:46:36 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 14 Jan 2025 04:46:36 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines
In-Reply-To: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
Message-ID: <EbrYWPS0wyG2yX22BihXNFjLowIYuqERZ6nVKXIR8xk=.92c4ba83-eda2-4882-9fc0-8efa298dfdd4@github.com>

On Thu, 9 Jan 2025 14:38:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Please consider this small refactoring work.
> 
> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
> 
> Testing on linux-riscv64:
> - [x] tier1-3 and gtest:all (release)
> - [x] hotspot:tier1 (fastdebug)

Thanks!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23008#pullrequestreview-2548775955

From galder at openjdk.org  Tue Jan 14 05:10:41 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 14 Jan 2025 05:10:41 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
Message-ID: <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>

On Thu, 9 Jan 2025 12:18:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`)
>
> @galderz So you want me to review again?

@eme64 I've fixed the test issue, it's ready to be reviewed

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2589014197

From dholmes at openjdk.org  Tue Jan 14 06:55:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Jan 2025 06:55:41 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <LjnRnINSs9CmlHycT7C1L1gafsev-McP9LsWTLdQWAQ=.49851e3f-973c-49e4-8ec1-6a6345cc7cf7@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Looks good!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23084#pullrequestreview-2548932282

From jwaters at openjdk.org  Tue Jan 14 07:51:03 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 Jan 2025 07:51:03 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v8]
In-Reply-To: <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <lUbeU3hd1B0gMoY1aPKgAQ3AqUCFMtBzLVq7J-eJq5Q=.0a3aeada-91a7-4ed3-a2d7-ad6396b547ea@github.com>
Message-ID: <mN5OJ_4bxctFjsP3VTSeAjVjsb6jWBR3QiNOkpojwJg=.b1a8b798-53e1-4494-97c2-47f91902d4ca@github.com>

On Thu, 9 Jan 2025 22:07:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into new-poison
>  - Merge branch 'master' into new-poison
>  - remove more os-specific posix forwarding headers
>  - stefank whitespace suggestions
>  - add permit wrapper for strdup and use in aix
>  - remove os-specific posix forwarding headers
>  - aix permit patches
>  - more fixes for clang noreturn issues
>  - Merge branch 'master' into new-poison
>  - update copyrights
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a835d49f...6d49abbb

Curious question: Did we ever find out why the attribute warning didn't fire off at the sites of forbidden methods being called inside gtest?

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

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2589232654

From kbarrett at openjdk.org  Tue Jan 14 08:18:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 08:18:39 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <rpWAnYvava6WwBLM5XU1qZ78Vv3m6fUJdUvRh0CZzno=.01c18c03-eff6-40cc-b927-7adac4cc858d@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23084#pullrequestreview-2549050399

From epeter at openjdk.org  Tue Jan 14 08:23:40 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 14 Jan 2025 08:23:40 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v9]
In-Reply-To: <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com>
Message-ID: <jIkdjpGZry1DQ0rgn5fivnqRCb3n1t3Iyi7r-TZGdU0=.637fb62a-9244-4c2d-84b5-c9d29a396b0c@github.com>

On Mon, 13 Jan 2025 17:12:31 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure it runs with cpus with either avx512 or asimd

test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Red Hat, Inc. All rights reserved.

Should probably be 2025 by now, right? At least that is our policy for Oracle, not sure what you want to do at Red Hat

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914414960

From epeter at openjdk.org  Tue Jan 14 08:41:45 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 14 Jan 2025 08:41:45 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v9]
In-Reply-To: <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com>
Message-ID: <F09kHLR226iJitk5GW7_WBxmN2eXSBQ_JE3QRWa4ZbA=.0c043e20-6f7f-4db4-bfae-f6c6784472aa@github.com>

On Mon, 13 Jan 2025 17:12:31 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure it runs with cpus with either avx512 or asimd

Changes requested by epeter (Reviewer).

test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxInlining.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Red Hat, Inc. All rights reserved.

Year 2025? No idea what the Red Hat policy is though.

test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 104:

> 102:     }
> 103: 
> 104:     public static void ReductionInit(long[] longs, int probability) {

Suggestion:

    public static void reductionInit(long[] longs, int probability) {

This is a method name, not a class - so I think it should start lower-case, right?

test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 107:

> 105:         int aboveCount, abovePercent;
> 106: 
> 107:         // Iterate until you find a set that matches the requirement probability

Can you give a high-level definition / explanation what this does?
Also: what is the expected number of rounds you iterate here? I'm asking because I would like to be sure that a timeout is basically impossible because the probability is too low.

test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 121:

> 119:                 } else {
> 120:                     // Decrement by at least 1
> 121:                     long decrement = random.nextLong(10) + 1;

Nit: I would call it `diffToMax`, because you are really just going to get a value below the `max`, and you are not decrementing the `max`. But up to you if you want to change it.

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

PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2549073452
PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914424784
PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914426190
PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914431043
PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914434395

From epeter at openjdk.org  Tue Jan 14 08:41:46 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 14 Jan 2025 08:41:46 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v9]
In-Reply-To: <F09kHLR226iJitk5GW7_WBxmN2eXSBQ_JE3QRWa4ZbA=.0c043e20-6f7f-4db4-bfae-f6c6784472aa@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com>
 <F09kHLR226iJitk5GW7_WBxmN2eXSBQ_JE3QRWa4ZbA=.0c043e20-6f7f-4db4-bfae-f6c6784472aa@github.com>
Message-ID: <GKHASGMqNe0QdarR-UL6sT8gMD6YuEi9YRvJGigP20E=.a3140b36-27cb-4882-be94-9d1d02dc9cd6@github.com>

On Tue, 14 Jan 2025 08:29:25 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make sure it runs with cpus with either avx512 or asimd
>
> test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 104:
> 
>> 102:     }
>> 103: 
>> 104:     public static void ReductionInit(long[] longs, int probability) {
> 
> Suggestion:
> 
>     public static void reductionInit(long[] longs, int probability) {
> 
> This is a method name, not a class - so I think it should start lower-case, right?

And the method might as well allocate the array too. But up to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914427359

From epeter at openjdk.org  Tue Jan 14 08:46:38 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 14 Jan 2025 08:46:38 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
 <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
Message-ID: <Zh5eLNAYZrr0U3ql1SVpcUxP0VDp88FT0d6s2enHozo=.b3108fa8-475c-48b3-abd3-dc21228e51c7@github.com>

On Tue, 14 Jan 2025 05:07:55 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> @galderz So you want me to review again?
>
> @eme64 I've fixed the test issue, it's ready to be reviewed

@galderz I don't remember from above, but did you ever run the Long Min/Max benchmarks from this?
https://github.com/openjdk/jdk/pull/21032

Would just be nice to see that they have an improvement after this change :)

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2589327111

From epeter at openjdk.org  Tue Jan 14 08:57:45 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 14 Jan 2025 08:57:45 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
 <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
Message-ID: <w6HsRaKvY1VAALkXyMUM5UjJelIDFZXv51Rbr8cv-Fg=.fbb0189d-4bba-47c1-b737-34488f829a33@github.com>

On Tue, 14 Jan 2025 05:07:55 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> @galderz So you want me to review again?
>
> @eme64 I've fixed the test issue, it's ready to be reviewed

@galderz I ran some testing on our side, feel free to ping me in 1-2 days for the results.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2589351747

From asotona at openjdk.org  Tue Jan 14 09:31:43 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 Jan 2025 09:31:43 GMT
Subject: Integrated: 8346986: Remove ASM from java.base
In-Reply-To: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
Message-ID: <E3VSoOX4qiht7IuTX1YBqL_CX-vTzD8O3JvQ_83HAZE=.0eca0861-fb0d-4f82-b56f-a0bf3b980450@github.com>

On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> There are no more consumers of ASM library except for hotspot tests.
> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 3e989fd0
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e989fd0f7796a2352ffb1bbeee2dcd89a4416ca
Stats:     4233 lines in 322 files changed: 1409 ins; 1442 del; 1382 mod

8346986: Remove ASM from java.base

Reviewed-by: dholmes, ihse, lmesnik, alanb

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

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

From asotona at openjdk.org  Tue Jan 14 09:31:42 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 14 Jan 2025 09:31:42 GMT
Subject: RFR: 8346986: Remove ASM from java.base [v8]
In-Reply-To: <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
References: <ZhVXrADgLnmBu_VwGoX44Y_jHuHjOZfbRUsWwJ_l1_0=.5e816257-c02a-4e52-8c1b-3e255c5fb384@github.com>
 <u6JI9Pn2nj1jrG2NdaH9RoJnnhk6Ful3EBMP-2EoCP0=.8b1677f8-d237-4283-81be-37ddcb19d72c@github.com>
Message-ID: <w6oVGF3FP7M6P001KKQ6z6uE5oVUBa0fGBbWzclgBKg=.eb057aac-a358-42fe-a6c2-9bed06982e94@github.com>

On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are no more consumers of ASM library except for hotspot tests.
>> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved asm.md to the testlibrary/asm

Tier 1 - 8 tests passed (except for 2 unrelated Swing tests).

Thank you for all the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2589418041

From azafari at openjdk.org  Tue Jan 14 10:25:29 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 14 Jan 2025 10:25:29 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v13]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <nehl9pWXZryF2gElBfED79uft0eryCb2OiPHUGd8i3Q=.289d2c62-57b3-41bd-ab74-c22e6efbdd76@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

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

  added overlap checks.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/2afb8c79..f69e7577

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

  Stats: 103 lines in 5 files changed: 72 ins; 22 del; 9 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  Tue Jan 14 11:13:12 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 14 Jan 2025 11:13:12 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v14]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <-1uieQyEElVhVdiVvoa0OOaFDwZwCsw9lB--LAM_lWM=.301888a4-7131-43a0-837d-eb7a652609da@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with two additional commits since the last revision:

 - size_t format fixed.
 - fix for debug prints

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/f69e7577..abaf0b37

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

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 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 mli at openjdk.org  Tue Jan 14 11:22:40 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Jan 2025 11:22:40 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines
In-Reply-To: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
Message-ID: <x0leAMt7L71p2ZuM8FGfSfRMTLKsOJBzfBKQgYdl6Jw=.51bb76e8-7113-4d9e-aeab-7f4a2548993e@github.com>

On Thu, 9 Jan 2025 14:38:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Please consider this small refactoring work.
> 
> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
> 
> Testing on linux-riscv64:
> - [x] tier1-3 and gtest:all (release)
> - [x] hotspot:tier1 (fastdebug)

Looks good.

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23008#pullrequestreview-2549443504

From fyang at openjdk.org  Tue Jan 14 11:31:22 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Jan 2025 11:31:22 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines [v2]
In-Reply-To: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
Message-ID: <V-wq522k9DYk4yJrfjp2IxW18kdUtSm2sDaqGPwaP0o=.8eefc865-159b-4255-94af-91a5a19cc4d3@github.com>

> Hi, Please consider this small refactoring work.
> 
> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
> 
> Testing on linux-riscv64:
> - [x] tier1-3 and gtest:all (release)
> - [x] hotspot:tier1 (fastdebug)

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Improve

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23008/files
  - new: https://git.openjdk.org/jdk/pull/23008/files/5c45a475..47adf1fc

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

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

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

From fyang at openjdk.org  Tue Jan 14 11:31:22 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Jan 2025 11:31:22 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines [v2]
In-Reply-To: <EbrYWPS0wyG2yX22BihXNFjLowIYuqERZ6nVKXIR8xk=.92c4ba83-eda2-4882-9fc0-8efa298dfdd4@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
 <EbrYWPS0wyG2yX22BihXNFjLowIYuqERZ6nVKXIR8xk=.92c4ba83-eda2-4882-9fc0-8efa298dfdd4@github.com>
Message-ID: <VUESuEDYdzLpOakRYHFZw5e7sBzIa52WW_vMUjw8bTI=.1bd67466-d00f-467b-bb94-955f855b9bbd@github.com>

On Tue, 14 Jan 2025 04:43:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve
>
> Thanks!

@robehn @Hamlin-Li : Thanks for the review! I have just realized and pushed another commit making the type of immediates more consistent for several macro-assembler routines like subi/subiw. Hope the latest version still looks fine to you.

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

PR Comment: https://git.openjdk.org/jdk/pull/23008#issuecomment-2589668989

From mli at openjdk.org  Tue Jan 14 11:37:36 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 14 Jan 2025 11:37:36 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines [v2]
In-Reply-To: <V-wq522k9DYk4yJrfjp2IxW18kdUtSm2sDaqGPwaP0o=.8eefc865-159b-4255-94af-91a5a19cc4d3@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
 <V-wq522k9DYk4yJrfjp2IxW18kdUtSm2sDaqGPwaP0o=.8eefc865-159b-4255-94af-91a5a19cc4d3@github.com>
Message-ID: <rGVJ168dBCWnJAYN8L9rHHiaGuIDt4yRF1iNMmZGjR8=.6c0df3bf-e7d8-4a58-86b2-c82a45aac0a7@github.com>

On Tue, 14 Jan 2025 11:31:22 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, Please consider this small refactoring work.
>> 
>> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
>> 
>> Testing on linux-riscv64:
>> - [x] tier1-3 and gtest:all (release)
>> - [x] hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve

Still good.

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23008#pullrequestreview-2549474781

From aph at openjdk.org  Tue Jan 14 12:29:47 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 14 Jan 2025 12:29:47 GMT
Subject: RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let
 legitimize_address() fix out-of-range operands [v2]
In-Reply-To: <gWSKYAcn6p7WOUTeUnYBw1Rd6bA6oGHTrF7aTZ6Oxr4=.30226cab-3fbb-4fe6-90e3-7701f5e2dc39@github.com>
References: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
 <gWSKYAcn6p7WOUTeUnYBw1Rd6bA6oGHTrF7aTZ6Oxr4=.30226cab-3fbb-4fe6-90e3-7701f5e2dc39@github.com>
Message-ID: <prDBQwHMDwcU1PSP_59V6fMj4BjefkHxKcrHAvN4oLA=.63465995-660b-4b04-acfc-34a374efaa62@github.com>

On Wed, 8 Jan 2025 13:49:33 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> `IndOffXX` types don't do us any good. It would be simpler and faster to match a general-purpose `IndOff` type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.
>> 
>> This patch simplifies the definitions of `immXOffset` with an estimated range. Whether an immediate can be encoded in a `LDR`/`STR` instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessary `legitimize_address()` in the phase of matcher for all `LDR`/`STR` instructions using the new `IndOff` memory operands (fix [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437)).
>> 
>> After this clean-up, memory operands matched with `IndOff` may require extra code emission (effectively a `lea`) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646)). On `aarch64` platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. Because `LDR`/`STR` is always the last one emitted, no matter what addressing mode the load/store operations finally use.
>> 
>> Tier 1 - 3 passed on `Macos-aarch64` with or without the vm option `-XX:+UseZGC`.
>
> Fei Gao 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 three additional commits since the last revision:
> 
>  - Update the copyright year and code comments
>  - Merge branch 'master' into cleanup_indoff
>  - 8341611: [REDO] AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands
>    
>    IndOffXX types don't do us any good. It would be simpler and
>    faster to match a general-purpose IndOff type then let
>    legitimize_address() fix any out-of-range operands. That'd
>    reduce the size of the match rules and the time to run them.
>    
>    This patch simplifies the definitions of `immXOffset` with an
>    estimated range. Whether an immediate can be encoded in a
>    LDR/STR instructions as an offset will be determined in the phase
>    of code-emitting. Meanwhile, we add necessary
>    `legitimize_address()` in the phase of matcher for all LDR/STR
>    instructions using the new `IndOff` memory operands
>    (fix JDK-8341437).
>    
>    After this clean-up, memory operands matched with `IndOff` may
>    require extra code emission (effectively a lea) before the address
>    can be used. So we also modify the code about looking up precise
>    offset of load/store instruction for implicit null check
>    (fix JDK-8340646). On aarch64 platform, we will use the beginning
>    offset of the last instruction in the instruction clause emitted
>    for a load/store machine node. Because LDR/STR is always the last
>    one emitted, no matter what addressing mode the load/store
>    operations finally use.
>    
>    Tier 1 - 3 passed on Macos-aarch64 with or without the vm option
>    "-XX:+UseZGC"

Once we're past RDP2 I'll approve this.

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

PR Comment: https://git.openjdk.org/jdk/pull/22862#issuecomment-2589783477

From coleenp at openjdk.org  Tue Jan 14 12:37:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 12:37:49 GMT
Subject: RFR: 8347566: Replace SSIZE_FORMAT with 'z' length modifier [v2]
In-Reply-To: <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
 <8ngxf9I1hYdlTzQjB3ebRjQZr7ByhUlldFZH73SULPY=.11d7d8c3-0d97-4cfc-942c-924c668525b2@github.com>
Message-ID: <EKtaBrbhzHw0bog9_eeqqVjg5tRby9mWji9pFkZtQK8=.fee29932-3a64-4d73-ace6-330e83862210@github.com>

On Mon, 13 Jan 2025 20:39:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that replaces SSIZE_FORMAT with %zd.
>> Tested with tier1 on Oracle supported platforms (and here with GHA).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix one zu -> zd.

Thanks Dean, Kim and David for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23084#issuecomment-2589796008

From coleenp at openjdk.org  Tue Jan 14 12:37:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 12:37:50 GMT
Subject: Integrated: 8347566: Replace SSIZE_FORMAT with 'z' length modifier
In-Reply-To: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
References: <iX-3kAnoUrqW3TF__1k34by3V22MfnAfJ8nCIONVkqw=.270c5eee-afa2-434d-a664-b9e735c45668@github.com>
Message-ID: <aVkPmra_apc2MpmtYouo1ytZ_dD3i7JnCdIo50LBQac=.58a86709-62a9-4d6d-a74d-2d0780c5992b@github.com>

On Mon, 13 Jan 2025 18:47:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change that replaces SSIZE_FORMAT with %zd.
> Tested with tier1 on Oracle supported platforms (and here with GHA).

This pull request has now been integrated.

Changeset: b4cd3b12
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b4cd3b12967688d78028f548db76d24cfe654614
Stats:     81 lines in 7 files changed: 2 ins; 3 del; 76 mod

8347566: Replace SSIZE_FORMAT with 'z' length modifier

Reviewed-by: dlong, dholmes, kbarrett

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

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

From syan at openjdk.org  Tue Jan 14 12:56:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 14 Jan 2025 12:56:50 GMT
Subject: RFR: 8347649: Build fails by clang17 after JDK-8313396
Message-ID: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>

Hi all,
This PR fix build failure by clang17 after JDK-8313396. Before this PR file src/hotspot/share/utilities/forbiddenFunctions.hpp `#include <stdlib.h>` and then  `#include "forbiddenFunctions_posix.hpp"`. System header file <stdlib.h> define `realpath` function, and file forbiddenFunctions_posix.hpp add attribute declaration for `realpath` function, so clang17 report compile warning "attribute declaration must precede definition". This PR switch the sequence of `#include <stdlib.h>` and `#include "forbiddenFunctions_posix.hpp"` in file src/hotspot/share/utilities/forbiddenFunctions.hpp to fix this compile warning issue.

Below code snippet shows the clang17 compile waning:

void a(const char *, char *){};
[[deprecated]] void a(const char *, char *);


clang -Wall -c ~/compiler-test/zzkk/attribute.cpp
/home/yansendao/compiler-test/zzkk/attribute.cpp:5:3: warning: attribute declaration must precede definition [-Wignored-attributes]
    5 | [[deprecated]] void a(const char *, char *);
      |   ^
/home/yansendao/compiler-test/zzkk/attribute.cpp:4:6: note: previous definition is here
    4 | void a(const char *, char *){};
      |      ^
1 warning generated.


Additional testing:

- [ ] configure and make with gcc10 with release/fastdebug debug level
- [ ] configure and make with gcc14 with release/fastdebug debug level

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

Commit messages:
 - 8347649: Build fails by clang17 after JDK-8313396

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

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

From jbhateja at openjdk.org  Tue Jan 14 13:09:45 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 14 Jan 2025 13:09:45 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <dwyK1YzhzuD35JrKaxQdjACVH6-BgEQZCdvclQKhra4=.27cd66d0-b881-435e-b369-1c081e6a4444@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
 <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
 <zX9mex0SPUb8umMa8uRwPvj9nsKwzoOqNio0CF8xPrA=.1c82220b-e200-4654-a67e-7ffbcf7a3bdb@github.com>
 <j0cnWHdkWhJSs8CvM6EbIQpPld66a-mRHKbXKl-cOZw=.edc40acc-c892-4e46-8bbf-b6205336ecad@github.com>
 <dwyK1YzhzuD35JrKaxQdjACVH6-BgEQZCdvclQKhra4=.27cd66d0-b881-435e-b369-1c081e6a4444@github.com>
Message-ID: <DEFSfPceUTnEqdWftLVAaf_6LUl7rsD3nV1drpBsdnY=.ec2bd11e-123a-4891-a8ea-82f7d0423c84@github.com>

On Mon, 13 Jan 2025 16:51:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi @PaulSandoz , In the current scheme we are passing unboxed carriers to intrinsic entry point, in the fallback implementation carrier type is first converted to floating point value using Float.float16ToFloat API which expects to receive a short type argument,  after the operation we again convert float value to carrier type (short) using Float.floatToFloat16 API which expects a float argument,  thus our intent here is to perform unboxing and boxing outside the intrinsic thereby avoiding all complexities around boxing by compiler. Even if we pass 3 additional parameters we still need to use Float16.floatValue which invokes Float.float16ToFloat underneath, thus this minor modification on Java side is on account of optimizing the intrinsic interface.
>
> Yes, i understand the approach. It's about clarity of the fallback implementation retaining what was expressed in the original code:
> 
>         short res = Float16Math.fma(fa, fb, fc, a, b, c,
>                 (a_, b_, c_) -> {
>                     double product = (double)(a_.floatValue() * b._floatValue());
>                     return valueOf(product + c_.doubleValue());
>                 });

Hi @PaulSandoz ,

In  above code snippet the return type 'short' of intrinsic call does not comply with the value being returned which is of box type, thereby mandating addition glue code. 

Regular primitive type boxing APIs are lazily intrinsified, thereby generating  an intrinsifiable Call IR during parsing. 
LoadNode?s idealization can fetch a boxed value from the input of boxing call IR and directly forward it to users.

Q1. What is the problem in directly passing Float16 boxes to FMA and SQRT intrinsic entry points?

A. The compiler will have to unbox them before the actual operation. There are multiple schemes to perform unboxing, such as name-based, offset-based, and index-based field lookup. 
Vector API unbox expansion uses an offset-based payload field lookup, for this it bookkeeps the payload?s offset over runtime representation of VectorPayload class created as part of VM initialization.
However, VM can only bookkeep this information for classes that are part of java.base module, Float16 being part of incubation module cannot use offset-based field lookup.  Thus only viable alternative is to unbox using field name/index based lookup.
For this compiler will first verify that the incoming oop is of Float16 type and then use a hardcoded name-based lookup to Load the field value. This looks fragile as it establishes an unwanted dependency b/w Float16 field names and compiler implementation, same applies to index-based lookup as index values are dependent onthe combined field count of class and instance-specific fields, thus any addition or deletion of a class-level static helper field before the field of interest can invalidate any hardcoded index value used by the compiler. 
All in all, for safe and reliable unboxing by compiler, it's necessary to create an upfront VM representation like vector_VectorPayload.

Q2. What are the pros and cons of passing both the unboxed value and boxed values to the intrinsic entry point?
A.  
Pros:
- This will save unsafe unboxing implementation if the holder class is not part of java.base module.
- We can leverage existing box intrinsification infrastructure which directly forwards the embedded values to its users.
- Also, it will minimize the changes in the Java side implementation.

Cons:
- It's suboptimal in case the call is neither intrinsified or inlined, as it will add additional spills before the call.

Q3.  Primitive box class boxing API ?valueOf? accepts an argument of the corresponding primitive type. How different are Float16 boxing APIs. 
A.  Unlike primitive box classes, Float16 has multiple boxing APIs and none of them accept a short type argument. 
    public static Float16 valueOf(int value) 
    public static Float16 valueOf(long value) 
    public static Float16 valueOf(float f) 
    public static Float16 valueOf(double d) 
    public static Float16 valueOf(String s) throws NumberFormatException 
    public static Float16 valueOf(BigDecimal v)
    public static Float16 valueOf(BigInteger bi) 
Thus, we need to add special handling to first downcast the parameter value to short type carrier otherwise it will pose problems in forwarding the boxed values.  Existing LoadNode idealization directly forwards the input of unboxed Call IR to its users. To use existing idealization, we need to massage the input of unboxed Call IR to the exact carrier size, so it?s not a meager one-line change in the following methods to enable seamless intrinsification of Float16 boxing APIs.
bool ciMethod::is_boxing_method() const 
bool ciMethod::is_unboxing_method() const 

Given the above observations passing 3 additional box arguments to intrinsic and returning a box value needs additional changes in the compiler while minor re-structuring in Java implementation packed with in the glue logic looks like a reasonable approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1914782512

From fyang at openjdk.org  Tue Jan 14 13:12:49 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 14 Jan 2025 13:12:49 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines [v3]
In-Reply-To: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
Message-ID: <_wVWNgqaDtjqrDJfeO7ZxOR_AvRlx4JN0cpQFGfX4xY=.96ccb8c0-2137-4c60-bb30-05dfec292389@github.com>

> Hi, Please consider this small refactoring work.
> 
> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
> 
> Testing on linux-riscv64:
> - [x] tier1-3 and gtest:all (release)
> - [x] hotspot:tier1 (fastdebug)

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Fix build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23008/files
  - new: https://git.openjdk.org/jdk/pull/23008/files/47adf1fc..c603eb37

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

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

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

From jwaters at openjdk.org  Tue Jan 14 13:16:39 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 Jan 2025 13:16:39 GMT
Subject: RFR: 8347649: Build fails by clang17 after JDK-8313396
In-Reply-To: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
References: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
Message-ID: <-lK1kE38pFlhjFCN7OF4ZP4wAEPXbFOMuyLGo4trrgE=.51fe4ab5-eb69-4051-b02b-1cfd48add8ad@github.com>

On Tue, 14 Jan 2025 12:51:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> This PR fix build failure by clang17 after JDK-8313396. Before this PR file src/hotspot/share/utilities/forbiddenFunctions.hpp `#include <stdlib.h>` and then  `#include "forbiddenFunctions_posix.hpp"`. System header file <stdlib.h> define `realpath` function, and file forbiddenFunctions_posix.hpp add attribute declaration for `realpath` function, so clang17 report compile warning "attribute declaration must precede definition". This PR switch the sequence of `#include <stdlib.h>` and `#include "forbiddenFunctions_posix.hpp"` in file src/hotspot/share/utilities/forbiddenFunctions.hpp to fix this compile warning issue.
> 
> Below code snippet shows the clang17 compile waning:
> 
> void a(const char *, char *){};
> [[deprecated]] void a(const char *, char *);
> 
> 
> clang -Wall -c ~/compiler-test/zzkk/attribute.cpp
> /home/yansendao/compiler-test/zzkk/attribute.cpp:5:3: warning: attribute declaration must precede definition [-Wignored-attributes]
>     5 | [[deprecated]] void a(const char *, char *);
>       |   ^
> /home/yansendao/compiler-test/zzkk/attribute.cpp:4:6: note: previous definition is here
>     4 | void a(const char *, char *){};
>       |      ^
> 1 warning generated.
> 
> 
> Additional testing:
> 
> - [ ] configure and make with gcc10 with release/fastdebug debug level
> - [ ] configure and make with gcc14 with release/fastdebug debug level

I'm not sure this would work, the includes from the system are placed in front of the forbiddenFunctions includes so that the declaration from the system headers are seen first, which I think is needed for the workaround for clang. Pinging @kimbarrett for this

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

PR Comment: https://git.openjdk.org/jdk/pull/23102#issuecomment-2589880759

From kbarrett at openjdk.org  Tue Jan 14 13:45:45 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 13:45:45 GMT
Subject: RFR: 8347649: Build fails by clang17 after JDK-8313396
In-Reply-To: <-lK1kE38pFlhjFCN7OF4ZP4wAEPXbFOMuyLGo4trrgE=.51fe4ab5-eb69-4051-b02b-1cfd48add8ad@github.com>
References: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
 <-lK1kE38pFlhjFCN7OF4ZP4wAEPXbFOMuyLGo4trrgE=.51fe4ab5-eb69-4051-b02b-1cfd48add8ad@github.com>
Message-ID: <0Y-pFAkb1Tm1K42u47RBmQarEzsskJ_DYKt2OvDp18A=.53a8c09b-13df-4473-b329-bbacecf23c43@github.com>

On Tue, 14 Jan 2025 13:13:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I'm not sure this would work, the includes from the system are placed in front of the forbiddenFunctions includes so that the declaration from the system headers are seen first, which I think is needed for the workaround for clang. Pinging @kimbarrett for this

Yes, I've seen this PR.  No, don't do this yet.  I need to look into this in more detail.  I already have a reason to possibly
backout JDK-8313396, because of an Oracle-internal issue.  This argues I'm probably really going to have to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/23102#issuecomment-2589943208

From stuefe at openjdk.org  Tue Jan 14 14:29:57 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 14 Jan 2025 14:29:57 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <yyrbQcrGS_xUelhqipX3FYYds0Br2kug7xt7mV_Bnt4=.d18ccffc-fc7c-40bd-8834-d04c72c7719a@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <P6m80lyQu4ZlVCj8JofY2_jVmgFzzVNrEnMsr8YS1n8=.dc1ab2de-ae6b-49bf-91d0-c6e3615c3268@github.com>
 <zJvm3vO-YXdRvmRTIN1kufoc-8Mf3TWyyBZvy2ukc4c=.662286b6-4bb5-4b3a-b114-e81ea489a124@github.com>
 <yyrbQcrGS_xUelhqipX3FYYds0Br2kug7xt7mV_Bnt4=.d18ccffc-fc7c-40bd-8834-d04c72c7719a@github.com>
Message-ID: <eAPkiSPJAlPbpNLqhUeCD3kCjsXN-8naBYR0befQmJE=.6780dbd7-d949-4a58-8f58-909db89bb879@github.com>

On Mon, 11 Nov 2024 09:59:22 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>>> I was actually hoping that we could close this PR and open a new one when this moves out of draft, in order to have a clean slate for reviews to start from. This is fine, however.
>> 
>> Sorry. Maybe I misinterpreted when it is said that "... remove the draft state..".
>
>> > I was actually hoping that we could close this PR and open a new one when this moves out of draft, in order to have a clean slate for reviews to start from. This is fine, however.
>> 
>> Sorry. Maybe I misinterpreted when it is said that "... remove the draft state..".
> 
> No, I think you interpreted Thomas correctly. I don't think Thomas was aware of my wishes :-).

Note that I will not have time to examine this until after FOSDEM. If time is an issue, feel free to push this, I trust @jdksjolen and the other reviewers.

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

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2590064759

From kbarrett at openjdk.org  Tue Jan 14 16:43:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 16:43:10 GMT
Subject: RFR: 8347720: [BACKOUT] Portable implementation of FORBID_C_FUNCTION
 and ALLOW_C_FUNCTION
Message-ID: <gBZXxOKdYQRUNUYejgkfcEH6ktK5PUkhSxcixWBvWKY=.6328b8d9-9390-49d5-b80e-e26e4dcf70d0@github.com>

Clean backout of JDK-8313396.

This reverts commit e0f2f4b216bc9358caa65975204aee086e4fcbd2.

Testing: mach5 tier1

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

Commit messages:
 - Revert "8313396: Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION"

Changes: https://git.openjdk.org/jdk/pull/23110/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347720
  Stats: 584 lines in 32 files changed: 56 ins; 407 del; 121 mod
  Patch: https://git.openjdk.org/jdk/pull/23110.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23110/head:pull/23110

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

From coleenp at openjdk.org  Tue Jan 14 16:47:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 16:47:36 GMT
Subject: RFR: 8347720: [BACKOUT] Portable implementation of
 FORBID_C_FUNCTION and ALLOW_C_FUNCTION
In-Reply-To: <gBZXxOKdYQRUNUYejgkfcEH6ktK5PUkhSxcixWBvWKY=.6328b8d9-9390-49d5-b80e-e26e4dcf70d0@github.com>
References: <gBZXxOKdYQRUNUYejgkfcEH6ktK5PUkhSxcixWBvWKY=.6328b8d9-9390-49d5-b80e-e26e4dcf70d0@github.com>
Message-ID: <4wLUBhLUtRiVjQ0n63dvDoQxfQQ4JS0kWMxLREfTiFg=.df683c61-8036-499c-a2fe-7ae2dab6fbdf@github.com>

On Tue, 14 Jan 2025 16:37:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Clean backout of JDK-8313396.
> 
> This reverts commit e0f2f4b216bc9358caa65975204aee086e4fcbd2.
> 
> Testing: mach5 tier1

Backout looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23110#pullrequestreview-2550391406

From duke at openjdk.org  Tue Jan 14 17:40:20 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 14 Jan 2025 17:40:20 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  revert back to using a flag.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/3fbacd6b..57d0fba0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=15-16

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

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

From kbarrett at openjdk.org  Tue Jan 14 17:46:49 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 17:46:49 GMT
Subject: Integrated: 8347720: [BACKOUT] Portable implementation of
 FORBID_C_FUNCTION and ALLOW_C_FUNCTION
In-Reply-To: <gBZXxOKdYQRUNUYejgkfcEH6ktK5PUkhSxcixWBvWKY=.6328b8d9-9390-49d5-b80e-e26e4dcf70d0@github.com>
References: <gBZXxOKdYQRUNUYejgkfcEH6ktK5PUkhSxcixWBvWKY=.6328b8d9-9390-49d5-b80e-e26e4dcf70d0@github.com>
Message-ID: <wNtoHcSxwJVgOBlLI-x7NYjNX9CJbXkpkQqaRRBVeEw=.e4a2c909-a3dd-48e1-9ae5-b28686cb9c5b@github.com>

On Tue, 14 Jan 2025 16:37:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Clean backout of JDK-8313396.
> 
> This reverts commit e0f2f4b216bc9358caa65975204aee086e4fcbd2.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: db76f47f
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db76f47f27c46ea89cd7c08b0de6d6fa032ffb4d
Stats:     584 lines in 32 files changed: 56 ins; 407 del; 121 mod

8347720: [BACKOUT] Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION

Reviewed-by: coleenp

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

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

From kbarrett at openjdk.org  Tue Jan 14 17:46:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Jan 2025 17:46:48 GMT
Subject: RFR: 8347720: [BACKOUT] Portable implementation of
 FORBID_C_FUNCTION and ALLOW_C_FUNCTION
In-Reply-To: <4wLUBhLUtRiVjQ0n63dvDoQxfQQ4JS0kWMxLREfTiFg=.df683c61-8036-499c-a2fe-7ae2dab6fbdf@github.com>
References: <gBZXxOKdYQRUNUYejgkfcEH6ktK5PUkhSxcixWBvWKY=.6328b8d9-9390-49d5-b80e-e26e4dcf70d0@github.com>
 <4wLUBhLUtRiVjQ0n63dvDoQxfQQ4JS0kWMxLREfTiFg=.df683c61-8036-499c-a2fe-7ae2dab6fbdf@github.com>
Message-ID: <ZMspmgXIgqkMWeQHsX-pzTbWRo8Ray8JJ2Uozb_jPCI=.9d4b25cf-df6a-4171-94ce-ed19c7e302a1@github.com>

On Tue, 14 Jan 2025 16:44:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Clean backout of JDK-8313396.
>> 
>> This reverts commit e0f2f4b216bc9358caa65975204aee086e4fcbd2.
>> 
>> Testing: mach5 tier1
>
> Backout looks good.

Thanks for review @coleenp

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

PR Comment: https://git.openjdk.org/jdk/pull/23110#issuecomment-2590686426

From ccheung at openjdk.org  Tue Jan 14 17:54:43 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 14 Jan 2025 17:54:43 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v6]
In-Reply-To: <xK-d_p1Eld7zB8B99n6oum2DtnqAYu9kiW34LXIAnQM=.9e86aa29-5b4d-4655-ae5d-130f70fda55c@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <xK-d_p1Eld7zB8B99n6oum2DtnqAYu9kiW34LXIAnQM=.9e86aa29-5b4d-4655-ae5d-130f70fda55c@github.com>
Message-ID: <VW8GDCSu7_IOM7Rl-IrDuswUv5YA-mWug-VRLfByxzs=.02e9c09e-94ca-4baa-9d2d-4ee52edcf6a8@github.com>

On Tue, 14 Jan 2025 01:24:05 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
>> 
>> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
>> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
>> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
>> 
>> Note to reviewers:
>> 
>> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung comments

Updates look good.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22291#pullrequestreview-2550594464

From ayang at openjdk.org  Tue Jan 14 19:22:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Jan 2025 19:22:42 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <jvapQiGl_Lr7XQm8mB64bTIobUNNd8Ml1KjQR9n80kI=.12e9673d-0784-47ea-90d1-35357271c8a3@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2550823927

From mgronlun at openjdk.org  Tue Jan 14 19:36:35 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 14 Jan 2025 19:36:35 GMT
Subject: RFR: 8326236: assert(ce != nullptr) failed in
 Continuation::continuation_bottom_sender
In-Reply-To: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>
References: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>
Message-ID: <_-wlxU0E78hWbrO2xsOFowT2RhnAZuHp5C8NR_zlK1Y=.78d1bd54-94eb-4280-9e92-160c48f13ceb@github.com>

On Thu, 9 Jan 2025 19:48:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method frame::safe_for_sender() we could read a sender_pc that matches StubRoutines::cont_returnBarrier() but there is no actual continuation in the stack. I added more details in the bug comments on how we can get into this situation. The extra check verifies there is a ContinuationEntry further up in the stack. I run the patch through mach5 tiers 1-2 for sanity testing and tiers 6-7.
> 
> Thanks,
> Patricio

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23017#pullrequestreview-2550852022

From iklam at openjdk.org  Tue Jan 14 19:50:03 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 14 Jan 2025 19:50:03 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v7]
In-Reply-To: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
Message-ID: <RlIfY8Gq0qytu6LPG_UOS_LHXk4nTAboesR7Xst6Ce8=.38275488-7e74-4804-9646-35f72ac369be@github.com>

> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
> 
> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
> 
> Note to reviewers:
> 
> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
 - @calvinccheung comments
 - Updated copyright
 - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
 - @ashu-mehra comments
 - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8344140-consolidate-aot-artifact-gathering-discovery
 - Fixe 32-bit builds; removed unused function
 - more clean up
 - tmp
 - ... and 3 more: https://git.openjdk.org/jdk/compare/2de71d04...07cacbd0

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

Changes: https://git.openjdk.org/jdk/pull/22291/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22291&range=06
  Stats: 1356 lines in 29 files changed: 563 ins; 679 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/22291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22291/head:pull/22291

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

From gziemski at openjdk.org  Tue Jan 14 20:53:33 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 14 Jan 2025 20:53:33 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed
 and memory
Message-ID: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>

Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.

To use, you first need to record the pattern of operations, ex:

`./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`

This will run the target app, and log all the allocations in chronological order. This will produce a few files:
- hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations)
- hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state)
- hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing)

Now you can use those recording to actually benchmark your proposed changes, ex:

`./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10`

Which will produce yet another file:

- hs_nmt_pid23527_benchmark.log

that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output.

The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change.

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

Commit messages:
 - white spaces
 - white spaces
 - white spaces
 - white spaces
 - win and linux APIs
 - more consistent output when benchmarking
 - remove exec flag
 - NMT benchmark

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

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

From duke at openjdk.org  Tue Jan 14 21:36:52 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 14 Jan 2025 21:36:52 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <qxL9i89a6jjanvpXtCO3PSyKrQ3u9M-ssQUv39PgqbQ=.da7dc0c8-2a4d-4586-916c-671753dd363a@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

Okay I've gone back to the old approach of using a marker. I've replaced the name `_bootstrapping_done` in favor of `NmtVirtualMemoryLocker::_safe_to_use`. I think this makes more sense because we aren't waiting on NMT bootstrapping, we are instead waiting for other conditions outside of NMT.  

Yes, I agree that this marker should live in NMT instead of Mutex or Threads because we are not only dependent on mutexes being ready or threads being ready, we're dependent on both. And this dependency is specific to NMT (at least it seems for now) since NMT is used so early.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2591146892

From pchilanomate at openjdk.org  Tue Jan 14 21:53:51 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Jan 2025 21:53:51 GMT
Subject: RFR: 8326236: assert(ce != nullptr) failed in
 Continuation::continuation_bottom_sender
In-Reply-To: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>
References: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>
Message-ID: <I4GA2vLL6m_2Vq4ZxRy9EDUz12faOE7pUG3LKhmZ7WI=.a4b30d55-ff4e-4d68-b990-622ea0376d77@github.com>

On Thu, 9 Jan 2025 19:48:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method frame::safe_for_sender() we could read a sender_pc that matches StubRoutines::cont_returnBarrier() but there is no actual continuation in the stack. I added more details in the bug comments on how we can get into this situation. The extra check verifies there is a ContinuationEntry further up in the stack. I run the patch through mach5 tiers 1-2 for sanity testing and tiers 6-7.
> 
> Thanks,
> Patricio

Thanks for the reviews David and Markus!

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

PR Comment: https://git.openjdk.org/jdk/pull/23017#issuecomment-2591176961

From pchilanomate at openjdk.org  Tue Jan 14 21:53:51 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Jan 2025 21:53:51 GMT
Subject: Integrated: 8326236: assert(ce != nullptr) failed in
 Continuation::continuation_bottom_sender
In-Reply-To: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>
References: <cLP5kASHkz6ub_Yf43szPjBZ4mUx1Q_YAhYNNMcMnRE=.006ac47f-5d3d-44b0-a449-69b3a957f448@github.com>
Message-ID: <_AVN6ZDHKta6Ye4x4Vuc_-F31IaD5Q0Bq5dmkl88cZ8=.201edd2a-b417-4f5b-855a-781e4fae08f9@github.com>

On Thu, 9 Jan 2025 19:48:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method frame::safe_for_sender() we could read a sender_pc that matches StubRoutines::cont_returnBarrier() but there is no actual continuation in the stack. I added more details in the bug comments on how we can get into this situation. The extra check verifies there is a ContinuationEntry further up in the stack. I run the patch through mach5 tiers 1-2 for sanity testing and tiers 6-7.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: ec2aaaaf
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec2aaaaf83ad0553d9cb8b3a81e8214b3f5e63fe
Stats:     20 lines in 4 files changed: 20 ins; 0 del; 0 mod

8326236: assert(ce != nullptr) failed in Continuation::continuation_bottom_sender

Reviewed-by: dholmes, mgronlun

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

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

From fyang at openjdk.org  Wed Jan 15 00:20:38 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Jan 2025 00:20:38 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines [v2]
In-Reply-To: <rGVJ168dBCWnJAYN8L9rHHiaGuIDt4yRF1iNMmZGjR8=.6c0df3bf-e7d8-4a58-86b2-c82a45aac0a7@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
 <V-wq522k9DYk4yJrfjp2IxW18kdUtSm2sDaqGPwaP0o=.8eefc865-159b-4255-94af-91a5a19cc4d3@github.com>
 <rGVJ168dBCWnJAYN8L9rHHiaGuIDt4yRF1iNMmZGjR8=.6c0df3bf-e7d8-4a58-86b2-c82a45aac0a7@github.com>
Message-ID: <2m3uWv_NXMZ1qqvOS06K-QWc4MhPKCtXaLuIlXNKHmk=.d7e1c715-58a1-416a-bc63-326abbf76202@github.com>

On Tue, 14 Jan 2025 11:34:40 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Still good.

Could you please re-approve? Fixed a build issue and re-run hs:tier1. Result is clean.

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

PR Comment: https://git.openjdk.org/jdk/pull/23008#issuecomment-2591365210

From dholmes at openjdk.org  Wed Jan 15 00:26:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Jan 2025 00:26:34 GMT
Subject: RFR: 8347649: Build fails by clang17 after JDK-8313396
In-Reply-To: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
References: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
Message-ID: <0b1upC8PiXWKoqcU96kEfctwBvz7iBnrQkGDRTgPf0M=.4919e07b-2e1f-44b1-96a8-a67e0956479d@github.com>

On Tue, 14 Jan 2025 12:51:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> This PR fix build failure by clang17 after JDK-8313396. Before this PR file src/hotspot/share/utilities/forbiddenFunctions.hpp `#include <stdlib.h>` and then  `#include "forbiddenFunctions_posix.hpp"`. System header file <stdlib.h> define `realpath` function, and file forbiddenFunctions_posix.hpp add attribute declaration for `realpath` function, so clang17 report compile warning "attribute declaration must precede definition". This PR switch the sequence of `#include <stdlib.h>` and `#include "forbiddenFunctions_posix.hpp"` in file src/hotspot/share/utilities/forbiddenFunctions.hpp to fix this compile warning issue.
> 
> Below code snippet shows the clang17 compile waning:
> 
> void a(const char *, char *){};
> [[deprecated]] void a(const char *, char *);
> 
> 
> clang -Wall -c ~/compiler-test/zzkk/attribute.cpp
> /home/yansendao/compiler-test/zzkk/attribute.cpp:5:3: warning: attribute declaration must precede definition [-Wignored-attributes]
>     5 | [[deprecated]] void a(const char *, char *);
>       |   ^
> /home/yansendao/compiler-test/zzkk/attribute.cpp:4:6: note: previous definition is here
>     4 | void a(const char *, char *){};
>       |      ^
> 1 warning generated.
> 
> 
> Additional testing:
> 
> - [ ] configure and make with gcc10 with release/fastdebug debug level
> - [ ] configure and make with gcc14 with release/fastdebug debug level

The backout was done, so this PR and issue can be closed. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23102#issuecomment-2591377025

From psandoz at openjdk.org  Wed Jan 15 00:31:40 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 15 Jan 2025 00:31:40 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <DEFSfPceUTnEqdWftLVAaf_6LUl7rsD3nV1drpBsdnY=.ec2bd11e-123a-4891-a8ea-82f7d0423c84@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
 <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
 <zX9mex0SPUb8umMa8uRwPvj9nsKwzoOqNio0CF8xPrA=.1c82220b-e200-4654-a67e-7ffbcf7a3bdb@github.com>
 <j0cnWHdkWhJSs8CvM6EbIQpPld66a-mRHKbXKl-cOZw=.edc40acc-c892-4e46-8bbf-b6205336ecad@github.com>
 <dwyK1YzhzuD35JrKaxQdjACVH6-BgEQZCdvclQKhra4=.27cd66d0-b881-435e-b369-1c081e6a4444@github.com>
 <DEFSfPceUTnEqdWftLVAaf_6LUl7rsD3nV1drpBsdnY=.ec2bd11e-123a-4891-a8ea-82f7d0423c84@github.com>
Message-ID: <iPfktRIFP--gP1VL1_lyV_Shj-5GRpbRFMit_h9A8Cg=.c9415921-b0b8-475d-8b9c-3bff3bc75d26@github.com>

On Tue, 14 Jan 2025 13:07:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Given the above observations passing 3 additional box arguments to intrinsic and returning a box value needs additional changes in the compiler while minor re-structuring in Java implementation packed with in the glue logic looks like a reasonable approach.

Did you mean to say *no* additional changes in the compiler? Otherwise, if not what would those changes be?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1915791046

From syan at openjdk.org  Wed Jan 15 01:41:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Jan 2025 01:41:39 GMT
Subject: RFR: 8347649: Build fails by clang17 after JDK-8313396
In-Reply-To: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
References: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
Message-ID: <U1BdbXAvivDN1gOIR_wxdhSv4_YGRQMp7lcvfQsACWI=.f54f17e7-555c-4afa-b07b-2a9f9efc6100@github.com>

On Tue, 14 Jan 2025 12:51:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> This PR fix build failure by clang17 after JDK-8313396. Before this PR file src/hotspot/share/utilities/forbiddenFunctions.hpp `#include <stdlib.h>` and then  `#include "forbiddenFunctions_posix.hpp"`. System header file <stdlib.h> define `realpath` function, and file forbiddenFunctions_posix.hpp add attribute declaration for `realpath` function, so clang17 report compile warning "attribute declaration must precede definition". This PR switch the sequence of `#include <stdlib.h>` and `#include "forbiddenFunctions_posix.hpp"` in file src/hotspot/share/utilities/forbiddenFunctions.hpp to fix this compile warning issue.
> 
> Below code snippet shows the clang17 compile waning:
> 
> void a(const char *, char *){};
> [[deprecated]] void a(const char *, char *);
> 
> 
> clang -Wall -c ~/compiler-test/zzkk/attribute.cpp
> /home/yansendao/compiler-test/zzkk/attribute.cpp:5:3: warning: attribute declaration must precede definition [-Wignored-attributes]
>     5 | [[deprecated]] void a(const char *, char *);
>       |   ^
> /home/yansendao/compiler-test/zzkk/attribute.cpp:4:6: note: previous definition is here
>     4 | void a(const char *, char *){};
>       |      ^
> 1 warning generated.
> 
> 
> Additional testing:
> 
> - [ ] configure and make with gcc10 with release/fastdebug debug level
> - [ ] configure and make with gcc14 with release/fastdebug debug level

Close this PR as JDK-8313396 has been backout.

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

PR Comment: https://git.openjdk.org/jdk/pull/23102#issuecomment-2591455193

From syan at openjdk.org  Wed Jan 15 01:41:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Jan 2025 01:41:39 GMT
Subject: Withdrawn: 8347649: Build fails by clang17 after JDK-8313396
In-Reply-To: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
References: <7foYN7psPh_0Btfk3rw9clz61-6h34dbepF-imTGLYw=.0bda215e-77f4-4858-9fda-31346ac65b56@github.com>
Message-ID: <_d2vsBBrTVm6FIp_5_VgXA2ju0HLJXU_-yUyS3XAXYg=.a908fa18-c93a-42be-86d9-a04aac539fd2@github.com>

On Tue, 14 Jan 2025 12:51:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> This PR fix build failure by clang17 after JDK-8313396. Before this PR file src/hotspot/share/utilities/forbiddenFunctions.hpp `#include <stdlib.h>` and then  `#include "forbiddenFunctions_posix.hpp"`. System header file <stdlib.h> define `realpath` function, and file forbiddenFunctions_posix.hpp add attribute declaration for `realpath` function, so clang17 report compile warning "attribute declaration must precede definition". This PR switch the sequence of `#include <stdlib.h>` and `#include "forbiddenFunctions_posix.hpp"` in file src/hotspot/share/utilities/forbiddenFunctions.hpp to fix this compile warning issue.
> 
> Below code snippet shows the clang17 compile waning:
> 
> void a(const char *, char *){};
> [[deprecated]] void a(const char *, char *);
> 
> 
> clang -Wall -c ~/compiler-test/zzkk/attribute.cpp
> /home/yansendao/compiler-test/zzkk/attribute.cpp:5:3: warning: attribute declaration must precede definition [-Wignored-attributes]
>     5 | [[deprecated]] void a(const char *, char *);
>       |   ^
> /home/yansendao/compiler-test/zzkk/attribute.cpp:4:6: note: previous definition is here
>     4 | void a(const char *, char *){};
>       |      ^
> 1 warning generated.
> 
> 
> Additional testing:
> 
> - [ ] configure and make with gcc10 with release/fastdebug debug level
> - [ ] configure and make with gcc14 with release/fastdebug debug level

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Wed Jan 15 02:06:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Jan 2025 02:06:39 GMT
Subject: RFR: 8338428: Print final VM flags for task [v2]
In-Reply-To: <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
Message-ID: <7bLJYO2OfgAlgUTUzjLRa5r5vV8N6MBe17sjk0Q2QNQ=.1890ffb8-fdc0-4be0-ba6d-fccb866945ab@github.com>

On Sun, 12 Jan 2025 15:47:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The test lib is not ued

Given we run many thousands of tests each day, the machine time needed to execute yet-another-vm for each test, would make this too costly. Can we not piggy-back this into the VM that does the "requires" processing?

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

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2591480970

From dholmes at openjdk.org  Wed Jan 15 02:15:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Jan 2025 02:15:41 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <MiGwjSqaV9x0rP4PPhxEOEp3b9m9BbzOToyLyTelL2E=.860cf4c3-fe91-4f61-a6cd-1544f9491791@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

Nothing further from me. Thanks for your patience and perseverance on this one.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2551424832

From duke at openjdk.org  Wed Jan 15 03:57:39 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Jan 2025 03:57:39 GMT
Subject: Withdrawn: 8318098: Update jfr tests with corresponding requires flags
In-Reply-To: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com>
References: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com>
Message-ID: <CW0oTpEa0QAheoslLYp6iy-t-ay-pf8N6100To2RXk4=.b9a5f4f5-7a2e-460b-a597-16770d53d893@github.com>

On Tue, 19 Nov 2024 16:52:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are few JFR tests are failing with -Xcomp and compiler stress flags. 
> I added requires tag when tests are incompatible with corresponding mode:
> 1) huge stacks and DeoptimieALot cause timeout
> 2) WB controlled compilation doesn't work with Xcomp
> 3) Arguments tests might be sensitive to aby flags and should be flagless
> and excluded a 2 groups of tests failing with Xcomp for further invesitigation.
> 
> The drivers for these are following bug escapes because of JFR was not tested with VM flags:
> https://bugs.openjdk.org/browse/JDK-8340586
> https://bugs.openjdk.org/browse/JDK-8344199
> https://bugs.openjdk.org/browse/JDK-8340826
> https://bugs.openjdk.org/browse/JDK-8343893
> 
> 
> So now jfr tests support all flags used for testing  in CI with them.
> The bug
> https://bugs.openjdk.org/browse/JDK-8318098
> has a linked all the product issues found by running JFR tests with flags and explanation why is it needed.

This pull request has been closed without being integrated.

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

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

From iklam at openjdk.org  Wed Jan 15 04:35:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 15 Jan 2025 04:35:51 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v3]
In-Reply-To: <Rz_wLTn_6nuzC1ykXc0_X44wHnUdOxjFs6wtGRP31K8=.54ed0414-b83a-47f3-b03f-5341a2406b11@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
 <C_aAQOl_agKc49vGZe5pdpUIORd2HIV4stAPJ0HEnis=.a670485e-9c9e-4a99-ad18-a31b6d750e28@github.com>
 <Rz_wLTn_6nuzC1ykXc0_X44wHnUdOxjFs6wtGRP31K8=.54ed0414-b83a-47f3-b03f-5341a2406b11@github.com>
Message-ID: <KErHPIfzP6muXMsdly7BQxh__7FQ3v_94THUdjLevt0=.4bbf5073-87e7-4d78-9e57-b3ef21638c53@github.com>

On Tue, 7 Jan 2025 22:52:16 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8344140-consolidate-aot-artifact-gathering-discovery
>>  - Fixe 32-bit builds; removed unused function
>>  - more clean up
>>  - tmp
>>  - More clean up
>>  - Removed unnecessary code
>>  - 8344140: Consolidate AOT cache code for artifact discovery
>
> Comment in `AOTClassInitializer::can_archive_initialized_mirror()` refers to `HeapShared::find_all_aot_initialized_classes()` which does not exist anymore:
> 
> 
>   // When CDSConfig::is_initing_classes_at_dump_time() is enabled,
>   // HeapShared::find_all_aot_initialized_classes() finds the classes of all
>   // heap objects that are reachable from HeapShared::_run_time_special_subgraph,
>   // and mark these classes as aot-inited.
> 
> 
> And this comment at line 263 in `aotClassInitializer.cpp` also needs to be updated as the enum classes are not unconditionally AOT-initialized:
> 
> 
>       // above we selected all enums; we must include their super as well
>       {"java/lang/Enum"},

Thanks @ashu-mehra and @calvinccheung for the review.
I've tested against tiers 1~4 and builds-tier5. No new failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/22291#issuecomment-2591628370

From iklam at openjdk.org  Wed Jan 15 04:35:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 15 Jan 2025 04:35:52 GMT
Subject: Integrated: 8344140: Refactor the discovery of AOT cache artifacts
In-Reply-To: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
Message-ID: <c9g87ekLjf1jE0x6IrkMT8nC49-Q7ZlW__yW_ViDOYU=.6b86a4bc-1d21-403f-baaa-3c9393ce6216@github.com>

On Thu, 21 Nov 2024 05:27:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
> 
> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
> 
> Note to reviewers:
> 
> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.

This pull request has now been integrated.

Changeset: be1cdd94
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be1cdd9450763c5c409bd6e28ec3604cdd90b653
Stats:     1356 lines in 29 files changed: 563 ins; 679 del; 114 mod

8344140: Refactor the discovery of AOT cache artifacts

Reviewed-by: ccheung, asmehra

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

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

From stuefe at openjdk.org  Wed Jan 15 06:43:37 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Jan 2025 06:43:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <1nOiSreyP0kY8K5HY02xjtz0gPa7Y9jPqE7lVtSV5T8=.04075331-6448-4351-929e-9c5cc59b84e7@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

This looks good. 

But after the last attempt I would feel safer if we could run this through some more extensive testing. I ran a bunch of tests myself, and will ping the SAP guys. @dholmes-ora could you schedule some tests at Oracle? IIRC the ZGC tests were the ones that broke the most.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2551672289

From rehn at openjdk.org  Wed Jan 15 07:55:29 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 15 Jan 2025 07:55:29 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines [v3]
In-Reply-To: <_wVWNgqaDtjqrDJfeO7ZxOR_AvRlx4JN0cpQFGfX4xY=.96ccb8c0-2137-4c60-bb30-05dfec292389@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
 <_wVWNgqaDtjqrDJfeO7ZxOR_AvRlx4JN0cpQFGfX4xY=.96ccb8c0-2137-4c60-bb30-05dfec292389@github.com>
Message-ID: <eP4OE83dpVm7tnkmQvE0A_Zz-OgpCXITL27k3LtINF0=.6f1aa882-c8db-4fc8-b7d6-4dce7e0c2773@github.com>

On Tue, 14 Jan 2025 13:12:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, Please consider this small refactoring work.
>> 
>> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
>> 
>> Testing on linux-riscv64:
>> - [x] tier1-3 and gtest:all (release)
>> - [x] hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

Ship away!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23008#pullrequestreview-2551754181

From fyang at openjdk.org  Wed Jan 15 08:22:27 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Jan 2025 08:22:27 GMT
Subject: RFR: 8347352: RISC-V: Cleanup bitwise AND assembler routines [v3]
In-Reply-To: <_wVWNgqaDtjqrDJfeO7ZxOR_AvRlx4JN0cpQFGfX4xY=.96ccb8c0-2137-4c60-bb30-05dfec292389@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
 <_wVWNgqaDtjqrDJfeO7ZxOR_AvRlx4JN0cpQFGfX4xY=.96ccb8c0-2137-4c60-bb30-05dfec292389@github.com>
Message-ID: <fqJmReOUrDQs8mWCMML9rkb5ml2poEMdA98cIAFicpk=.b998acb8-0391-407e-ba32-7bfcf91cd586@github.com>

On Tue, 14 Jan 2025 13:12:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, Please consider this small refactoring work.
>> 
>> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
>> 
>> Testing on linux-riscv64:
>> - [x] tier1-3 and gtest:all (release)
>> - [x] hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

Thanks all for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23008#issuecomment-2591880748

From fyang at openjdk.org  Wed Jan 15 08:22:28 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Jan 2025 08:22:28 GMT
Subject: Integrated: 8347352: RISC-V: Cleanup bitwise AND assembler routines
In-Reply-To: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
References: <NO8DzYoXyhsw7wZDf0AuQ-oAC-3Bq2WcOutMg2m1lDc=.12d9344e-8006-48ab-8d95-360f3f3e8a7b@github.com>
Message-ID: <V5bea7TGLiVGzKZZ0dKXWA8apx-BtjomD7j0TioEr5w=.c7b42616-27df-41f8-bfb0-250c593ae461@github.com>

On Thu, 9 Jan 2025 14:38:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Please consider this small refactoring work.
> 
> It's a bit strange that we have `Assembler::_and_imm12` and `MacroAssembler::andi`, which is quite different from friends `Assembler::ori` and `Assembler::xori`. And it doesn't seem necessary to have this `MacroAssembler::andi` which checks the immediate range. I find the immediate is within signed 12-bit range for most of the cases. One exception is in file `sharedRuntime_riscv.cpp` where I think we can do `mv` + `andr` instead.
> 
> Testing on linux-riscv64:
> - [x] tier1-3 and gtest:all (release)
> - [x] hotspot:tier1 (fastdebug)

This pull request has now been integrated.

Changeset: 4f3dc9d1
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f3dc9d13a609ef50205f77e9cdf9c57fd30bcca
Stats:     42 lines in 5 files changed: 1 ins; 10 del; 31 mod

8347352: RISC-V: Cleanup bitwise AND assembler routines

Reviewed-by: rehn, fjiang, mli

-------------

PR: https://git.openjdk.org/jdk/pull/23008

From adinn at openjdk.org  Wed Jan 15 09:49:26 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 15 Jan 2025 09:49:26 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v11]
In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
Message-ID: <co3DT9O_LNGAi_-wfD91VmN1_5RMVLylDXcxkmdvg0I=.750ef51f-76fc-475b-87cc-0a2ae47aadea@github.com>

> Implementation of JDK-8343767

Andrew Dinn has updated the pull request incrementally with four additional commits since the last revision:

 - allow repeated entries rather than stubs
 - correct error in stub routines fill test
 - remove unused ppc stub
 - fix errors in s390 arraycopy code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21957/files
  - new: https://git.openjdk.org/jdk/pull/21957/files/2bc580ce..691d6ad8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=09-10

  Stats: 425 lines in 17 files changed: 70 ins; 240 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/21957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957

PR: https://git.openjdk.org/jdk/pull/21957

From tschatzl at openjdk.org  Wed Jan 15 09:50:46 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Jan 2025 09:50:46 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <0iii5xOCqc5Y4o6SpUIX11dKYjDwFDP7qAyRJ7cgSDM=.f5551a2a-4b1b-4084-b4ee-5b84b417ca4e@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2552068102

From gcao at openjdk.org  Wed Jan 15 09:51:26 2025
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 15 Jan 2025 09:51:26 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v10]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <-7WakNQrV3PbcXXz1VxcyI38i56gpunMO_nrj08autA=.e3b7b7a7-e0c2-43bd-bbea-141d57e2181c@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'upstream/master' into JDK-8342881
 - Fix for Feilong's review
 - Add MacroAssembler::ror function
 - Merge branch 'master' into JDK-8342881
 - Update code comment
 - Update for RealFYang's comment
 - Merge remote-tracking branch 'upstream/master' into JDK-8342881
 - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

-------------

Changes: https://git.openjdk.org/jdk/pull/21922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=09
  Stats: 374 lines in 5 files changed: 300 ins; 23 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/21922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21922/head:pull/21922

PR: https://git.openjdk.org/jdk/pull/21922

From rehn at openjdk.org  Wed Jan 15 10:17:57 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 15 Jan 2025 10:17:57 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup
Message-ID: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>

Hey, please consider.

I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
We also had this same format repeated many times.

This patch takes all instructions format duplicates and replaces them with 'fp_base'.
fadd_s is thus described in code as:
`fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
Instead of:
`INSN(fadd_s,   0b1010011, 0b0000000);`

It then moves zfh/zfhmin to a sepererate section and assert checks them.

Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.

Tested:
jdk/java/lang/Math
jdk/java/util/Formatter/
jdk/java/lang/Float/
jdk/java/lang/Double/
hotspot/jtreg/compiler/floatingpoint/
hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
hotspot/jtreg/compiler/eliminateAutobox/
hotspot/jtreg/vmTestbase/jit/

And tier1 twice, no FP issues. (Using UseZfh/min)

Thanks, Robbin

-------------

Commit messages:
 - Baseline

Changes: https://git.openjdk.org/jdk/pull/23130/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347794
  Stats: 536 lines in 8 files changed: 303 ins; 133 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/23130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23130/head:pull/23130

PR: https://git.openjdk.org/jdk/pull/23130

From adinn at openjdk.org  Wed Jan 15 11:10:59 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 15 Jan 2025 11:10:59 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v12]
In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
Message-ID: <WM7iFXNWu_dtmaJB2EciQgVJGTAhAQj86kGBKcUYz0k=.bf3058c1-9bb9-498a-9000-f47566259fa6@github.com>

> Implementation of JDK-8343767

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  remove unreferenced local var

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21957/files
  - new: https://git.openjdk.org/jdk/pull/21957/files/691d6ad8..53480ed5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957

PR: https://git.openjdk.org/jdk/pull/21957

From mdoerr at openjdk.org  Wed Jan 15 11:11:00 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Jan 2025 11:11:00 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v11]
In-Reply-To: <co3DT9O_LNGAi_-wfD91VmN1_5RMVLylDXcxkmdvg0I=.750ef51f-76fc-475b-87cc-0a2ae47aadea@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <co3DT9O_LNGAi_-wfD91VmN1_5RMVLylDXcxkmdvg0I=.750ef51f-76fc-475b-87cc-0a2ae47aadea@github.com>
Message-ID: <v7JUs4MGiwKS_JNtJFzVatoHZQ_yi9uXzMCmfpDmJp8=.0cdb76a0-8e3c-4c30-b999-ad263f8e7f6c@github.com>

On Wed, 15 Jan 2025 09:49:26 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - allow repeated entries rather than stubs
>  - correct error in stub routines fill test
>  - remove unused ppc stub
>  - fix errors in s390 arraycopy code

gtest has passed on PPC64 with the latest updates. Thanks! The PPC64 code LGTM. I haven't reviewed the other code. This is only a partial review.
I think the Copyright headers of the files which were modified this year will need to get updated before integration.

GHA shows build warnings on Windows.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21957#pullrequestreview-2552253404
PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2592376050

From coleenp at openjdk.org  Wed Jan 15 13:50:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 13:50:46 GMT
Subject: RFR: 8337978: Verify OopHandles oops on access
In-Reply-To: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>
References: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>
Message-ID: <APqYQpXUjmpFgNym0lqC46VO47BL78khHra8I3R8spc=.fe77328c-fe3c-4954-b669-130f7013061a@github.com>

On Fri, 10 Jan 2025 17:32:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Detecting failures like [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941) would be more convenient if we verified the oops we put/get to/from `OopHandles`-s explicitly. This will stop the leakage of incorrect oops (e.g. bad Java klass mirrors seen in [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941)) to the runtime.
> 
> I was curious how this affects testing time, and I cannot see a big difference at least on `tier1`:
> 
> 
> # Baseline
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60427.40s user 4604.67s system 3775% cpu 28:42.39 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  61364.50s user 4563.23s system 3806% cpu 28:52.20 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60192.57s user 4610.89s system 3788% cpu 28:30.51 total
> 
> # With OopHandle verification
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60410.88s user 4601.52s system 3740% cpu 28:58.20 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60389.57s user 4572.23s system 3752% cpu 28:50.96 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60845.41s user 4578.50s system 3757% cpu 29:01.08 total
> 
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `all`
>  - [ ] Linux x86_64 server fastdebug, `all`

This looks good. Thank you for adding this.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23043#pullrequestreview-2552803306

From adinn at openjdk.org  Wed Jan 15 14:00:01 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 15 Jan 2025 14:00:01 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
Message-ID: <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>

> Implementation of JDK-8343767

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  update copyrights

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21957/files
  - new: https://git.openjdk.org/jdk/pull/21957/files/53480ed5..04927290

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=11-12

  Stats: 49 lines in 38 files changed: 0 ins; 0 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/21957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957

PR: https://git.openjdk.org/jdk/pull/21957

From adinn at openjdk.org  Wed Jan 15 14:07:45 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 15 Jan 2025 14:07:45 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <kBUMTZM_oooYkibxwKfTJ7kvEqmIemr0ir0DSSQWi9s=.4bae0b8c-54be-4467-a1c6-60560b8fdcd9@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
 <kBUMTZM_oooYkibxwKfTJ7kvEqmIemr0ir0DSSQWi9s=.4bae0b8c-54be-4467-a1c6-60560b8fdcd9@github.com>
Message-ID: <TOF-UWyKOOBLug_MI-rLFUQDC4S8L9IbyHfzHj9fy1c=.a336cc2c-b380-4020-bfab-61107d985e34@github.com>

On Tue, 3 Dec 2024 02:45:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   increase compiler stub space for macos x86_64
>
> Looks good. 
> 
> Testing results (hs-tier1 - hs-tier4) are clean.

@iwanowww @TheRealMDoerr @offamitkumar

I believe I have now addressed all outstanding issues on all arches:

 - I bumped up the blob sizes to account for merged changes and to allow enough headroom for the compiler stubs on macos/x64
 - I fixed the ppc test failure (my patch to the `TEST_FILL` macro ended up checking whether the accessor was null rather than the accessed field; the same error is now removed on s390)
 - I removed the unused `ppc zero_words_aligned8` stub
 - I fixed an couple of cut and paste errors that messed up the s390 conjoint `obj_uninit` array copy routines. s390 is now passing tier1 tests (albeit grindingly slowly on my borrowed s390 box :-)
 - I updated all copyrights to 2024 for additions/changes made last years and 2025 for changes added since new year

and finally

 - I removed the `repeat_stub` template that was used to declare and generate an array of `lookup_secondary_supers_table` stubs and replaced it with a `do_entry_array` template that is used to declare and generate an array of entries for the now single `lookup_secondary_supers_table` stub.

I believe that last change makes the declarations more coherent. We should not really be declaring/generating a fixed size collection of closely related routines as independent stubs since those routines ought either to be all present or none of them present. Instead it makes much more sense to declare/generate the routines as a single named stub which exposes an array of entries.

This change also simplifies the generation of the associated stub names/enum tags and blob/stub verifier routines. Every stub now has a compile-time constant C string name generated in the names array, a single global enum tag and a single blob-local enum tag.

Also this enables a nice follow-up. We don't currently have unique global or blob/stub-local enum tags for each separate entry (or a base tag plus dedicated range in the case where we declare an array of entries) but it will now be possible to achieve that, allowing us to add further verification including, in Leyden, checking that stored and retrieved entry counts match a stub's associated enum tag range.

@TheRealMDoerr thanks for the already re-reviewing.

@iwanowww @offamitkumar @RealFYang could you please give this one final look over?

@iwanowww would it be appropriate to rerun full tier1-4 tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2592943666

From sroy at openjdk.org  Wed Jan 15 16:47:40 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 15 Jan 2025 16:47:40 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <W6x-htemcgUrhZXpzllqxD8azf9eglIvLlgrlqQTxYs=.84f59b57-3a55-4363-997f-13aee029c21b@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
 <W6x-htemcgUrhZXpzllqxD8azf9eglIvLlgrlqQTxYs=.84f59b57-3a55-4363-997f-13aee029c21b@github.com>
Message-ID: <Wjnz_Vw8UvJbj0sftKS2Fn9ivJlKyWVk4XSMMod48cw=.dd48bdf1-1038-4912-b3ce-28853a8de10a@github.com>

On Fri, 10 Jan 2025 13:07:53 GMT, Andrew Haley <aph at openjdk.org> wrote:

> The commenting here is poor.
> 
> GHASH uses little-endian for the byte order, but big-endian for the bit order. For example, the polynomial 1 is represented as the 16-byte string 80 00 00 00 | 12 bytes of 00. So, we must either reverse the bytes in each word and do everything big-endian or reverse the bits in each byte and do it little-endian. Which do you do?
> 
> Sure, I could figure it out by reading the code, but please say.

Hi Andrew

I would like to understand if I have fully understood your comment. 

Currently the load instruction takes care of the endianness ,for subkey and state. For loading the data, we enforce the endianness and reorder the bytes order using vec_perm.
vec_perm(vH, vHigh, vLow, loadOrder);

I am assuming  the inputs for GHASH follows the endianness as per the algorithm, as you have mentioned.  I have made sure they are in the appropriate intended representation for both LE and BE platforms(using vec_perm and appropriate load instructions)

In the algorithm that I have used , 0xC2 is the polynomial for reduction. 

It is  shifted  by 56 bits to make It the most significant byte. I think this is little endian byte order  ? 
I just had to do the operations with the reduction polynomial to align it as per the algorithm.

I did not do any extra swapping for the subkey ,state vector and input. 

Is this what you are looking for ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2593425586

From aph at openjdk.org  Wed Jan 15 18:31:38 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 15 Jan 2025 18:31:38 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <Wjnz_Vw8UvJbj0sftKS2Fn9ivJlKyWVk4XSMMod48cw=.dd48bdf1-1038-4912-b3ce-28853a8de10a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
 <W6x-htemcgUrhZXpzllqxD8azf9eglIvLlgrlqQTxYs=.84f59b57-3a55-4363-997f-13aee029c21b@github.com>
 <Wjnz_Vw8UvJbj0sftKS2Fn9ivJlKyWVk4XSMMod48cw=.dd48bdf1-1038-4912-b3ce-28853a8de10a@github.com>
Message-ID: <Q5-xoCGdFchEp3ENLtFdMsuddQDgdvim6h9vSMb_JpU=.e9bc9f05-fee4-4225-8e9e-1782cc7d065e@github.com>

On Wed, 15 Jan 2025 16:45:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > The commenting here is poor.
> > GHASH uses little-endian for the byte order, but big-endian for the bit order. For example, the polynomial 1 is represented as the 16-byte string 80 00 00 00 | 12 bytes of 00. So, we must either reverse the bytes in each word and do everything big-endian or reverse the bits in each byte and do it little-endian. Which do you do?
> > Sure, I could figure it out by reading the code, but please say.
> 
> Hi Andrew
> 
> I would like to understand if I have fully understood your comment.
> 
> Currently the load instruction takes care of the endianness ,for subkey and state. For loading the data, we enforce the endianness and reorder the bytes order using vec_perm. vec_perm(vH, vHigh, vLow, loadOrder);

> I am assuming the inputs for GHASH follows the endianness as per the algorithm, as you have mentioned. I have made sure they are in the appropriate intended representation for both LE and BE platforms(using vec_perm and appropriate load instructions)
> 
> In the algorithm that I have used , 0xC2 is the polynomial for reduction.
>
> It is shifted by 56 bits to make It the most significant byte. I think this is little endian byte order ? I just had to do the operations with the reduction polynomial to align it as per the algorithm.

Right, so in this implementation the low-order bits of the field polynomial (i.e. p = z^7+z^2+z+1) are represented as 0xC2, or 11000010.  But you will note that there is a bit missing here. the low-order bits of the field polynomial should have four bits set. And in GHASH.java in the JDK, 0xe100000000000000 is used, which is a bit more obvious.

I think you're using the trick described in Intel's _Optimized Galois-Counter-Mode Implementation on Intel? Architecture Processors_, which represents the polynomial in a shifted form as, in effect, `1:C200000000000000`. 
Unfortunately, the constant `vConstC2` does not appear anywhere in this PR, so I had no way to know that. I guess that this PR does not even compile.

The main problem is, though, that there is little commentary in the code which explains how things are encoded. If you're using a bit-reversed and shifted representation of a polynomial, you have to say that. If youre using the algorithm described in the Intel paper, you have to say that too. Have pity on the reader.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2593664404

From lmesnik at openjdk.org  Wed Jan 15 19:32:36 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 Jan 2025 19:32:36 GMT
Subject: RFR: 8338428: Print final VM flags for task [v2]
In-Reply-To: <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
Message-ID: <RHKA7_SpT6F6bIxoBWETqVOq3xlAiFcV5BhndYq6UdU=.0dbfec3d-a0e1-496c-872b-b4e6aa548df3@github.com>

On Sun, 12 Jan 2025 15:47:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The test lib is not ued

Ough, I misread your question.  I though that you are asking if it is executed even the only one single test is run. 
This code is executed only one per task, not per test. So overall increase is very small, less then 0.1%

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2593770661

From coleenp at openjdk.org  Wed Jan 15 19:35:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 19:35:57 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <G3e6PEnYZwImOskdjoPd73biTEqN3hbRz-p7OfRGatY=.fa6793a3-2718-4129-b0be-cc681e523f1c@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

I'm glad that this could use Mutex in the end and not use the PlatforMutex.  If all else fails though, the way this is structured could use PlatformMutex as the underlying implementation and that would be okay.  Removing the use of ThreadCritical is the motivating part of this change.
I've downloaded the patch and am running tier1-7 on it.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2553722161

From mdoerr at openjdk.org  Wed Jan 15 20:41:39 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Jan 2025 20:41:39 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
Message-ID: <CVKWUhapxdYAvfu6bigfK_GmOdgN7dYmCl-QYgtNNaY=.e640c0d9-0364-4a1b-b6af-c9f3cac8b3c2@github.com>

On Thu, 9 Jan 2025 09:07:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 680:

> 678:   __ li(temp1, 0xc2);
> 679:   __ sldi(temp1, temp1, 56);
> 680:   __ vxor(vZero, vZero, vZero);

I think `vspltisb(vZero, 0);` would be better readable (and also avoid an unnecessary data dependency on a previous instruction using the same register).

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 681:

> 679:   __ sldi(temp1, temp1, 56);
> 680:   __ vxor(vZero, vZero, vZero);
> 681:   // Load the vector from memory into vConstC2

This comment is not correct. It's not loaded from memory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1917304528
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1917303293

From matsaave at openjdk.org  Wed Jan 15 21:14:37 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 15 Jan 2025 21:14:37 GMT
Subject: RFR: 8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories
In-Reply-To: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
References: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
Message-ID: <ioMqef6biEKCYmzSBU0DghK-pjQegtX6_rGLZOEsio0=.b9a963c7-d1fd-436d-9a61-01a91dd6bfd8@github.com>

On Tue, 14 Jan 2025 14:56:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the os, os_cpu and cpu directories.  There weren't very many.  Most was done with a script with very little hand-editing.  Added 2 whitespaces in arm.ad.
> Tested just now with tier1-4 on x86 and aarch64, GHA for the rest.

Changes look good, I have a few questions and considerations:

src/hotspot/os/aix/os_aix.cpp line 636:

> 634:     address high_address = thread->stack_base();
> 635:     lt.print("Thread is alive (tid: %zu, kernel thread id: %zu"
> 636:              ", stack [" PTR_FORMAT " - " PTR_FORMAT " (%zuk using %luk pages)).",

Is `%lu` compatible with multiple platforms or should it also be changed to `%zu`?

src/hotspot/os/aix/os_aix.cpp line 1760:

> 1758: static void warn_fail_commit_memory(char* addr, size_t size, bool exec,
> 1759:                                     int err) {
> 1760:   warning("INFO: os::commit_memory(" PTR_FORMAT ", %zu"

I think you can merge `"%zu"` with `", %d) failed; error='%s' (errno=%d)"` in the same quotes

src/hotspot/os/linux/os_linux.cpp line 2886:

> 2884: static void warn_fail_commit_memory(char* addr, size_t size, bool exec,
> 2885:                                     int err) {
> 2886:   warning("INFO: os::commit_memory(" PTR_FORMAT ", %zu"

Same here

src/hotspot/os/linux/os_linux.cpp line 2894:

> 2892:                                     size_t alignment_hint, bool exec,
> 2893:                                     int err) {
> 2894:   warning("INFO: os::commit_memory(" PTR_FORMAT ", %zu"

And here

-------------

PR Review: https://git.openjdk.org/jdk/pull/23106#pullrequestreview-2553946520
PR Review Comment: https://git.openjdk.org/jdk/pull/23106#discussion_r1917330038
PR Review Comment: https://git.openjdk.org/jdk/pull/23106#discussion_r1917331735
PR Review Comment: https://git.openjdk.org/jdk/pull/23106#discussion_r1917337268
PR Review Comment: https://git.openjdk.org/jdk/pull/23106#discussion_r1917337380

From coleenp at openjdk.org  Wed Jan 15 22:45:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 22:45:09 GMT
Subject: RFR: 8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories
 [v2]
In-Reply-To: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
References: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
Message-ID: <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>

> Please review this change to replace SIZE_FORMAT with %zu in the os, os_cpu and cpu directories.  There weren't very many.  Most was done with a script with very little hand-editing.  Added 2 whitespaces in arm.ad.
> Tested just now with tier1-4 on x86 and aarch64, GHA for the rest.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Reformatting suggestions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23106/files
  - new: https://git.openjdk.org/jdk/pull/23106/files/640eb79a..47d7fe6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23106&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23106&range=00-01

  Stats: 9 lines in 2 files changed: 0 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23106.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23106/head:pull/23106

PR: https://git.openjdk.org/jdk/pull/23106

From coleenp at openjdk.org  Wed Jan 15 22:45:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 22:45:09 GMT
Subject: RFR: 8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories
 [v2]
In-Reply-To: <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>
References: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
 <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>
Message-ID: <R9JeRnz-wISkZSJxM9xXkSnMFEBbQegMgDHkXJk9jWM=.5fc84dfd-b9e5-4db9-a8cd-a2bd1d2d0a94@github.com>

On Wed, 15 Jan 2025 22:42:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the os, os_cpu and cpu directories.  There weren't very many.  Most was done with a script with very little hand-editing.  Added 2 whitespaces in arm.ad.
>> Tested just now with tier1-4 on x86 and aarch64, GHA for the rest.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformatting suggestions.

@matias9927  Thank you for the reformatting suggestions.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23106#pullrequestreview-2554184446

From coleenp at openjdk.org  Wed Jan 15 22:45:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 22:45:09 GMT
Subject: RFR: 8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories
 [v2]
In-Reply-To: <ioMqef6biEKCYmzSBU0DghK-pjQegtX6_rGLZOEsio0=.b9a963c7-d1fd-436d-9a61-01a91dd6bfd8@github.com>
References: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
 <ioMqef6biEKCYmzSBU0DghK-pjQegtX6_rGLZOEsio0=.b9a963c7-d1fd-436d-9a61-01a91dd6bfd8@github.com>
Message-ID: <Uz2ucqVbBDowHm9-e2dZyG9chSgushkU27V_yBldmvI=.766cf967-4e03-49ce-a0d8-0d942bd99b94@github.com>

On Wed, 15 Jan 2025 21:01:14 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reformatting suggestions.
>
> src/hotspot/os/aix/os_aix.cpp line 636:
> 
>> 634:     address high_address = thread->stack_base();
>> 635:     lt.print("Thread is alive (tid: %zu, kernel thread id: %zu"
>> 636:              ", stack [" PTR_FORMAT " - " PTR_FORMAT " (%zuk using %luk pages)).",
> 
> Is `%lu` compatible with multiple platforms or should it also be changed to `%zu`?

I think aix only supports a 64 bit platform, so this format specifier is probably right for that.  I'm not going to change pre-existing formatting for aix without being able to test it.

> src/hotspot/os/linux/os_linux.cpp line 2886:
> 
>> 2884: static void warn_fail_commit_memory(char* addr, size_t size, bool exec,
>> 2885:                                     int err) {
>> 2886:   warning("INFO: os::commit_memory(" PTR_FORMAT ", %zu"
> 
> Same here

Fixed - reformatted.

> src/hotspot/os/linux/os_linux.cpp line 2894:
> 
>> 2892:                                     size_t alignment_hint, bool exec,
>> 2893:                                     int err) {
>> 2894:   warning("INFO: os::commit_memory(" PTR_FORMAT ", %zu"
> 
> And here

Also reformatted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23106#discussion_r1917424913
PR Review Comment: https://git.openjdk.org/jdk/pull/23106#discussion_r1917428613
PR Review Comment: https://git.openjdk.org/jdk/pull/23106#discussion_r1917428572

From lmesnik at openjdk.org  Wed Jan 15 23:53:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 Jan 2025 23:53:54 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings
Message-ID: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>

There few compiler warning disabled in the testlibary build.
They should be fixed or localized and removed from build to prevent new possible issues.

The main goal is to avoid new such issues in the testlibrary. 
Tested with tier1-5 to ensure that all tests were passed.

-------------

Commit messages:
 - copyrights updates
 - dangling fixed
 - Merge branch 'master' of https://github.com/openjdk/jdk into warnings
 - restricted removed
 - cast removed
 - deprecation remove
 - try removed
 - preview reviewed
 - serial removed
 - rawtypes removed
 - ... and 2 more: https://git.openjdk.org/jdk/compare/a3be97e2...ae302c9c

Changes: https://git.openjdk.org/jdk/pull/23143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347840
  Stats: 86 lines in 30 files changed: 23 ins; 4 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/23143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23143/head:pull/23143

PR: https://git.openjdk.org/jdk/pull/23143

From dholmes at openjdk.org  Thu Jan 16 01:47:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Jan 2025 01:47:35 GMT
Subject: RFR: 8338428: Print final VM flags for task [v2]
In-Reply-To: <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <ylgIHF21gctVz7NU78kaJtMkdynniw0zviJqvzbp3sI=.25c44f4b-5693-46d3-b0e4-ae296ed0e834@github.com>
Message-ID: <wDD6X5FScsMMuDiS8KteFuAczUb99eqmUQg8p2P1mxk=.168f27ed-2547-4610-8543-0ed8e2a83725@github.com>

On Sun, 12 Jan 2025 15:47:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The test lib is not ued

So it is once per run of jtreg effectively? Even so while the cost to the test task is negligible the accumulated cost in machine time (which someone is paying for) is not. Everything else in `VMProps` queries the VM running `VMProps` and this should do the same. We should add a whitebox API to either retrieve, or directly dump, the final flags values.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2594292192

From dholmes at openjdk.org  Thu Jan 16 03:00:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Jan 2025 03:00:34 GMT
Subject: RFR: 8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories
 [v2]
In-Reply-To: <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>
References: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
 <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>
Message-ID: <Y_CnPmJKePj2XyQ03u0fR-zWvcuylcRGD7QXi6byqJ8=.09c756be-cb79-43fd-a1ce-8588b8076e82@github.com>

On Wed, 15 Jan 2025 22:45:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the os, os_cpu and cpu directories.  There weren't very many.  Most was done with a script with very little hand-editing.  Added 2 whitespaces in arm.ad.
>> Tested just now with tier1-4 on x86 and aarch64, GHA for the rest.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformatting suggestions.

LGTM.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23106#pullrequestreview-2554611240

From lmesnik at openjdk.org  Thu Jan 16 05:03:37 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 05:03:37 GMT
Subject: RFR: 8338428: Print final VM flags for task [v3]
In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
Message-ID: <3b7uuxwigBtyIVY7gbrPCzBdCbgfAs0o-c3P2zO6bcU=.3d09f362-0752-4d75-b222-980a41c39692@github.com>

> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
> 
> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
> 
> Update:
> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.

Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:

 - seconnd attempt
 - Revert "updated VMProps"
   
   This reverts commit 6af3f1c6d72353ec5d40b9d1fde05771ef102141.
 - Revert "The test lib is not ued"
   
   This reverts commit 919c870e0475597f4128b663c3f303ae56d06e1c.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23054/files
  - new: https://git.openjdk.org/jdk/pull/23054/files/919c870e..d2f3b1c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=01-02

  Stats: 37 lines in 3 files changed: 4 ins; 32 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23054/head:pull/23054

PR: https://git.openjdk.org/jdk/pull/23054

From lmesnik at openjdk.org  Thu Jan 16 05:07:36 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 05:07:36 GMT
Subject: RFR: 8338428: Print final VM flags for task [v3]
In-Reply-To: <3b7uuxwigBtyIVY7gbrPCzBdCbgfAs0o-c3P2zO6bcU=.3d09f362-0752-4d75-b222-980a41c39692@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <3b7uuxwigBtyIVY7gbrPCzBdCbgfAs0o-c3P2zO6bcU=.3d09f362-0752-4d75-b222-980a41c39692@github.com>
Message-ID: <JVz7GigVHiEI7dmUExlLHkqfxgyyfXw4sdHEl70U6AQ=.20e17f46-22b8-46e4-b6e0-ad892a2f4527@github.com>

On Thu, 16 Jan 2025 05:03:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - seconnd attempt
>  - Revert "updated VMProps"
>    
>    This reverts commit 6af3f1c6d72353ec5d40b9d1fde05771ef102141.
>  - Revert "The test lib is not ued"
>    
>    This reverts commit 919c870e0475597f4128b663c3f303ae56d06e1c.

This trick should work. 
When jtreg execute GetJDKProperties  VMProps to know properties to rrequires, it parse input and supress sterr. It requires too much changes to update it's output in the backward compatible way. 
So the simplest fix would be to dump whol VM output with final flags into a file.
While it is possible to add WB API for this, I would prefer to don't add code if possible to avoid this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2594545026

From dholmes at openjdk.org  Thu Jan 16 06:09:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Jan 2025 06:09:46 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <lsAg7A_4Wkr7BWfLvnphoYVU1Fjh0TtwJZJesLHZYFo=.c95180c4-2970-48a2-95ca-ccf26c2b61b4@github.com>

On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

Overall looks good - sometimes a bit of a puzzler understanding what warning is being addressed. :)

Only one thing I'm concerned may be an issue. Also a couple of suggestions.

Thanks

test/lib/jdk/test/lib/format/ArrayDiff.java line 110:

> 108:      * @return an ArrayDiff instance for the two arrays and formatting parameters provided
> 109:      */
> 110:     @SuppressWarnings({"rawtypes", "unchecked"})

Just wondering where the unchecked warning arises in the code?

test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java line 42:

> 40:  *
> 41:  * @author      Bill Foote
> 42:  */

I would suggest deleting any comment blocks that just have the @author tag, and deleting the @author elsewhere. All these files (lib/hprof) already have an author attribution comment.

test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46:

> 44:     public int   getInt(long pos) throws IOException;
> 45:     public long  getLong(long pos) throws IOException;
> 46:     public void  close() throws IOException;

Why was this redefined to throw IOException rather than just Exception?

test/lib/jdk/test/lib/hprof/parser/Reader.java line 96:

> 94:             } else if ((i >>> 8) == GZIP_HEADER_MAGIC) {
> 95:                 // Possible gziped file, try decompress it and get the stack trace.
> 96:                 in.close();

It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below.

test/lib/jdk/test/lib/hprof/parser/Reader.java line 169:

> 167:             } else if ((i >>> 8) == GZIP_HEADER_MAGIC) {
> 168:                 // Possible gziped file, try decompress it and get the stack trace.
> 169:                 in.close();

It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below.

test/lib/jdk/test/lib/thread/VThreadRunner.java line 100:

> 98:             if ((X) ex == ex) {
> 99:                 throw (X) ex;
> 100:             }

This doesn't make sense to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2554831705
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917773365
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917775999
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917780287
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917795069
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917795554
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917787207

From lmesnik at openjdk.org  Thu Jan 16 06:12:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 06:12:01 GMT
Subject: RFR: 8338428: Print final VM flags for task [v4]
In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
Message-ID: <06Gdh-fXZSsqpkcB0egI96b0suKcHLVzTxD-3HxsE3Y=.5bcc12ed-876a-4c23-832b-8c3a99b1b728@github.com>

> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
> 
> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
> 
> Update:
> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Added diagnostic flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23054/files
  - new: https://git.openjdk.org/jdk/pull/23054/files/d2f3b1c2..28b05e9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23054/head:pull/23054

PR: https://git.openjdk.org/jdk/pull/23054

From dholmes at openjdk.org  Thu Jan 16 06:29:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Jan 2025 06:29:51 GMT
Subject: RFR: 8338428: Print final VM flags for task [v4]
In-Reply-To: <06Gdh-fXZSsqpkcB0egI96b0suKcHLVzTxD-3HxsE3Y=.5bcc12ed-876a-4c23-832b-8c3a99b1b728@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <06Gdh-fXZSsqpkcB0egI96b0suKcHLVzTxD-3HxsE3Y=.5bcc12ed-876a-4c23-832b-8c3a99b1b728@github.com>
Message-ID: <TEugq3zRWBgnCIVMEAps---SAOrSC0lKEOW5JOXgul0=.f0b15935-5c4c-42aa-9114-28103ecb2c8d@github.com>

On Thu, 16 Jan 2025 06:12:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added diagnostic flag

Can flags supplied by a test, or the user, interfere with that invocation?

Do you really want the xml format for this file?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23054#pullrequestreview-2554893748

From alanb at openjdk.org  Thu Jan 16 07:12:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Jan 2025 07:12:36 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <ZzZgrVk1z_5JOOT-3buuPQ-kj_PhXx0iOzpVolbtJLc=.419a6c89-71c4-4342-94fa-54775c63a873@github.com>

On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

test/lib/jdk/test/lib/thread/VThreadPinner.java line 97:

> 95:      * virtual thread then it invokes the task directly.
> 96:      */
> 97:     @SuppressWarnings("unchecked")

If you change the code to the follow, same in VThreadRunner then it would avoid the the SW on the method and avoid the other change you have to VThreadRunner.

            @SuppressWarnings("unchecked")
            var x = (X) ex;
            throw x;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917853893

From stuefe at openjdk.org  Thu Jan 16 08:24:46 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Jan 2025 08:24:46 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
 <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
 <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
Message-ID: <FTwbtnmXiZP6yLV1TXBICU3k7ojzv-IX0oMNEWfpDsY=.c0841386-7ef8-4edc-ae52-4e5664ba699b@github.com>

On Mon, 13 Jan 2025 13:00:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>>> Thinking about this some more, the fact that tree nodes are allocated internally and are separate entities from the key/value holders precludes the using this tree for memory management (address stable or not). It works, but the separate allocation defeats the purpose. It would be good if, on `upsert`, I could hand in optionally the future node memory itself, and the node should then be placed into/at the start of this memory. And it must be able to deal with the handed-in node memory be variable-sized, of course.
>> 
>> Or, much simpler, let me construct the node itself and hand it into the tree.
>
> Hi @tstuefe ,
> 
>>Consider this scenario: I want to have two short-lived trees, nodes live longer than their trees they temporarily occupy, and I want the nodes to reside in physically different preallocated pools. I want to use the same allocator and tree classes, though, so template parameters must be the same.
> 
>>There are two ways to do this. The most obvious would be to keep a reference to an allocator instance that the caller hands in via constructor. So, make _allocator a pointer, and if omitted by the caller use your own C-heap allocator. Otherwise, use the caller's allocator.
> 
> Or you have a reference as the template type and you alter the constructor of the `RBTree` to take such a type to construct its own allocator with.
> 
> It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
> 
> I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes. You could also, for example, avoid the cost of freeing separate elements and eliminate the whole tree at once when the lifetime of the tree has ended (since the lifetime of the allocator is identical). In short: When your tree isn't intrusive, it's very nice to have a custom allocator.
> 
> For your use case, you basically need a very similar addition to the API. It'd look something like this in pseudo-code:
> 
> ```c++
> // I hold the data, but the node holds the key
> struct IntrusiveHolder {
>   int data;
>   RBNode node;
>   static IntrusiveHolder* cast_to_self(RBNode* node) ; // offset_of() magic
> };
> 
> struct Compare {
>   int cmp(int a, int b);
> }
> 
> template<typename K, typename V, typename Cmp, typename Allocator>
> struct RBTree{
> public:
>   enum Dir { left, right };
>   // Describes the parent node and whether the next node is to be inserted on the left or the right.
>   struct InsertionCursor {
>    RBNode* parent; Dir dir;
>    RBNode* position(); // Get the node (potentially nullptr)
>   };
> 
>   // Walks the tree in the obvious order, using Comparator::cmp overload to find the place to insert.
>   // However does not allocate.
>   InsertionCursor find_insertion_point(K k);
>   // Inserts the node at the position and rebalances the tree.
>   void insert_at_cursor(InsertionCursor, RBNode* node);
> 
>   // For removals we need to unlink the node from the tree, but keep it alive and then just return the pointer.
>   RBNode*...

Hi @jdksjolen, @caspernorrbin 

sorry for the delay, work is piled up.

> 
> It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.

intrusive - I did not know this term, even though I wrote containers like this all my life, go figure :-). 

Yes, that's precisely what I want.

- I want to create/store nodes myself 
- I want to avoid copying node content; in fact, I don't want to even bother with assignment operators.
- I want to be able to add child nodes to a node to handle duplicates if my tree allows duplicates (which is of no concern to the tree, but since these child nodes should live in the same pool, again, my wish for wanting to create nodes myself)

All of this points to a tree where I manage the node myself. So, have a function to find a reference to an existing node by key and have a function to hand in a node for storage. Pretty much like you line it out in your example:


MyTree::add_my_bulky_and_possible_varsized_node(Node* n) {
	- find node n2 with key n->key
		- found? Add n as child node under n2
		- not found? add n as new node
}


I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.


> 
> I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes.

You lost me here

> You could also, for example, avoid the cost of freeing separate elements and eliminate the whole tree at once when the lifetime of the tree has ended (since the lifetime of the allocator is identical).

This is not a strong argument though, since when I create the allocator outside the tree, I can let it die in the same fashion when the tree dies. This is what I plan to do. But as you wrote, we should allow both intrusive and non-intrusive.

> Casper already is working on supporting an intrusive RBTree with an API similar to what I sketched out above, but I'd like it if we can integrate the current version of the tree as it is. With this change we can already remove the NMT Treap and replace it, so that's a nice use case. Plus, there'll always be new features, we can't wait with integration until all possible features are implemented :).

Hmm, okay. I'll give the patch a closer look later today and then approve it unless I find something.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2594803275

From stuefe at openjdk.org  Thu Jan 16 09:35:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Jan 2025 09:35:43 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
 <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
 <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
Message-ID: <4Xfx55iO6NURzJRu6JR80U9vxgVukN5Pw1MsGDQNFvM=.69f93443-ce74-4649-be96-d7769d8e77fd@github.com>

On Wed, 4 Dec 2024 12:21:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.
>
> I think the case for making the whole thing in a header depends on how much code there is, that's all.

@theRealAph 

> Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.

But for that the compiler must see the implementation of the functions, right? So, we cannot move the implementation into a cpp file?

We can move it into an inline header, like we usually do. Which serves much of the same purpose.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918123566

From duke at openjdk.org  Thu Jan 16 09:46:48 2025
From: duke at openjdk.org (Yuri Gaevsky)
Date: Thu, 16 Jan 2025 09:46:48 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
In-Reply-To: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
Message-ID: <Jodc20oFtZQYSmn3MnPvYBNltFaNabEVmmTNWXDI2F4=.79d62875-82c8-451b-a54d-a87408087164@github.com>

On Wed, 7 Feb 2024 14:35:55 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

> Hello All,
> 
> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
> 
> Thank you,
> -Yuri Gaevsky
> 
> **Correctness checks:**
>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.

.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-2595032555

From stefank at openjdk.org  Thu Jan 16 10:14:36 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Jan 2025 10:14:36 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <sE1FRHSWW7iVRm15iO3cJHbf6gkDf9HFY9oe5oSDtlk=.4f1fef79-b0b4-4188-8cd5-080fa9702d30@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

Thanks for the reviews!

Shenandoah devs, what should I do about the comment I added in shenandoahHeap.cpp? Do you want to handle that in this patch, should I leave the comment, or should I remove it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22825#issuecomment-2595108090

From shade at openjdk.org  Thu Jan 16 10:16:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 16 Jan 2025 10:16:40 GMT
Subject: RFR: 8337978: Verify OopHandles oops on access
In-Reply-To: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>
References: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>
Message-ID: <HaSGoMm64nccMMQ9jSSQOkwJSz6V1lgkGiPG4B-1FIU=.460fc72c-7b20-41fb-8b52-cfa7d50ef739@github.com>

On Fri, 10 Jan 2025 17:32:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Detecting failures like [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941) would be more convenient if we verified the oops we put/get to/from `OopHandles`-s explicitly. This will stop the leakage of incorrect oops (e.g. bad Java klass mirrors seen in [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941)) to the runtime.
> 
> I was curious how this affects testing time, and I cannot see a big difference at least on `tier1`:
> 
> 
> # Baseline
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60427.40s user 4604.67s system 3775% cpu 28:42.39 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  61364.50s user 4563.23s system 3806% cpu 28:52.20 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60192.57s user 4610.89s system 3788% cpu 28:30.51 total
> 
> # With OopHandle verification
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60410.88s user 4601.52s system 3740% cpu 28:58.20 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60389.57s user 4572.23s system 3752% cpu 28:50.96 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60845.41s user 4578.50s system 3757% cpu 29:01.08 total
> 
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier1`
>  - [x] Linux AArch64 server fastdebug, `all`
>  - [x] Linux x86_64 server fastdebug, `all`

Thanks for reviews! The testing looks clean here, so I am integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23043#issuecomment-2595111471

From shade at openjdk.org  Thu Jan 16 10:16:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 16 Jan 2025 10:16:40 GMT
Subject: Integrated: 8337978: Verify OopHandles oops on access
In-Reply-To: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>
References: <9O1UZB4OnvG4TaIXEGFzVcEKIm-TTaqJkWSn957eZQI=.656e6500-5158-45a0-bdcf-edd2f55529c9@github.com>
Message-ID: <68zJSVw-VHGCctcHb5jhPpf2tmBTr-4drAjBN-tx-yw=.d7a9f5a8-9ead-44b0-8a38-6bdf84fb63a2@github.com>

On Fri, 10 Jan 2025 17:32:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Detecting failures like [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941) would be more convenient if we verified the oops we put/get to/from `OopHandles`-s explicitly. This will stop the leakage of incorrect oops (e.g. bad Java klass mirrors seen in [JDK-8337941](https://bugs.openjdk.org/browse/JDK-8337941)) to the runtime.
> 
> I was curious how this affects testing time, and I cannot see a big difference at least on `tier1`:
> 
> 
> # Baseline
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60427.40s user 4604.67s system 3775% cpu 28:42.39 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  61364.50s user 4563.23s system 3806% cpu 28:52.20 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60192.57s user 4610.89s system 3788% cpu 28:30.51 total
> 
> # With OopHandle verification
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60410.88s user 4601.52s system 3740% cpu 28:58.20 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60389.57s user 4572.23s system 3752% cpu 28:50.96 total
> CONF=linux-aarch64-server-fastdebug make test TEST=tier1  60845.41s user 4578.50s system 3757% cpu 29:01.08 total
> 
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier1`
>  - [x] Linux AArch64 server fastdebug, `all`
>  - [x] Linux x86_64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: d23ad013
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d23ad01319ba298cc0ddcc2424abac8071840338
Stats:     24 lines in 1 file changed: 20 ins; 0 del; 4 mod

8337978: Verify OopHandles oops on access

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/23043

From aboldtch at openjdk.org  Thu Jan 16 11:12:50 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 16 Jan 2025 11:12:50 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
Message-ID: <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>

On Fri, 10 Jan 2025 10:03:22 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified comment

Good work on the RB-tree implementation.

I am no expert in RB-trees but the implementation does not look obviously incorrect. And the gtest and verification looks comprehensive. (Only thing I might have extended is to randomness to also check the visitor and iterators. Something like generating a random ordered set of keys in a different container, insert them in some random order, maybe including insertions and removals of other keys and then check that the visitor and iterator visit this set correctly.) 

The RB-tree logic looks good to me.

Except for some small nits most of my feedback is about the API and the iteration.

I would like to avoid GrowableArrays in the implementation, but maybe I am missing a reason why they are preferable. If we could design the iterators to work more like standard C++ iterators (at least simplified but compatible versions) would make them more useful and ergonomic. There is also an opportunity to use such iterators as cursors and create a nice interface for using this tree in many different scenarios.

The second is if we should add more const version of the APIs to make it easier to work with the tree in const context (e.g. pass around the tree as a `const& Tree`). At least `const V* find(const K& key) const` seems useful to have a const `contains`.

Overall I think this is nice. But I would like some feedback on my comments w.r.t. the API before approving.

src/hotspot/share/utilities/rbTree.hpp line 119:

> 117:     _allocator.free(node);
> 118:     _num_nodes--;
> 119:   }

Are we assuming that the key is always trivially destructible? Maybe we should document and statically assert this. Even if it is not, it is usually nice to call the destructor to end the objects lifetime.

src/hotspot/share/utilities/rbTree.hpp line 167:

> 165:   // Removes the given node from the tree.
> 166:   // Returns true if the node was successfully removed, false otherwise.
> 167:   bool remove(RBNode* node);

I find it confusing that removing a node can fail. It seems to be to handle `nullptr`. I'd rather restrict this and have `bool remove(const K& k)` check the return value of `find_node`.

src/hotspot/share/utilities/rbTree.hpp line 183:

> 181:     _num_nodes = 0;
> 182:     _root = nullptr;
> 183:   }

I feel like this could have been done recursively and using the stack as a stack. Or at least skip the heap allocation with fixed sized array `RBNode* stack[128];`.

src/hotspot/share/utilities/rbTree.hpp line 236:

> 234:     RBNode* end = closest_gt(addr);
> 235:     return Range(start, end);
> 236:   }

This seems somewhat out of place. The signature is miss-matched from all the other APIs both in terms of the name and type.

I am wrong in that end is always the next node after start? I think the closest_gt call is unnecessary and we can simply find the next node after start.

src/hotspot/share/utilities/rbTree.hpp line 273:

> 271:     NONCOPYABLE(IteratorImpl);
> 272: 
> 273:     IteratorImpl(const RBTree* tree) : _tree(tree) {

Given that our tree node have a parent pointer. I wonder why this is implemented with a GrowableArray rather than just keeping track of a node and walking the tree on next / previous. (Are we afraid that the pointer chasing back up the tree will be to costly? It seems very rare that you walk up the tree without also dereferencing the data)

This would have multiple benefits. We could make it O(1) space rather than O(log(n)).
I think the biggest benefit is that it can be copy constructible and assignable making it much easier to work with including making it easily adaptable to work like a C++ iterator so that we can have begin() and end(), ranged for loops. Many of the APIs like find, enclosing range, visit etc could be implemented in terms of these, making it less cumbersome to design external algorithms which interacts with the tree rather than having to extend the functionality on the tree directly. It also makes iterators usable while inserting in the tree.

Johan talk about using a cursor to enable inserts and removals (to for example enable an intrusive node). I think we could also design an API which achieves the same with iterators. 
```c++
auto it = tree.find_leq(key);
if (cmp(key, *it) != 0) {
  Node* node = get_intrusive_node(key);
  tree.insert(it, node);
} else {
  Node* node = *it;
  // Update node inplace or maybe replace it with a new intrusive node.
}

src/hotspot/share/utilities/rbTree.inline.hpp line 444:

> 442: template <typename K, typename V, typename COMPARATOR, typename ALLOCATOR>
> 443: template <typename F>
> 444: inline void RBTree<K, V, COMPARATOR, ALLOCATOR>::visit_range_in_order(const K& from, const K& to, F f) {

This could be written in terms of `closest_leq` and `closest_gt` and just walk the tree between these nodes, and only do `O(log(n))` `CMP` calls instead of `O(log(n) + log(k))` where `k` is the size of the node range.

src/hotspot/share/utilities/rbTree.inline.hpp line 525:

> 523: }
> 524: 
> 525: #endif // SHARE_UTILITIES_RBTREE_INLINE_HPP

Missing new line
Suggestion:

#endif // SHARE_UTILITIES_RBTREE_INLINE_HPP

test/hotspot/gtest/utilities/test_rbtree.cpp line 68:

> 66: public:
> 67:   void inserting_duplicates_results_in_one_value() {
> 68:     constexpr const int up_to = 10;

`constexpr const` looks strange to me.
Suggestion:

    constexpr int up_to = 10;

test/hotspot/gtest/utilities/test_rbtree.cpp line 111:

> 109:     };
> 110: 
> 111:     constexpr const int up_to = 10;

Suggestion:

    constexpr int up_to = 10;

test/hotspot/gtest/utilities/test_rbtree.cpp line 345:

> 343: 
> 344:     void test_iterator() {
> 345:     constexpr const int num_nodes = 100;

Suggestion:

    constexpr int num_nodes = 100;

test/hotspot/gtest/utilities/test_rbtree.cpp line 458:

> 456: 
> 457: TEST_VM_F(RBTreeTest, InsertRemoveVerify) {
> 458:   constexpr const int num_nodes = 100;

Suggestion:

  constexpr int num_nodes = 100;

test/hotspot/gtest/utilities/test_rbtree.cpp line 476:

> 474:   { // Repeatedly verify a tree of moderate size
> 475:     RBTreeInt rbtree;
> 476:     constexpr const int ten_thousand = 10000;

Suggestion:

    constexpr int ten_thousand = 10000;

test/hotspot/gtest/utilities/test_rbtree.cpp line 503:

> 501:   struct Nothing {};
> 502:     RBTreeCHeap<int, Nothing, Cmp, mtOther> rbtree;
> 503:     constexpr const int one_hundred_thousand = 100000;

Suggestion:

    constexpr int one_hundred_thousand = 100000;

-------------

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2554941459
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1917844013
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1917848967
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1917858528
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1917952102
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1917889019
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918205042
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1917912263
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918207402
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918207817
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918208223
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918208506
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918208806
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918209157

From aboldtch at openjdk.org  Thu Jan 16 11:12:50 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 16 Jan 2025 11:12:50 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
Message-ID: <00XoZuuL7TwIyfS86NNSV5SJaswDgHu7HC6rUZK44Ys=.c2ad7bf5-8405-49dd-a35d-1f940e96f950@github.com>

On Thu, 16 Jan 2025 06:58:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified comment
>
> src/hotspot/share/utilities/rbTree.hpp line 119:
> 
>> 117:     _allocator.free(node);
>> 118:     _num_nodes--;
>> 119:   }
> 
> Are we assuming that the key is always trivially destructible? Maybe we should document and statically assert this. Even if it is not, it is usually nice to call the destructor to end the objects lifetime.

I saw that this was discussed further down.

> src/hotspot/share/utilities/rbTree.hpp line 183:
> 
>> 181:     _num_nodes = 0;
>> 182:     _root = nullptr;
>> 183:   }
> 
> I feel like this could have been done recursively and using the stack as a stack. Or at least skip the heap allocation with fixed sized array `RBNode* stack[128];`.

Can probably do this for a lot of the other iteration done in this patch. I would think for most we would only need 64 entries. And even this could be written to just use at most a stack depth of 64.

> src/hotspot/share/utilities/rbTree.hpp line 236:
> 
>> 234:     RBNode* end = closest_gt(addr);
>> 235:     return Range(start, end);
>> 236:   }
> 
> This seems somewhat out of place. The signature is miss-matched from all the other APIs both in terms of the name and type.
> 
> I am wrong in that end is always the next node after start? I think the closest_gt call is unnecessary and we can simply find the next node after start.

Also note that this is not tested in the gtest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1917890551
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918200769
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918210898

From aph at openjdk.org  Thu Jan 16 11:24:38 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Jan 2025 11:24:38 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <CVKWUhapxdYAvfu6bigfK_GmOdgN7dYmCl-QYgtNNaY=.e640c0d9-0364-4a1b-b6af-c9f3cac8b3c2@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
 <CVKWUhapxdYAvfu6bigfK_GmOdgN7dYmCl-QYgtNNaY=.e640c0d9-0364-4a1b-b6af-c9f3cac8b3c2@github.com>
Message-ID: <7fKapa07x20xXIZAkpkVAPgyfcfri08g933Ri2Wx6a0=.85be79db-a081-4248-b5ee-e3c5c49a7ade@github.com>

On Wed, 15 Jan 2025 20:37:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 681:
> 
>> 679:   __ sldi(temp1, temp1, 56);
>> 680:   __ vxor(vZero, vZero, vZero);
>> 681:   // Load the vector from memory into vConstC2
> 
> This comment is not correct. It's not loaded from memory.

Thanks for confirming that. So the low-order-bits of the reduction polynomial are in the high byte of `temp1` at this point, and the rest of `temp1` is zero, confirming that the polynomial (z^7+z^2+z+1) is in bit-reversed order:


+  __ li(temp1, 0xc2);
+  __ sldi(temp1, temp1, 56);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1918283067

From jsjolen at openjdk.org  Thu Jan 16 11:28:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 16 Jan 2025 11:28:40 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
 <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
 <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
Message-ID: <OsQblEIQ2Jhpk6r_vZM7QtLBr6ZKT8Gc1Wzf-9-Iw7E=.fce8422e-9473-4f3c-8e77-a4038f4f8684@github.com>

On Mon, 13 Jan 2025 13:00:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>>> Thinking about this some more, the fact that tree nodes are allocated internally and are separate entities from the key/value holders precludes the using this tree for memory management (address stable or not). It works, but the separate allocation defeats the purpose. It would be good if, on `upsert`, I could hand in optionally the future node memory itself, and the node should then be placed into/at the start of this memory. And it must be able to deal with the handed-in node memory be variable-sized, of course.
>> 
>> Or, much simpler, let me construct the node itself and hand it into the tree.
>
> Hi @tstuefe ,
> 
>>Consider this scenario: I want to have two short-lived trees, nodes live longer than their trees they temporarily occupy, and I want the nodes to reside in physically different preallocated pools. I want to use the same allocator and tree classes, though, so template parameters must be the same.
> 
>>There are two ways to do this. The most obvious would be to keep a reference to an allocator instance that the caller hands in via constructor. So, make _allocator a pointer, and if omitted by the caller use your own C-heap allocator. Otherwise, use the caller's allocator.
> 
> Or you have a reference as the template type and you alter the constructor of the `RBTree` to take such a type to construct its own allocator with.
> 
> It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
> 
> I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes. You could also, for example, avoid the cost of freeing separate elements and eliminate the whole tree at once when the lifetime of the tree has ended (since the lifetime of the allocator is identical). In short: When your tree isn't intrusive, it's very nice to have a custom allocator.
> 
> For your use case, you basically need a very similar addition to the API. It'd look something like this in pseudo-code:
> 
> ```c++
> // I hold the data, but the node holds the key
> struct IntrusiveHolder {
>   int data;
>   RBNode node;
>   static IntrusiveHolder* cast_to_self(RBNode* node) ; // offset_of() magic
> };
> 
> struct Compare {
>   int cmp(int a, int b);
> }
> 
> template<typename K, typename V, typename Cmp, typename Allocator>
> struct RBTree{
> public:
>   enum Dir { left, right };
>   // Describes the parent node and whether the next node is to be inserted on the left or the right.
>   struct InsertionCursor {
>    RBNode* parent; Dir dir;
>    RBNode* position(); // Get the node (potentially nullptr)
>   };
> 
>   // Walks the tree in the obvious order, using Comparator::cmp overload to find the place to insert.
>   // However does not allocate.
>   InsertionCursor find_insertion_point(K k);
>   // Inserts the node at the position and rebalances the tree.
>   void insert_at_cursor(InsertionCursor, RBNode* node);
> 
>   // For removals we need to unlink the node from the tree, but keep it alive and then just return the pointer.
>   RBNode*...

> Hi @jdksjolen, @caspernorrbin
> 
> sorry for the delay, work is piled up.
> 
> > It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
> 
> intrusive - I did not know this term, even though I wrote containers like this all my life, go figure :-).
> 
> Yes, that's precisely what I want.
> 
>     * I want to create/store nodes myself
> 
>     * I want to avoid copying node content; in fact, I don't want to even bother with assignment operators.
> 
>     * I want to be able to add child nodes to a node to handle duplicates if my tree allows duplicates (which is of no concern to the tree, but since these child nodes should live in the same pool, again, my wish for wanting to create nodes myself)
> 
> 
> All of this points to a tree where I manage the node myself. So, have a function to find a reference to an existing node by key and have a function to hand in a node for storage. Pretty much like you line it out in your example:
> 
> ```
> MyTree::add_my_bulky_and_possible_varsized_node(Node* n) {
> 	- find node n2 with key n->key
> 		- found? Add n as child node under n2
> 		- not found? add n as new node
> }
> ```
> 
> I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.

This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.

```c++
struct Foo {
  RBNode rb; // with some K as key
  Foo* next;
  struct { /* ... */ } data;
};

void a_m_b_a_p_v_n(Foo* n) {
  Cursor c = tree.find_insertion_point(n);
  if (c.exists()) {
    Foo* f = Foo::cast_to_self(c.node());
    n->next = f->next;
    f->next = n->next;
  }
  tree.insert(c, n);
};


Just do that. Let's us entirely skip the headache of the rest of it, at the cost of 8 bytes.
 
> > I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes.
> 
> You lost me here
> 

A static allocator either needs access to local state via a pointer on allocation, or it needs to have some form of protection against concurrent writes. This code below requires a mutex in `alloc`, because it is static.

```c++
static char my_alloc_area[4096];
static size_t ptr_into_my_alloc_area;
void alloc(size_t sz) {
  // Uses my_alloc_area
}

void bar() {
  Thread t1 = run_thread([]() {
    RBTree<K, V, alloc> tree;
    // Do stuff to tree, causing alloc to be called
  });

  Thread t2 = run_thread([]() {
    RBTree<K, V, alloc> tree;
    // Do stuff to tree, causing alloc to be called
  });
}


This code doesn't need a mutex:

```c++
struct Alloc {
  char my_alloc_area[4096];
  // And so on
};

void bar() {
  Thread t1 = run_thread([]() {
    RBTree<K, V, Alloc> tree; // RBTree holds local instance of Alloc
    // Do stuff to tree, causing alloc to be called
  });

  Thread t2 = run_thread([]() {
    RBTree<K, V, Alloc> tree; // And so does this one
    // Do stuff to tree, causing alloc to be called
  });
}


> > You could also, for example, avoid the cost of freeing separate elements and eliminate the whole tree at once when the lifetime of the tree has ended (since the lifetime of the allocator is identical).
> 
> This is not a strong argument though, since when I create the allocator outside the tree, I can let it die in the same fashion when the tree dies. This is what I plan to do. But as you wrote, we should allow both intrusive and non-intrusive.
> 

Sure, you can, but now you just provide it the allocator and you don't have to think about it anymore. If you want to extend the lifetime, make the allocator a reference and add a constructor argument parameter pack. It's really QoL both for writing and maintaining the code, IMO.

> > Casper already is working on supporting an intrusive RBTree with an API similar to what I sketched out above, but I'd like it if we can integrate the current version of the tree as it is. With this change we can already remove the NMT Treap and replace it, so that's a nice use case. Plus, there'll always be new features, we can't wait with integration until all possible features are implemented :).
> 
> Hmm, okay. I'll give the patch a closer look later today and then approve it unless I find something.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2595267700

From stefank at openjdk.org  Thu Jan 16 11:35:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Jan 2025 11:35:44 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion
Message-ID: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>

HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.

All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 

The make files changes to support this are:
1) Remove share/precompiled/ from the list of include directories,
2) Compiler-specific changes to support this:

*Windows cl*:
* Add the share/precompiled/ include directory when generating the PCH file.
* Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.

>From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.

*gcc*:
* Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.

*clang*:
* No changes needed, the -include-pch line is all that we need.

I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.

Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.

Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.

Tested by letting GHA build and running tier1-2 in our CI pipeline.

-------------

Commit messages:
 - Remove precompiled.hpp include from source files

Changes: https://git.openjdk.org/jdk/pull/23146/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347909
  Stats: 1852 lines in 1757 files changed: 6 ins; 1837 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23146/head:pull/23146

PR: https://git.openjdk.org/jdk/pull/23146

From aph at openjdk.org  Thu Jan 16 11:42:38 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Jan 2025 11:42:38 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <Q5-xoCGdFchEp3ENLtFdMsuddQDgdvim6h9vSMb_JpU=.e9bc9f05-fee4-4225-8e9e-1782cc7d065e@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
 <W6x-htemcgUrhZXpzllqxD8azf9eglIvLlgrlqQTxYs=.84f59b57-3a55-4363-997f-13aee029c21b@github.com>
 <Wjnz_Vw8UvJbj0sftKS2Fn9ivJlKyWVk4XSMMod48cw=.dd48bdf1-1038-4912-b3ce-28853a8de10a@github.com>
 <Q5-xoCGdFchEp3ENLtFdMsuddQDgdvim6h9vSMb_JpU=.e9bc9f05-fee4-4225-8e9e-1782cc7d065e@github.com>
Message-ID: <Re5xZOFhR2Ec_NfhJ1Ojc4gAV9eAZI7p1hdYcVD1Pbs=.ab6e2742-b5a0-49c1-9740-232b71257956@github.com>

On Wed, 15 Jan 2025 18:28:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

> The main problem is, though, that there is little commentary in the code which explains how things are encoded. ...

I now see what's going on,

I suggest you add a comment, something like "The polynomials are processed in bit-reflected order for efficiency reasons. For an explanation of how this works, see Vinodh Gopal, Erdinc Ozturk, Wajdi Feghali, Jim Guilford, Gil Wolrich,
Martin Dixon. Optimized Galois-Counter-Mode Implementation on Intel?
Architecture Processor
http://web.archive.org/web/20130609111954/http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-galois-counter-mode-paper.pdf"

That satisfies all of the requirements for documenting the algorithm, which is substantially different from the one in the AES/GCM specification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2595294015

From jsjolen at openjdk.org  Thu Jan 16 12:05:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 16 Jan 2025 12:05:40 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
Message-ID: <QHQk528UPyi4fOqS5AE0TvyUx-478-GETPZxcdgafdw=.ef4fa11b-e48c-4d7c-bc8e-b8fbd3bf0cc1@github.com>

On Thu, 16 Jan 2025 07:03:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified comment
>
> src/hotspot/share/utilities/rbTree.hpp line 167:
> 
>> 165:   // Removes the given node from the tree.
>> 166:   // Returns true if the node was successfully removed, false otherwise.
>> 167:   bool remove(RBNode* node);
> 
> I find it confusing that removing a node can fail. It seems to be to handle `nullptr`. I'd rather restrict this and have `bool remove(const K& k)` check the return value of `find_node`.

Wouldn't that require two traversals down the tree? Would a `enum RemovalResult { Removed, NotFound }` be preferred?

> test/hotspot/gtest/utilities/test_rbtree.cpp line 111:
> 
>> 109:     };
>> 110: 
>> 111:     constexpr const int up_to = 10;
> 
> Suggestion:
> 
>     constexpr int up_to = 10;

TIL, I usually put both.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918332766
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918333661

From aph at openjdk.org  Thu Jan 16 12:13:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Jan 2025 12:13:54 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
 <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
 <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
Message-ID: <P891-oLxnDz6ZVttzG_PHqz8qQweFVMkb64RPdT3eDg=.41037b1c-5afc-44c5-bc3a-a342870fa782@github.com>

On Wed, 4 Dec 2024 12:21:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.
>
> I think the case for making the whole thing in a header depends on how much code there is, that's all.

> @theRealAph
> 
> > Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.
> 
> But for that the compiler must see the implementation of the functions, right? So, we cannot move the implementation into a cpp file?

Sure we can. That's what explicit template instantiation does. The cpp file contains the definition of the functions plus the explicit instantiations of whatever template types are needed.

As an example, imagine that the rbtree.inline.hpp implementation were moved to rbtree.cpp. Then there could be a number of  explicit template instantiations in rbtree.cpp like this one:

`template class RBTree<concreteK, concreteV, concreteCOMPARATOR, concreteALLOCATOR>;`

This generates all of the code for the template functions. But it's generated once and called, rather than inlined. The only stuff in the header would be the declarations.

NB: Again, i am _not_ saying that we should do this, but I am saying that it's an option for large template classes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918344746

From stuefe at openjdk.org  Thu Jan 16 12:31:39 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Jan 2025 12:31:39 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <OsQblEIQ2Jhpk6r_vZM7QtLBr6ZKT8Gc1Wzf-9-Iw7E=.fce8422e-9473-4f3c-8e77-a4038f4f8684@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
 <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
 <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
 <OsQblEIQ2Jhpk6r_vZM7QtLBr6ZKT8Gc1Wzf-9-Iw7E=.fce8422e-9473-4f3c-8e77-a4038f4f8684@github.com>
Message-ID: <sXLE-TKOLYwhqZ1vTdBoWHDdieshwwBp6IpcwAY7G7M=.cc915bcf-de6e-498b-b71b-78441a6b2da3@github.com>

On Thu, 16 Jan 2025 11:26:12 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi @tstuefe ,
>> 
>>>Consider this scenario: I want to have two short-lived trees, nodes live longer than their trees they temporarily occupy, and I want the nodes to reside in physically different preallocated pools. I want to use the same allocator and tree classes, though, so template parameters must be the same.
>> 
>>>There are two ways to do this. The most obvious would be to keep a reference to an allocator instance that the caller hands in via constructor. So, make _allocator a pointer, and if omitted by the caller use your own C-heap allocator. Otherwise, use the caller's allocator.
>> 
>> Or you have a reference as the template type and you alter the constructor of the `RBTree` to take such a type to construct its own allocator with.
>> 
>> It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
>> 
>> I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes. You could also, for example, avoid the cost of freeing separate elements and eliminate the whole tree at once when the lifetime of the tree has ended (since the lifetime of the allocator is identical). In short: When your tree isn't intrusive, it's very nice to have a custom allocator.
>> 
>> For your use case, you basically need a very similar addition to the API. It'd look something like this in pseudo-code:
>> 
>> ```c++
>> // I hold the data, but the node holds the key
>> struct IntrusiveHolder {
>>   int data;
>>   RBNode node;
>>   static IntrusiveHolder* cast_to_self(RBNode* node) ; // offset_of() magic
>> };
>> 
>> struct Compare {
>>   int cmp(int a, int b);
>> }
>> 
>> template<typename K, typename V, typename Cmp, typename Allocator>
>> struct RBTree{
>> public:
>>   enum Dir { left, right };
>>   // Describes the parent node and whether the next node is to be inserted on the left or the right.
>>   struct InsertionCursor {
>>    RBNode* parent; Dir dir;
>>    RBNode* position(); // Get the node (potentially nullptr)
>>   };
>> 
>>   // Walks the tree in the obvious order, using Comparator::cmp overload to find the place to insert.
>>   // However does not allocate.
>>   InsertionCursor find_insertion_point(K k);
>>   // Inserts the node at the position and rebalances the tree.
>>   void insert_at_cursor(InsertionCursor, RBNode* node);
>> 
>>   // For removals we need to unlink t...
>
>> Hi @jdksjolen, @caspernorrbin
>> 
>> sorry for the delay, work is piled up.
>> 
>> > It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
>> 
>> intrusive - I did not know this term, even though I wrote containers like this all my life, go figure :-).
>> 
>> Yes, that's precisely what I want.
>> 
>>     * I want to create/store nodes myself
>> 
>>     * I want to avoid copying node content; in fact, I don't want to even bother with assignment operators.
>> 
>>     * I want to be able to add child nodes to a node to handle duplicates if my tree allows duplicates (which is of no concern to the tree, but since these child nodes should live in the same pool, again, my wish for wanting to create nodes myself)
>> 
>> 
>> All of this points to a tree where I manage the node myself. So, have a function to find a reference to an existing node by key and have a function to hand in a node for storage. Pretty much like you line it out in your example:
>> 
>> ```
>> MyTree::add_my_bulky_and_possible_varsized_node(Node* n) {
>> 	- find node n2 with key n->key
>> 		- found? Add n as child node under n2
>> 		- not found? add n as new node
>> }
>> ```
>> 
>> I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.
> 
> This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.
> 
> ```c++
> struct Foo {
>   RBNode rb; // with some K as key
>   Foo* next;
>   struct { /* ... */ } data;
> };
> 
> void a_m_b_a_p_v_n(Foo* n) {
>   Cursor c = tree.find_insertion_point(n);
>   if (c.exists()) {
>     Foo* f = Foo::cast_to_self(c.node());
>     n->next = f->next;
>     f->next = n->next;
>   }
>   tree.insert(c, n);
> };
> 
> 
> Just do that. Let's us entirely skip the headache of the rest of it, at the cost of 8 bytes.
>  
>> > I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` alloca...

> > Hi @jdksjolen, 

> > 
> > I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.
> 
> This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.
> 

You misunderstood me - a linked list is exactly what I meant. That is why I talked about a "child node". I did this in metaspace: https://github.com/openjdk/jdk/blob/f64f22b360f68df68ebb875bd0ef08ba61702952/src/hotspot/share/memory/metaspace/blockTree.hpp#L89-L96

I can do that myself, as I wrote, this does not concern the tree. So for the tree we can keep things without duplicates. But for simplicity the easiest solution is for child nodes to be of the Node class itself, because then you can just swap them around and make them the leader node for this key value later. That would require a child Node to be allocated in the same pool as the "real" tree nodes, and have the same type as well. All of that can happen outside the tree. It is, however, an argument for giving the caller the ability to allocate and manage nodes himself and passing them in pre-formed for insertion.

> > > I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes.
> > 
> > 
> > You lost me here
> 
> A static allocator either needs access to local state via a pointer on allocation, or it needs to have some form of protection against concurrent writes. This code below requires a mutex in `alloc`, because it is static.
> 
> 

Oh, sure. But again, not a strong argument for non-intrusiveness. In my original comment, I argued for having the ability to pass in an allocator instance into the destructor, or alternatively use a token of some sort when calling functions in a AllStatic allocator that identifies the tree.

But as I wrote, I think we don't have to choose. We can have an allocator instance as optional ctor argument, and let the tree create its own allocator itself if nothing is passed in. Or, you know, just use malloc and free instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2595459055

From stuefe at openjdk.org  Thu Jan 16 12:40:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Jan 2025 12:40:38 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <P891-oLxnDz6ZVttzG_PHqz8qQweFVMkb64RPdT3eDg=.41037b1c-5afc-44c5-bc3a-a342870fa782@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
 <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
 <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
 <P891-oLxnDz6ZVttzG_PHqz8qQweFVMkb64RPdT3eDg=.41037b1c-5afc-44c5-bc3a-a342870fa782@github.com>
Message-ID: <bbxVeyvfB6VmoyvMhADohO_ITumIG8C7ERXz4i9NaMA=.8b2b3e72-5fb6-41a3-bb2b-256eeb494d74@github.com>

On Thu, 16 Jan 2025 12:11:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I think the case for making the whole thing in a header depends on how much code there is, that's all.
>
>> @theRealAph
>> 
>> > Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.
>> 
>> But for that the compiler must see the implementation of the functions, right? So, we cannot move the implementation into a cpp file?
> 
> Sure we can. That's what explicit template instantiation does. The cpp file contains the definition of the functions plus the explicit instantiations of whatever template types are needed.
> 
> As an example, imagine that the rbtree.inline.hpp implementation were moved to rbtree.cpp. Then there could be a number of  explicit template instantiations in rbtree.cpp like this one:
> 
> `template class RBTree<concreteK, concreteV, concreteCOMPARATOR, concreteALLOCATOR>;`
> 
> This generates all of the code for the template functions. But it's generated once and called, rather than inlined. The only stuff in the header would be the declarations.
> 
> NB: Again, i am _not_ saying that we should do this, but I am saying that it's an option for large template classes.

@theRealAph Just to be sure I understand, this means that if I want to add a new variant at a later point, I need to add its explicit instantiation to this cpp file, right? Including adding all the headers it needs to resolve the new template types.

I guess this is what others meant by "we don't know the types others use upfront". We could do this, its just a bit of a hassle. OTOH, it could reduce template bloat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918415522

From stuefe at openjdk.org  Thu Jan 16 13:13:39 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Jan 2025 13:13:39 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion
In-Reply-To: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
Message-ID: <fmo8sNGWpcxzkb5yUeJYHBtR6b-pWFAqQNB_ICzFVrY=.bec6fe34-74fb-470b-bf11-e06fe59990bc@github.com>

On Thu, 16 Jan 2025 11:28:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
> 
> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
> 
> The make files changes to support this are:
> 1) Remove share/precompiled/ from the list of include directories,
> 2) Compiler-specific changes to support this:
> 
> *Windows cl*:
> * Add the share/precompiled/ include directory when generating the PCH file.
> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
> 
> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
> 
> *gcc*:
> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
> 
> *clang*:
> * No changes needed, the -include-pch line is all that we need.
> 
> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
> 
> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
> 
> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
> 
> Tested by letting GHA build and running tier1-2 in our CI pipeline.

I believe I had cases where I explicitly needed to avoid using the precompiled mechanism for a file. That is still possible, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23146#issuecomment-2595605730

From jsjolen at openjdk.org  Thu Jan 16 13:53:41 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 16 Jan 2025 13:53:41 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <OsQblEIQ2Jhpk6r_vZM7QtLBr6ZKT8Gc1Wzf-9-Iw7E=.fce8422e-9473-4f3c-8e77-a4038f4f8684@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
 <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
 <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
 <OsQblEIQ2Jhpk6r_vZM7QtLBr6ZKT8Gc1Wzf-9-Iw7E=.fce8422e-9473-4f3c-8e77-a4038f4f8684@github.com>
Message-ID: <-XCkn4EZIBRPHcc1_PZELoQDDlCz13VbpnbkJhMDRVc=.c0b6e97d-b6c7-491b-bc13-8ec8a2417124@github.com>

On Thu, 16 Jan 2025 11:26:12 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi @tstuefe ,
>> 
>>>Consider this scenario: I want to have two short-lived trees, nodes live longer than their trees they temporarily occupy, and I want the nodes to reside in physically different preallocated pools. I want to use the same allocator and tree classes, though, so template parameters must be the same.
>> 
>>>There are two ways to do this. The most obvious would be to keep a reference to an allocator instance that the caller hands in via constructor. So, make _allocator a pointer, and if omitted by the caller use your own C-heap allocator. Otherwise, use the caller's allocator.
>> 
>> Or you have a reference as the template type and you alter the constructor of the `RBTree` to take such a type to construct its own allocator with.
>> 
>> It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
>> 
>> I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes. You could also, for example, avoid the cost of freeing separate elements and eliminate the whole tree at once when the lifetime of the tree has ended (since the lifetime of the allocator is identical). In short: When your tree isn't intrusive, it's very nice to have a custom allocator.
>> 
>> For your use case, you basically need a very similar addition to the API. It'd look something like this in pseudo-code:
>> 
>> ```c++
>> // I hold the data, but the node holds the key
>> struct IntrusiveHolder {
>>   int data;
>>   RBNode node;
>>   static IntrusiveHolder* cast_to_self(RBNode* node) ; // offset_of() magic
>> };
>> 
>> struct Compare {
>>   int cmp(int a, int b);
>> }
>> 
>> template<typename K, typename V, typename Cmp, typename Allocator>
>> struct RBTree{
>> public:
>>   enum Dir { left, right };
>>   // Describes the parent node and whether the next node is to be inserted on the left or the right.
>>   struct InsertionCursor {
>>    RBNode* parent; Dir dir;
>>    RBNode* position(); // Get the node (potentially nullptr)
>>   };
>> 
>>   // Walks the tree in the obvious order, using Comparator::cmp overload to find the place to insert.
>>   // However does not allocate.
>>   InsertionCursor find_insertion_point(K k);
>>   // Inserts the node at the position and rebalances the tree.
>>   void insert_at_cursor(InsertionCursor, RBNode* node);
>> 
>>   // For removals we need to unlink t...
>
>> Hi @jdksjolen, @caspernorrbin
>> 
>> sorry for the delay, work is piled up.
>> 
>> > It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
>> 
>> intrusive - I did not know this term, even though I wrote containers like this all my life, go figure :-).
>> 
>> Yes, that's precisely what I want.
>> 
>>     * I want to create/store nodes myself
>> 
>>     * I want to avoid copying node content; in fact, I don't want to even bother with assignment operators.
>> 
>>     * I want to be able to add child nodes to a node to handle duplicates if my tree allows duplicates (which is of no concern to the tree, but since these child nodes should live in the same pool, again, my wish for wanting to create nodes myself)
>> 
>> 
>> All of this points to a tree where I manage the node myself. So, have a function to find a reference to an existing node by key and have a function to hand in a node for storage. Pretty much like you line it out in your example:
>> 
>> ```
>> MyTree::add_my_bulky_and_possible_varsized_node(Node* n) {
>> 	- find node n2 with key n->key
>> 		- found? Add n as child node under n2
>> 		- not found? add n as new node
>> }
>> ```
>> 
>> I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.
> 
> This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.
> 
> ```c++
> struct Foo {
>   RBNode rb; // with some K as key
>   Foo* next;
>   struct { /* ... */ } data;
> };
> 
> void a_m_b_a_p_v_n(Foo* n) {
>   Cursor c = tree.find_insertion_point(n);
>   if (c.exists()) {
>     Foo* f = Foo::cast_to_self(c.node());
>     n->next = f->next;
>     f->next = n->next;
>   }
>   tree.insert(c, n);
> };
> 
> 
> Just do that. Let's us entirely skip the headache of the rest of it, at the cost of 8 bytes.
>  
>> > I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` alloca...

> > > Hi @jdksjolen,
> 
> > > I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.
> > 
> > 
> > This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.
> 
> You misunderstood me - a linked list is exactly what I meant. That is why I talked about a "child node". I did this in metaspace:
> 

Phew! Good to hear that we're talking about the same thing.

> https://github.com/openjdk/jdk/blob/f64f22b360f68df68ebb875bd0ef08ba61702952/src/hotspot/share/memory/metaspace/blockTree.hpp#L89-L96
> 
> I can do that myself, as I wrote, this does not concern the tree. So for the tree we can keep things without duplicates. But for simplicity the easiest solution is for child nodes to be of the Node class itself, because then you can just swap them around and make them the leader node for this key value later. That would require a child Node to be allocated in the same pool as the "real" tree nodes, and have the same type as well. All of that can happen outside the tree. It is, however, an argument for giving the caller the ability to allocate and manage nodes himself and passing them in pre-formed for insertion.
> 
 
Right, and you should get that with the intrusive tree. My pseudo-code that you saw above, unfortunately, does not tell you that.


>Oh, sure. But again, not a strong argument for non-intrusiveness. In my original comment, I argued for having the ability to pass in an allocator instance into the destructor, or alternatively use a token of some sort when calling functions in a AllStatic allocator that identifies the tree.

>But as I wrote, I think we don't have to choose. We can have an allocator instance as optional ctor argument, and let the tree create its own allocator itself if nothing is passed in. Or, you know, just use malloc and free instead.

I think that the major argument for non-intrusive datastructures is that they require less ceremony to use. But as you say, we don't have to choose one or the other, and I don't want us to have to.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2595749485

From amitkumar at openjdk.org  Thu Jan 16 14:20:41 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 16 Jan 2025 14:20:41 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
Message-ID: <b5hQOZEefm9cLjNTr-4_kFS1V7G_VE_EHzpSz87ZnAA=.35952f0d-9aab-495f-9a80-c01b9e1a4ea8@github.com>

On Wed, 15 Jan 2025 14:00:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

Are there some specific flags / jtreg setting with which I should run the tests ? I can see that normal tier1 test are clean.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2595851208

From erikj at openjdk.org  Thu Jan 16 14:29:36 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Jan 2025 14:29:36 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion
In-Reply-To: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
Message-ID: <LxeNXt_u_-SqzRxz5x9O2cgQERR6heMgJ-ZHiqxNTys=.a394f899-db73-4b78-acf4-edf3b8f2c447@github.com>

On Thu, 16 Jan 2025 11:28:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
> 
> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
> 
> The make files changes to support this are:
> 1) Remove share/precompiled/ from the list of include directories,
> 2) Compiler-specific changes to support this:
> 
> *Windows cl*:
> * Add the share/precompiled/ include directory when generating the PCH file.
> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
> 
> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
> 
> *gcc*:
> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
> 
> *clang*:
> * No changes needed, the -include-pch line is all that we need.
> 
> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
> 
> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
> 
> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
> 
> Tested by letting GHA build and running tier1-2 in our CI pipeline.

Looks good to me, but would suggest breaking up some of those lines.

make/common/native/CompileFile.gmk line 256:

> 254:             FILE := $$($1_GENERATED_PCH_SRC), \
> 255:             BASE := $1, \
> 256:             EXTRA_CXXFLAGS := -I$$(dir $$($1_PRECOMPILED_HEADER)) -Fp$$($1_PCH_FILE) -Yc$$(notdir $$($1_PRECOMPILED_HEADER)), \

Suggestion:

            EXTRA_CXXFLAGS := -I$$(dir $$($1_PRECOMPILED_HEADER)) -Fp$$($1_PCH_FILE) \
                -Yc$$(notdir $$($1_PRECOMPILED_HEADER)), \

make/common/native/CompileFile.gmk line 260:

> 258: 
> 259:         $1_USE_PCH_FLAGS := \
> 260:             -FI$$(notdir $$($1_PRECOMPILED_HEADER)) -Fp$$($1_PCH_FILE) -Yu$$(notdir $$($1_PRECOMPILED_HEADER))

Suggestion:

            -FI$$(notdir $$($1_PRECOMPILED_HEADER)) -Fp$$($1_PCH_FILE) \
                -Yu$$(notdir $$($1_PRECOMPILED_HEADER))

make/common/native/CompileFile.gmk line 274:

> 272:         ifeq ($(TOOLCHAIN_TYPE), gcc)
> 273:           $1_PCH_FILE := $$($1_OBJECT_DIR)/precompiled/$$(notdir $$($1_PRECOMPILED_HEADER)).gch
> 274:           $1_USE_PCH_FLAGS := -I$$($1_OBJECT_DIR)/precompiled -include $$(notdir $$($1_PRECOMPILED_HEADER))

Suggestion:

          $1_USE_PCH_FLAGS := -I$$($1_OBJECT_DIR)/precompiled \
              -include $$(notdir $$($1_PRECOMPILED_HEADER))

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23146#pullrequestreview-2556319967
PR Review Comment: https://git.openjdk.org/jdk/pull/23146#discussion_r1918652378
PR Review Comment: https://git.openjdk.org/jdk/pull/23146#discussion_r1918655708
PR Review Comment: https://git.openjdk.org/jdk/pull/23146#discussion_r1918656632

From erikj at openjdk.org  Thu Jan 16 14:33:36 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Jan 2025 14:33:36 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion
In-Reply-To: <fmo8sNGWpcxzkb5yUeJYHBtR6b-pWFAqQNB_ICzFVrY=.bec6fe34-74fb-470b-bf11-e06fe59990bc@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <fmo8sNGWpcxzkb5yUeJYHBtR6b-pWFAqQNB_ICzFVrY=.bec6fe34-74fb-470b-bf11-e06fe59990bc@github.com>
Message-ID: <pAteatEuY4zjpdSnAa__J6La2TzCs1jRCVlKKwDj87g=.dcef179a-e50e-417e-b2b9-36052dc6de3f@github.com>

On Thu, 16 Jan 2025 13:10:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I believe I had cases where I explicitly needed to avoid using the precompiled mechanism for a file. That is still possible, right?

That should still be possible using the exclude parameter to SetupNativeCompilation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23146#issuecomment-2595885031

From stefank at openjdk.org  Thu Jan 16 15:49:39 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Jan 2025 15:49:39 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v2]
In-Reply-To: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
Message-ID: <qjknHzfQE4spLqJEfovuuu8hyLPGx5daDGKVtgZ3Grs=.2a088a38-8853-4c15-b84a-475b71287daa@github.com>

> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
> 
> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
> 
> The make files changes to support this are:
> 1) Remove share/precompiled/ from the list of include directories,
> 2) Compiler-specific changes to support this:
> 
> *Windows cl*:
> * Add the share/precompiled/ include directory when generating the PCH file.
> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
> 
> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
> 
> *gcc*:
> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
> 
> *clang*:
> * No changes needed, the -include-pch line is all that we need.
> 
> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
> 
> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
> 
> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
> 
> Tested by letting GHA build and running tier1-2 in our CI pipeline.

Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:

 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23146/files
  - new: https://git.openjdk.org/jdk/pull/23146/files/32606ce8..72fa0d76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=00-01

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23146/head:pull/23146

PR: https://git.openjdk.org/jdk/pull/23146

From stefank at openjdk.org  Thu Jan 16 15:49:40 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Jan 2025 15:49:40 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v2]
In-Reply-To: <LxeNXt_u_-SqzRxz5x9O2cgQERR6heMgJ-ZHiqxNTys=.a394f899-db73-4b78-acf4-edf3b8f2c447@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <LxeNXt_u_-SqzRxz5x9O2cgQERR6heMgJ-ZHiqxNTys=.a394f899-db73-4b78-acf4-edf3b8f2c447@github.com>
Message-ID: <3-19-R35EtcyfKTQQP0zU3bmIldb64MRiHybU5BSf_I=.733a1008-7eee-43a4-9ab1-e8347882a92f@github.com>

On Thu, 16 Jan 2025 14:26:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Looks good to me, but would suggest breaking up some of those lines.

Thanks for reviewing. I committed your suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23146#issuecomment-2596071557

From stefank at openjdk.org  Thu Jan 16 15:52:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Jan 2025 15:52:37 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion
In-Reply-To: <pAteatEuY4zjpdSnAa__J6La2TzCs1jRCVlKKwDj87g=.dcef179a-e50e-417e-b2b9-36052dc6de3f@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <fmo8sNGWpcxzkb5yUeJYHBtR6b-pWFAqQNB_ICzFVrY=.bec6fe34-74fb-470b-bf11-e06fe59990bc@github.com>
 <pAteatEuY4zjpdSnAa__J6La2TzCs1jRCVlKKwDj87g=.dcef179a-e50e-417e-b2b9-36052dc6de3f@github.com>
Message-ID: <39q-pB_1FUsuaq8RCbOO6oF6BKd7MEIHSrL0Lni2tyg=.ab8ee489-98c4-4734-bb57-2935317b2754@github.com>

On Thu, 16 Jan 2025 14:31:25 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > I believe I had cases where I explicitly needed to avoid using the precompiled mechanism for a file. That is still possible, right?
> 
> That should still be possible using the exclude parameter to SetupNativeCompilation.

JvmOverrideFiles.gmk contains code to exclude files from using precompiled headers. I looked at one of the cmdline files for one of those files and can see that that file is still compiled without precompiled headers as expected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23146#issuecomment-2596081513

From matsaave at openjdk.org  Thu Jan 16 16:03:36 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 16 Jan 2025 16:03:36 GMT
Subject: RFR: 8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories
 [v2]
In-Reply-To: <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>
References: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
 <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>
Message-ID: <0xsUTzkk3h0DHaAhFYqTA_vGLDA4WfZFmuqMg1DeX9s=.81456442-3d61-455a-8555-015ba2becefb@github.com>

On Wed, 15 Jan 2025 22:45:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the os, os_cpu and cpu directories.  There weren't very many.  Most was done with a script with very little hand-editing.  Added 2 whitespaces in arm.ad.
>> Tested just now with tier1-4 on x86 and aarch64, GHA for the rest.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformatting suggestions.

Thanks for the fixes!

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23106#pullrequestreview-2556593699

From coleenp at openjdk.org  Thu Jan 16 16:08:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 16:08:57 GMT
Subject: RFR: 8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories
 [v2]
In-Reply-To: <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>
References: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
 <2OE7euEMOT0L2AnQlyX3OyYw5k5VvtyNgZP70igmkDQ=.88afba21-65b9-4b74-8044-b61d6d0ca3d2@github.com>
Message-ID: <fvf8Eh2WsGeNrkaUsuV0vYuyICo_3fRT_J0ULa7o5hE=.f2b3d633-b08d-491a-bfaa-ffc006fe8445@github.com>

On Wed, 15 Jan 2025 22:45:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the os, os_cpu and cpu directories.  There weren't very many.  Most was done with a script with very little hand-editing.  Added 2 whitespaces in arm.ad.
>> Tested just now with tier1-4 on x86 and aarch64, GHA for the rest.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformatting suggestions.

Thanks Matias and David!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23106#issuecomment-2596122336

From coleenp at openjdk.org  Thu Jan 16 16:13:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 16:13:38 GMT
Subject: Integrated: 8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories
In-Reply-To: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
References: <iXCg97q8fEe6odrDJFCm1HLzs9qSIf_ecnEUlB-kUMk=.0a59f602-1702-4029-953f-5e046eef2eee@github.com>
Message-ID: <G6qEYxvXuTqSkGZMCVhzrGnl9qt4-CBtdZb8Ol3UWBg=.0521c2ee-96be-4ae8-9d3e-64827a4c5507@github.com>

On Tue, 14 Jan 2025 14:56:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the os, os_cpu and cpu directories.  There weren't very many.  Most was done with a script with very little hand-editing.  Added 2 whitespaces in arm.ad.
> Tested just now with tier1-4 on x86 and aarch64, GHA for the rest.

This pull request has now been integrated.

Changeset: d218b540
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d218b54086762d920bba0fc2ced47ea9148a3787
Stats:     112 lines in 19 files changed: 0 ins; 4 del; 108 mod

8347609: Replace SIZE_FORMAT in os/os_cpu/cpu directories

Reviewed-by: matsaave, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/23106

From erikj at openjdk.org  Thu Jan 16 16:24:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Jan 2025 16:24:39 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v2]
In-Reply-To: <qjknHzfQE4spLqJEfovuuu8hyLPGx5daDGKVtgZ3Grs=.2a088a38-8853-4c15-b84a-475b71287daa@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <qjknHzfQE4spLqJEfovuuu8hyLPGx5daDGKVtgZ3Grs=.2a088a38-8853-4c15-b84a-475b71287daa@github.com>
Message-ID: <V0uRMsYyUOAQvSOKk1b8wgYG0ddQQ113z5wx8Vf711k=.0cfbd7ce-5c81-4d97-a287-f56f1323c077@github.com>

On Thu, 16 Jan 2025 15:49:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
>> 
>> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
>> 
>> The make files changes to support this are:
>> 1) Remove share/precompiled/ from the list of include directories,
>> 2) Compiler-specific changes to support this:
>> 
>> *Windows cl*:
>> * Add the share/precompiled/ include directory when generating the PCH file.
>> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
>> 
>> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
>> 
>> *gcc*:
>> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
>> 
>> *clang*:
>> * No changes needed, the -include-pch line is all that we need.
>> 
>> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
>> 
>> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
>> 
>> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
>> 
>> Tested by letting GHA build and running tier1-2 in our CI pipeline.
>
> Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

make/common/native/CompileFile.gmk line 262:

> 260:         $1_USE_PCH_FLAGS := \
> 261:             -FI$$(notdir $$($1_PRECOMPILED_HEADER)) -Fp$$($1_PCH_FILE) \
> 262:                 -Yu$$(notdir $$($1_PRECOMPILED_HEADER))

Oops I messed up here.
Suggestion:

            -FI$$(notdir $$($1_PRECOMPILED_HEADER)) -Fp$$($1_PCH_FILE) \
            -Yu$$(notdir $$($1_PRECOMPILED_HEADER))

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23146#discussion_r1918843925

From aph at openjdk.org  Thu Jan 16 16:33:47 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 16 Jan 2025 16:33:47 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <P891-oLxnDz6ZVttzG_PHqz8qQweFVMkb64RPdT3eDg=.41037b1c-5afc-44c5-bc3a-a342870fa782@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
 <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
 <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
 <P891-oLxnDz6ZVttzG_PHqz8qQweFVMkb64RPdT3eDg=.41037b1c-5afc-44c5-bc3a-a342870fa782@github.com>
Message-ID: <B8QgrLrX_UYjMbyR_Azda2XNnLu3PMwXBMRNDZxpauI=.e3d52d42-5a17-4173-b7df-b2a6fb0e6ab5@github.com>

On Thu, 16 Jan 2025 12:11:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I think the case for making the whole thing in a header depends on how much code there is, that's all.
>
>> @theRealAph
>> 
>> > Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.
>> 
>> But for that the compiler must see the implementation of the functions, right? So, we cannot move the implementation into a cpp file?
> 
> Sure we can. That's what explicit template instantiation does. The cpp file contains the definition of the functions plus the explicit instantiations of whatever template types are needed.
> 
> As an example, imagine that the rbtree.inline.hpp implementation were moved to rbtree.cpp. Then there could be a number of  explicit template instantiations in rbtree.cpp like this one:
> 
> `template class RBTree<concreteK, concreteV, concreteCOMPARATOR, concreteALLOCATOR>;`
> 
> This generates all of the code for the template functions. But it's generated once and called, rather than inlined. The only stuff in the header would be the declarations.
> 
> NB: Again, i am _not_ saying that we should do this, but I am saying that it's an option for large template classes.

> @theRealAph Just to be sure I understand, this means that if I want to add a new variant at a later point, I need to add its explicit instantiation to this cpp file, right? Including adding all the headers it needs to resolve the new template types.

Yes, indeed that's right.

> I guess this is what others meant by "we don't know the types others use upfront". We could do this, its just a bit of a hassle. OTOH, it could reduce template bloat.

No big deal at all, I would have thought. A practical downside might be that a bunch of unused convenience methods would be generated, but a linker can delete many of those,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918856304

From ysr at openjdk.org  Thu Jan 16 16:44:39 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 16 Jan 2025 16:44:39 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <tdn7ABEb9_pCL9kMO3nTDeUsPb-lA9Pnhliml6_xGK8=.721a7b1f-fbd8-46dd-8015-90645d4cf7ac@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

The changes look fine to me.

We probably want to clean up Shenandoah code related to failure to reserve space in a separate ticket. Thanks for bringing these changes to our attention; I had missed the original refactoring of address range reservations that you had started before the holidays.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 391:

> 389: 
> 390:       // Maybe Shenandoah wants to check the the memory got reserved here?
> 391: 

Thanks for tagging us Stefan. There seem to be a few places where we might want to check & guard for failure to reserve the space. It might make sense to clean up these failure paths in a separate ticket. cc @earthling-amzn @shipilev ?

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2556672862
PR Review Comment: https://git.openjdk.org/jdk/pull/22825#discussion_r1918859248

From lmesnik at openjdk.org  Thu Jan 16 17:17:27 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 17:17:27 GMT
Subject: RFR: 8338428: Print final VM flags for task [v4]
In-Reply-To: <06Gdh-fXZSsqpkcB0egI96b0suKcHLVzTxD-3HxsE3Y=.5bcc12ed-876a-4c23-832b-8c3a99b1b728@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <06Gdh-fXZSsqpkcB0egI96b0suKcHLVzTxD-3HxsE3Y=.5bcc12ed-876a-4c23-832b-8c3a99b1b728@github.com>
Message-ID: <vpXyQ1MzORxPRH5mgay8ZSE9MfAZ9AyS1ZSDl5Ltrpk=.12162812-7a9e-4243-9e66-003e76e466a3@github.com>

On Thu, 16 Jan 2025 06:12:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added diagnostic flag

This invocation uses flags set to jtreg like -javaoption, -vmoption but not test-specific flags. 
Unfortunately, I don't have original request about this feature. As I understand the goal is to be able to check the specific vm flags that might be host specific for failed test run, like vector instructions, memory/GC ergonomics, etc. Might be make a diff with passed local run. I think that it is going to be used very rare, just if there are any question about VM default settings.

I think it is ok to have it in xml so far. The more problem is how people aware about this information. Probably add it to https://bugs.openjdk.org/browse/JDK-8346464

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2596280821

From wkemper at openjdk.org  Thu Jan 16 17:25:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Jan 2025 17:25:38 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <tdn7ABEb9_pCL9kMO3nTDeUsPb-lA9Pnhliml6_xGK8=.721a7b1f-fbd8-46dd-8015-90645d4cf7ac@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <tdn7ABEb9_pCL9kMO3nTDeUsPb-lA9Pnhliml6_xGK8=.721a7b1f-fbd8-46dd-8015-90645d4cf7ac@github.com>
Message-ID: <m8uOP6EyKhIJ2EiHBGgHxhHaUoa5d8_m3donYky7e2Y=.6a2d946a-eb70-4c95-939d-713ecf2f23f2@github.com>

On Thu, 16 Jan 2025 16:32:02 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
>> 
>> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
>> 
>> Tested tier1 and GHA, but will run more tests when/if this gets accepted.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 391:
> 
>> 389: 
>> 390:       // Maybe Shenandoah wants to check the the memory got reserved here?
>> 391: 
> 
> Thanks for tagging us Stefan. There seem to be a few places where we might want to check & guard for failure to reserve the space. It might make sense to clean up these failure paths in a separate ticket. cc @earthling-amzn @shipilev ?

The method `ShenandoahHeap::reserve` should `vm_exit_during_initialization` if the memory isn't reserved. Between that and the collection set memory here, I believe that would cover Shenandoah's cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22825#discussion_r1918930136

From stuefe at openjdk.org  Thu Jan 16 17:32:56 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Jan 2025 17:32:56 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
Message-ID: <_SIamvGXXQ7x9aqeB-QM25CEyB_v0W2PcrGxE6sO4FE=.4d947ee3-93fc-45d9-98ab-0bb92236ebf2@github.com>

On Fri, 10 Jan 2025 10:03:22 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified comment

Looked through verification first; will continue tomorrow.

src/hotspot/share/utilities/rbTree.hpp line 55:

> 53:   class RBNode {
> 54:     friend RBTree;
> 55:     friend class RBTreeTest;

Is there a reason to be friends of RBTree? Even RBTreeTest?

src/hotspot/share/utilities/rbTree.hpp line 66:

> 64: 
> 65:     enum Color : uint8_t { BLACK, RED };
> 66:     Color _color;

Possibly for a future optimization. You could keep the color information as one bit overlayed in one of the pointers. That saves four to eight bytes per Node structure.

The Node pointers have to be aligned to `sizeof(void*)`, so we will always have an alignment shadow of at least two bits. If you encapsulate accessing the tagged pointer correctly, this should not be complicated.

(I believe the kernel RB tree does the same thing)

src/hotspot/share/utilities/rbTree.hpp line 70:

> 68:   public:
> 69:     const K& key() const { return _key; }
> 70:     V& val() { return _value; }

Here, and in other places: please give us const variants too (as @xmas92 noted, I believe).

src/hotspot/share/utilities/rbTree.inline.hpp line 92:

> 90: #ifdef ASSERT
> 91: template <typename K, typename V, typename COMPARATOR, typename ALLOCATOR>
> 92: inline bool RBTree<K, V, COMPARATOR, ALLOCATOR>::RBNode::is_correct(

Some proposals for better/more useful/more expressive verification:

1) I would use asserts inside the `Node::is_correct` function. I would not bother returning a bool but assert right away. This is used during tree verification only, and ideally, we want to crash hard and fast right there to have aa point to quickly debug. Arguably, I would rename the function to something like `verify()` (I'll use that name from now on)

2) I would then also not use combined asserts but assert each condition separately.

3) Please use size_t (or uintx, which I prefer but I know others don't) for the number of nodes/number of blacks in the arguments of this function. 

4) I would not pass in limits to be checked by the node. Instead would let Node::verify() increase stats.

5) I would also return longest/shortest path to any leaf, and black-nodes-til-leaf, like this (see below point(6)):


void verify(
  size_t& num_nodes,          // total nodes 
  size_t& blacks_until_leaf,  // returns the number of black nodes from here to its leafs
  size_t& longest_leaf_path,  // length of longest to-leaf path from here
  size_t& shortest_leaf_path, // length of shortest to-leaf path from here
  size_t current_depth
  ) const;

you also can create a Stat struct and pass a reference to that if you dislike so many arguments.

6) In Node::verify(), I would explicitly check the following red-black tree rules: 
  - If Node is red, it shall have no red childs; (I see you do this already)
  - If a Node has exactly one child, the child must be red (consequently, the node must be black)
  - After calling `Node::verify() `for left and right child recursively, the blacks-until-leaf for right node and the one for the left node should be the same (which is also why we return just one value for `blacks_until_leaf`)
  - the longest leaf path and the shortest leaf path must never be farther apart than factor 2 (so, `shortest_leaf_path <= longest_leaf_path <= shortest_leaf_path * 2 `). That asserts that we are balanced as far as RB trees go.

7) In debug builds, please give the Node class a marker bit: `DEBUG_ONLY(bool _visited)`. Keep inside of the Tree class a `DEBUG_ONLY("bool _expected_visited")` bit. On Node creation/addition, set node->_visited to tree->_expected_visited. Then do this: on each `Tree::verify()` call, flip the tree expected bit, and in `Node::verify()` assert that the current node "_visited" bit is !_expected. Then change node->_visited to _expected. This is to ensure that the tree does not contain duplicates - we should have visited each node exactly once. This will be a thing to look out for when adding caller-allocated nodes as a feature. (the flipping of tree->_expected_visited just lets us avoid resetting the bit in each node after verification is completed)

8) If you do (7), you could also do something like this: write a gtest where all nodes are allocated from an array-like allocator. Now you have an independent way to traverse all nodes (via the array). After tree verification, you can then do one additional sweep through the array and check that every `Node::_visited == Tree::_expected_visited`. This makes sure our iteration process reaches all nodes.

9) outside the tree, once root->verify() returned, just check the num_nodes counter for == Tree::_size. Remove Node::count_nodes(), it's not needed. Now, less code and we have avoided one unnecessary iteration of the tree just to get the node count.

src/hotspot/share/utilities/rbTree.inline.hpp line 105:

> 103:   bool right_is_correct = num_blacks == 0;
> 104:   if (_left != nullptr) {
> 105:     if (COMPARATOR::cmp(_left->key(), _key) >= 0 || // left >= root, or

Under which circumstances would the comparator return 0? We don't have duplicates in the tree, right?

src/hotspot/share/utilities/rbTree.inline.hpp line 114:

> 112:   if (_right != nullptr) {
> 113:     if (COMPARATOR::cmp(_right->key(), _key) <= 0 || // right <= root, or
> 114:         (is_red() && _left->is_red()) ||             // 2 red nodes, or

Did you mean `_right->is_red()` ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2556582163
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918935276
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918938994
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918805128
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918920888
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918882840
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1918883391

From adinn at openjdk.org  Thu Jan 16 18:07:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 16 Jan 2025 18:07:42 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <b5hQOZEefm9cLjNTr-4_kFS1V7G_VE_EHzpSz87ZnAA=.35952f0d-9aab-495f-9a80-c01b9e1a4ea8@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
 <b5hQOZEefm9cLjNTr-4_kFS1V7G_VE_EHzpSz87ZnAA=.35952f0d-9aab-495f-9a80-c01b9e1a4ea8@github.com>
Message-ID: <aTM0vossEyTYX-vyflC5w4BdJr2WDR67HLUJuLm-AII=.3347524b-e1ce-438b-9c54-7d277665de44@github.com>

On Thu, 16 Jan 2025 14:18:06 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyrights
>
> Are there some specific flags / jtreg setting with which I should run the tests ? I can see that normal tier1 test are clean.

@offamitkumar

Thanks for confirming tier1 tests are ok. That's probably enough to be safe (it includes running the gtest that checks the stub routines.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2596377615

From lmesnik at openjdk.org  Thu Jan 16 18:09:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:09:59 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v2]
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <6Nzo-XUtQRZNsZlfAmV8-4tF36VpdbUamSV195gwQ1g=.7f8807ad-d00e-487a-9c4a-12ebc7be7676@github.com>

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23143/files
  - new: https://git.openjdk.org/jdk/pull/23143/files/ae302c9c..6a23012e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=00-01

  Stats: 52 lines in 10 files changed: 6 ins; 42 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23143/head:pull/23143

PR: https://git.openjdk.org/jdk/pull/23143

From lmesnik at openjdk.org  Thu Jan 16 18:18:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:18:15 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  revert change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23143/files
  - new: https://git.openjdk.org/jdk/pull/23143/files/6a23012e..7a1c35da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23143/head:pull/23143

PR: https://git.openjdk.org/jdk/pull/23143

From lmesnik at openjdk.org  Thu Jan 16 18:18:16 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:18:16 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <ZzZgrVk1z_5JOOT-3buuPQ-kj_PhXx0iOzpVolbtJLc=.419a6c89-71c4-4342-94fa-54775c63a873@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <ZzZgrVk1z_5JOOT-3buuPQ-kj_PhXx0iOzpVolbtJLc=.419a6c89-71c4-4342-94fa-54775c63a873@github.com>
Message-ID: <iRy6PrTfmonHd0LfREsBdkaYwuL4JI3IpopvbU4tGjs=.cd67878c-a8ec-4f4d-9cfa-4b9dde8a8d85@github.com>

On Thu, 16 Jan 2025 07:09:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert change
>
> test/lib/jdk/test/lib/thread/VThreadPinner.java line 97:
> 
>> 95:      * virtual thread then it invokes the task directly.
>> 96:      */
>> 97:     @SuppressWarnings("unchecked")
> 
> If you change the code to the follow, same in VThreadRunner then it would avoid the the SW on the method and avoid the other change you have to VThreadRunner.
> 
>             @SuppressWarnings("unchecked")
>             var x = (X) ex;
>             throw x;

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918978915

From lmesnik at openjdk.org  Thu Jan 16 18:18:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:18:15 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>
Message-ID: <k-KYhhMc4dL_1XfJcYgPWdiUGmx0EgwKrFtiEd2UX_s=.82e63bcd-fd17-474e-a66b-07e0aeb0ec30@github.com>

On Thu, 16 Jan 2025 18:14:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There few compiler warning disabled in the testlibary build.
>> They should be fixed or localized and removed from build to prevent new possible issues.
>> 
>> The main goal is to avoid new such issues in the testlibrary. 
>> Tested with tier1-5 to ensure that all tests were passed.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert change

See answer and updated vewrsion.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2556833136

From lmesnik at openjdk.org  Thu Jan 16 18:18:16 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:18:16 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <lsAg7A_4Wkr7BWfLvnphoYVU1Fjh0TtwJZJesLHZYFo=.c95180c4-2970-48a2-95ca-ccf26c2b61b4@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <lsAg7A_4Wkr7BWfLvnphoYVU1Fjh0TtwJZJesLHZYFo=.c95180c4-2970-48a2-95ca-ccf26c2b61b4@github.com>
Message-ID: <QS-YajV1x0vqI7pvgnMti4iaKWtzPoGmEweNyCEoGMA=.b5fcd363-9295-456e-b7ba-dfa729e0f65b@github.com>

On Thu, 16 Jan 2025 05:31:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert change
>
> test/lib/jdk/test/lib/format/ArrayDiff.java line 110:
> 
>> 108:      * @return an ArrayDiff instance for the two arrays and formatting parameters provided
>> 109:      */
>> 110:     @SuppressWarnings({"rawtypes", "unchecked"})
> 
> Just wondering where the unchecked warning arises in the code?

It is in the line 123.

> test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java line 42:
> 
>> 40:  *
>> 41:  * @author      Bill Foote
>> 42:  */
> 
> I would suggest deleting any comment blocks that just have the @author tag, and deleting the @author elsewhere. All these files (lib/hprof) already have an author attribution comment.

done

> test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46:
> 
>> 44:     public int   getInt(long pos) throws IOException;
>> 45:     public long  getLong(long pos) throws IOException;
>> 46:     public void  close() throws IOException;
> 
> Why was this redefined to throw IOException rather than just Exception?

The javac complains about potential InterruptedException, so I changed type.
See
https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html
`Implementers of this interface are also strongly advised to not have the close method throw [InterruptedException](https://docs.oracle.com/javase/8/docs/api/java/lang/InterruptedException.html). This exception interacts with a thread's interrupted status, and runtime misbehavior is likely to occur if an InterruptedException is [suppressed](https://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSuppressed-java.lang.Throwable-). More generally, if it would cause problems for an exception to be suppressed, the AutoCloseable.close method should not throw it.`

> test/lib/jdk/test/lib/hprof/parser/Reader.java line 96:
> 
>> 94:             } else if ((i >>> 8) == GZIP_HEADER_MAGIC) {
>> 95:                 // Possible gziped file, try decompress it and get the stack trace.
>> 96:                 String deCompressedFile = "heapdump" + System.currentTimeMillis() + ".hprof";
> 
> It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below.

Thanks for catching this. I missed that we try to re-open the same fail in else branch.

> test/lib/jdk/test/lib/thread/VThreadRunner.java line 100:
> 
>> 98:             if ((X) ex == ex) {
>> 99:                 throw (X) ex;
>> 100:             }
> 
> This doesn't make sense to me.

Sorry for mess, this shouldn't have been committed at all, just some drafting.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918956737
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918960995
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918969394
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918976104
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918981965

From stefank at openjdk.org  Thu Jan 16 18:49:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 16 Jan 2025 18:49:51 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v3]
In-Reply-To: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
Message-ID: <vb_qsnWd7wzsVS1p2IABKt9fG6Q3PHYoGcbswwTdQPY=.515e6150-6694-4c2b-badb-92e7a01c27f9@github.com>

> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
> 
> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
> 
> The make files changes to support this are:
> 1) Remove share/precompiled/ from the list of include directories,
> 2) Compiler-specific changes to support this:
> 
> *Windows cl*:
> * Add the share/precompiled/ include directory when generating the PCH file.
> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
> 
> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
> 
> *gcc*:
> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
> 
> *clang*:
> * No changes needed, the -include-pch line is all that we need.
> 
> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
> 
> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
> 
> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
> 
> Tested by letting GHA build and running tier1-2 in our CI pipeline.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Update make/common/native/CompileFile.gmk
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23146/files
  - new: https://git.openjdk.org/jdk/pull/23146/files/72fa0d76..9a73f271

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23146/head:pull/23146

PR: https://git.openjdk.org/jdk/pull/23146

From erikj at openjdk.org  Thu Jan 16 19:03:42 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Jan 2025 19:03:42 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v3]
In-Reply-To: <vb_qsnWd7wzsVS1p2IABKt9fG6Q3PHYoGcbswwTdQPY=.515e6150-6694-4c2b-badb-92e7a01c27f9@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <vb_qsnWd7wzsVS1p2IABKt9fG6Q3PHYoGcbswwTdQPY=.515e6150-6694-4c2b-badb-92e7a01c27f9@github.com>
Message-ID: <4hi7ZsssAtyK5f67919F1r0UxAR_Ubq4kORYmknl-hs=.931b2c76-a9e3-4531-b334-addf22e8b1e6@github.com>

On Thu, 16 Jan 2025 18:49:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
>> 
>> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
>> 
>> The make files changes to support this are:
>> 1) Remove share/precompiled/ from the list of include directories,
>> 2) Compiler-specific changes to support this:
>> 
>> *Windows cl*:
>> * Add the share/precompiled/ include directory when generating the PCH file.
>> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
>> 
>> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
>> 
>> *gcc*:
>> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
>> 
>> *clang*:
>> * No changes needed, the -include-pch line is all that we need.
>> 
>> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
>> 
>> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
>> 
>> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
>> 
>> Tested by letting GHA build and running tier1-2 in our CI pipeline.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/common/native/CompileFile.gmk
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23146#pullrequestreview-2557010070

From kvn at openjdk.org  Thu Jan 16 19:07:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 16 Jan 2025 19:07:46 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
Message-ID: <0eOBHgQTV-7_GH0_dDWG7teIes2XaHBVHwUAkcXd_bI=.f67fcf62-722e-4af3-aa45-efa1f3e6f21f@github.com>

On Wed, 15 Jan 2025 14:00:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

Yes, this code runs during VM startup so passing tier1 is good indication that it is safe.
May be make sure to run `compiler/intrinsics`, `compiler/codegen/aes`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2596552247

From coleenp at openjdk.org  Thu Jan 16 20:14:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 20:14:15 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code
Message-ID: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>

Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
Tested with tier1-4.

-------------

Commit messages:
 - More formatting changes
 - Changes made by hand
 - Replace SIZE_FORMAT in runtime

Changes: https://git.openjdk.org/jdk/pull/23160/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347733
  Stats: 341 lines in 68 files changed: 3 ins; 6 del; 332 mod
  Patch: https://git.openjdk.org/jdk/pull/23160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23160/head:pull/23160

PR: https://git.openjdk.org/jdk/pull/23160

From vlivanov at openjdk.org  Thu Jan 16 22:17:42 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 16 Jan 2025 22:17:42 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
Message-ID: <14uBUhX_V0bQgetjK4ojSYJeJYRcM1jBMV60Hk8VaRQ=.5b5144d6-c077-4e15-b9a7-7a25858bbfd8@github.com>

On Wed, 15 Jan 2025 14:00:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

I see compiler/arguments/TestCodeEntryAlignment.java failures on x64.


#  Internal Error (.../src/hotspot/share/asm/codeBuffer.hpp:200), pid=1218011, tid=1218066
#  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007f52b412a000 <= 0x00007f52b413e141 <= 0x00007f52b413e140

Command Line: -XX:+UnlockExperimentalVMOptions -XX:CodeCacheSegmentSize=1024 -XX:CodeEntryAlignment=1024 compiler.arguments.TestCodeEntryAlignment run

Current thread (0x00007f52c422b220):  JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=1218066, stack(0x00007f52a4f9b000,0x00007f52a509b000) (1024K)]

V  [libjvm.so+0x68c7b0]  Assembler::vmovdqu(Address, XMMRegister)+0x250  (codeBuffer.hpp:200)
V  [libjvm.so+0x1390ed3]  MacroAssembler::vmovdqu(Address, XMMRegister)+0x73  (macroAssembler_x86.cpp:2663)
V  [libjvm.so+0x176f4d5]  StubGenerator::generate_base64_encodeBlock()+0x955  (stubGenerator_x86_64.cpp:2081)
V  [libjvm.so+0x1777c7d]  StubGenerator::generate_compiler_stubs()+0x5cd  (stubGenerator_x86_64.cpp:4296)
V  [libjvm.so+0x17795e8]  StubGenerator_generate(CodeBuffer*, StubGenBlobId)+0xe8  (stubGenerator_x86_64.cpp:4421)
V  [libjvm.so+0x17d2ff8]  initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*) [clone .constprop.0]+0xe8  (stubRoutines.cpp:233)
V  [libjvm.so+0x17d55fc]  compiler_stubs_init(bool)+0x9c  (stubRoutines.cpp:264)
...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2597018842

From dholmes at openjdk.org  Thu Jan 16 22:30:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Jan 2025 22:30:33 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <Ip4bXpuQrTVWWtbGxNqfLqBVuh2lehZnNBSiiKO21OE=.aa2791be-9e8e-4874-94ed-dfd50777e538@github.com>

On Tue, 14 Jan 2025 19:12:45 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`
> 
> This will run the target app, and log all the allocations in chronological order. This will produce a few files:
> - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations)
> - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state)
> - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing)
> 
> Now you can use those recording to actually benchmark your proposed changes, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10`
> 
> Which will produce yet another file:
> 
> - hs_nmt_pid23527_benchmark.log
> 
> that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output.
> 
> The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change.

@gerard-ziemski  we should not have a bunch of Java files for this in the hotspot source tree. Benchmarks should be in the test tree somewhere. Can this not be integrated into existing benchmark frameworks i.e. JMH?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2597036137

From dholmes at openjdk.org  Thu Jan 16 22:43:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Jan 2025 22:43:37 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <GDRx6XhicQAtd5RKTvco86EIrz3hyCB1cjYvLcQ6rtA=.757b1b51-2786-4c3e-b974-ccaf3398b832@github.com>

On Tue, 14 Jan 2025 19:12:45 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`
> 
> This will run the target app, and log all the allocations in chronological order. This will produce a few files:
> - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations)
> - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state)
> - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing)
> 
> Now you can use those recording to actually benchmark your proposed changes, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10`
> 
> Which will produce yet another file:
> 
> - hs_nmt_pid23527_benchmark.log
> 
> that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output.
> 
> The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change.

I'm really not sure what this is actually trying to benchmark - who will be collecting this data and analysing it and what will they do with their results?

That aside, generating the logs in a training run is okay, but the tool for processing those logs should reside elsewhere.

A few initial passing comments.

src/demo/share/jfc/J2Ddemo/java2d/Intro.java line 449:

> 447:                   System.exit(0);
> 448:               }
> 449:               Scene scene = director.get(index);

Leftover debugging code?

src/hotspot/share/nmt/memLogRecorder.cpp line 27:

> 25: // record pattern of allocations of memory calls:
> 26: //
> 27: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar

You don't need the full paths in these examples

src/hotspot/share/nmt/memLogRecorder.cpp line 43:

> 41: // then to actually run the benchmark:
> 42: //
> 43: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=43100 -XX:NMTBenchmarkRecordedLoops=10

?? How does this run anything - you haven't passed an initial class to the Java invocation?

src/hotspot/share/nmt/memLogRecorder.cpp line 98:

> 96:  // ???
> 97: #endif
> 98:   pthread_mutex_init(&_mutex, NULL);

You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work.

src/hotspot/share/nmt/memLogRecorder.hpp line 37:

> 35: #elif defined(WINDOWS)
> 36:  // ???
> 37: #endif

You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23115#pullrequestreview-2557544778
PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919324156
PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919325893
PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919328324
PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919328661
PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919324004

From fyang at openjdk.org  Fri Jan 17 02:03:38 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 17 Jan 2025 02:03:38 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v10]
In-Reply-To: <-7WakNQrV3PbcXXz1VxcyI38i56gpunMO_nrj08autA=.e3b7b7a7-e0c2-43bd-bbea-141d57e2181c@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <-7WakNQrV3PbcXXz1VxcyI38i56gpunMO_nrj08autA=.e3b7b7a7-e0c2-43bd-bbea-141d57e2181c@github.com>
Message-ID: <Vcoo1QzkAwFZnjUQh0ehuhmL3SnWrFvkELd3er7AGbI=.f397d067-7d15-401f-87da-10c2a6d091f6@github.com>

On Wed, 15 Jan 2025 09:51:26 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8342881
>  - Fix for Feilong's review
>  - Add MacroAssembler::ror function
>  - Merge branch 'master' into JDK-8342881
>  - Update code comment
>  - Update for RealFYang's comment
>  - Merge remote-tracking branch 'upstream/master' into JDK-8342881
>  - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

Marked as reviewed by fyang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21922#pullrequestreview-2557819563

From dholmes at openjdk.org  Fri Jan 17 02:27:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Jan 2025 02:27:41 GMT
Subject: RFR: 8338428: Print final VM flags for task [v4]
In-Reply-To: <06Gdh-fXZSsqpkcB0egI96b0suKcHLVzTxD-3HxsE3Y=.5bcc12ed-876a-4c23-832b-8c3a99b1b728@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <06Gdh-fXZSsqpkcB0egI96b0suKcHLVzTxD-3HxsE3Y=.5bcc12ed-876a-4c23-832b-8c3a99b1b728@github.com>
Message-ID: <fBGAz4fTsuIUC3VNhJCWCkybzs6G-wIltsBUOsa2zgc=.845b3143-676b-4e8d-b115-4789a695b11b@github.com>

On Thu, 16 Jan 2025 06:12:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added diagnostic flag

Okay this approach seems reasonable and doesn't add a huge burden to running the tests.

Do we want to add this to all TEST.ROOT files or will hotspot and jdk suffice here?

The PR description should be updated and we probably need to expand this to other groups for review.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23054#pullrequestreview-2557838579

From gcao at openjdk.org  Fri Jan 17 03:14:37 2025
From: gcao at openjdk.org (Gui Cao)
Date: Fri, 17 Jan 2025 03:14:37 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v10]
In-Reply-To: <-7WakNQrV3PbcXXz1VxcyI38i56gpunMO_nrj08autA=.e3b7b7a7-e0c2-43bd-bbea-141d57e2181c@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <-7WakNQrV3PbcXXz1VxcyI38i56gpunMO_nrj08autA=.e3b7b7a7-e0c2-43bd-bbea-141d57e2181c@github.com>
Message-ID: <khPOAfUu77BRUF-puo1SaJfaIR5Sd52yd-HlZmiX6Sg=.98d36b2f-3c10-4e1c-80af-7435fe332b6a@github.com>

On Wed, 15 Jan 2025 09:51:26 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8342881
>  - Fix for Feilong's review
>  - Add MacroAssembler::ror function
>  - Merge branch 'master' into JDK-8342881
>  - Update code comment
>  - Update for RealFYang's comment
>  - Merge remote-tracking branch 'upstream/master' into JDK-8342881
>  - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

Thanks all for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21922#issuecomment-2597343711

From duke at openjdk.org  Fri Jan 17 03:14:38 2025
From: duke at openjdk.org (duke)
Date: Fri, 17 Jan 2025 03:14:38 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v10]
In-Reply-To: <-7WakNQrV3PbcXXz1VxcyI38i56gpunMO_nrj08autA=.e3b7b7a7-e0c2-43bd-bbea-141d57e2181c@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <-7WakNQrV3PbcXXz1VxcyI38i56gpunMO_nrj08autA=.e3b7b7a7-e0c2-43bd-bbea-141d57e2181c@github.com>
Message-ID: <xkB_VMqEnH9OmPy-3cZE7pwjofW3aA1C29Q10lqbzQY=.c7b3ec47-cd9a-47b7-8baf-450869c6cd99@github.com>

On Wed, 15 Jan 2025 09:51:26 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8342881
>  - Fix for Feilong's review
>  - Add MacroAssembler::ror function
>  - Merge branch 'master' into JDK-8342881
>  - Update code comment
>  - Update for RealFYang's comment
>  - Merge remote-tracking branch 'upstream/master' into JDK-8342881
>  - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

@zifeihan 
Your change (at version 693deae3b1ee83cb7c1412a4266cc7e411e242a7) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21922#issuecomment-2597344909

From sspitsyn at openjdk.org  Fri Jan 17 04:09:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 04:09:34 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code
In-Reply-To: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
Message-ID: <t4eG8WFq2zfyOk8f-50NQfaMSN6VRSwTA8Zkd7worZ0=.bc702046-7e9c-4e4d-86cf-7f245bc0f058@github.com>

On Thu, 16 Jan 2025 16:48:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
> Tested with tier1-4.

This makes code more readable. Looks good.
I've not checked the copyright years.

src/hotspot/share/oops/array.hpp line 77:

> 75: 
> 76:     size_t elements = left / sizeof(T);
> 77:     assert(elements <= (size_t)INT_MAX, "number of elements %zudoesn't fit into an int.", elements);

Nit: It seems that a space is needed after `%zu`. This was this way originally.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23160#pullrequestreview-2557917156
PR Review Comment: https://git.openjdk.org/jdk/pull/23160#discussion_r1919521203

From dholmes at openjdk.org  Fri Jan 17 05:12:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Jan 2025 05:12:34 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code
In-Reply-To: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
Message-ID: <FfED-EHugBDXMLN6AdLQ_GLo45J1S6Cwe-4DiHc3_g8=.e743ceb4-aa6e-4d28-b864-5fb2ea9c6e7b@github.com>

On Thu, 16 Jan 2025 16:48:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
> Tested with tier1-4.

LGTM.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23160#pullrequestreview-2557979828

From cslucas at openjdk.org  Fri Jan 17 05:24:12 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 17 Jan 2025 05:24:12 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables
Message-ID: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>

In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 

The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.

The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.

Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.

The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.

Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.

Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

-------------

Commit messages:
 - Relocation of Card Tables

Changes: https://git.openjdk.org/jdk/pull/23170/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343468
  Stats: 372 lines in 30 files changed: 200 ins; 114 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/23170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170

PR: https://git.openjdk.org/jdk/pull/23170

From dholmes at openjdk.org  Fri Jan 17 06:01:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Jan 2025 06:01:48 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>
Message-ID: <o33EsykK6J5km_i1bsx-syIBmu2EXlmxhCSfyLaaQ2U=.1e20bd92-24ba-49ed-ae75-bb758adeaf6a@github.com>

On Thu, 16 Jan 2025 18:18:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There few compiler warning disabled in the testlibary build.
>> They should be fixed or localized and removed from build to prevent new possible issues.
>> 
>> The main goal is to avoid new such issues in the testlibrary. 
>> Tested with tier1-5 to ensure that all tests were passed.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert change

Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2558035645

From dholmes at openjdk.org  Fri Jan 17 06:01:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Jan 2025 06:01:49 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <QS-YajV1x0vqI7pvgnMti4iaKWtzPoGmEweNyCEoGMA=.b5fcd363-9295-456e-b7ba-dfa729e0f65b@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <lsAg7A_4Wkr7BWfLvnphoYVU1Fjh0TtwJZJesLHZYFo=.c95180c4-2970-48a2-95ca-ccf26c2b61b4@github.com>
 <QS-YajV1x0vqI7pvgnMti4iaKWtzPoGmEweNyCEoGMA=.b5fcd363-9295-456e-b7ba-dfa729e0f65b@github.com>
Message-ID: <nfwHCq1DfAO6Zgauc0oa0kRSy1Cqft87VqZfPjIpfhw=.0e9d2c45-54e4-44dc-a861-d0b1ba51271a@github.com>

On Thu, 16 Jan 2025 17:53:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46:
>> 
>>> 44:     public int   getInt(long pos) throws IOException;
>>> 45:     public long  getLong(long pos) throws IOException;
>>> 46:     public void  close() throws IOException;
>> 
>> Why was this redefined to throw IOException rather than just Exception?
>
> The javac complains about potential InterruptedException, so I changed type.
> See
> https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html
> `Implementers of this interface are also strongly advised to not have the close method throw [InterruptedException](https://docs.oracle.com/javase/8/docs/api/java/lang/InterruptedException.html). This exception interacts with a thread's interrupted status, and runtime misbehavior is likely to occur if an InterruptedException is [suppressed](https://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSuppressed-java.lang.Throwable-). More generally, if it would cause problems for an exception to be suppressed, the AutoCloseable.close method should not throw it.`

Ugggh! That is an annoyance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1919602558

From dholmes at openjdk.org  Fri Jan 17 06:08:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Jan 2025 06:08:47 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v3]
In-Reply-To: <vb_qsnWd7wzsVS1p2IABKt9fG6Q3PHYoGcbswwTdQPY=.515e6150-6694-4c2b-badb-92e7a01c27f9@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <vb_qsnWd7wzsVS1p2IABKt9fG6Q3PHYoGcbswwTdQPY=.515e6150-6694-4c2b-badb-92e7a01c27f9@github.com>
Message-ID: <DSnhhi5j1brEuC9G2EBE9qLLls6buNF76bouRTCihZI=.fece0bfb-4dbd-4837-8633-a3f45f25fcea@github.com>

On Thu, 16 Jan 2025 18:49:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
>> 
>> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
>> 
>> The make files changes to support this are:
>> 1) Remove share/precompiled/ from the list of include directories,
>> 2) Compiler-specific changes to support this:
>> 
>> *Windows cl*:
>> * Add the share/precompiled/ include directory when generating the PCH file.
>> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
>> 
>> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
>> 
>> *gcc*:
>> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
>> 
>> *clang*:
>> * No changes needed, the -include-pch line is all that we need.
>> 
>> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
>> 
>> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
>> 
>> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
>> 
>> Tested by letting GHA build and running tier1-2 in our CI pipeline.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/common/native/CompileFile.gmk
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Do the gtest changes not require something in make/hotspot/lib/CompileGtest.gmk?

Otherwise as long as this works it seems fine. (I presume the necessary compilers didn't support this when we made the original switch from includeDB.)

I expect there are copyrights that need updating (though not too many once Coleen has finished with her changes :) ).

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23146#pullrequestreview-2558043707

From stefank at openjdk.org  Fri Jan 17 08:15:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 17 Jan 2025 08:15:37 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v3]
In-Reply-To: <DSnhhi5j1brEuC9G2EBE9qLLls6buNF76bouRTCihZI=.fece0bfb-4dbd-4837-8633-a3f45f25fcea@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <vb_qsnWd7wzsVS1p2IABKt9fG6Q3PHYoGcbswwTdQPY=.515e6150-6694-4c2b-badb-92e7a01c27f9@github.com>
 <DSnhhi5j1brEuC9G2EBE9qLLls6buNF76bouRTCihZI=.fece0bfb-4dbd-4837-8633-a3f45f25fcea@github.com>
Message-ID: <Mh3X2s6pZePkVvKpfhHT3UhreLaz0cbm-JTNdyWY5XE=.0fcb2faf-57e4-4564-b571-ec88d9e21bd2@github.com>

On Fri, 17 Jan 2025 06:05:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Do the gtest changes not require something in make/hotspot/lib/CompileGtest.gmk?

I don't see anything obvious that needs to be changed.

I've verified that turning precompiled headers on adds the correct flags for gtests and that gtestMain.cpp gets compiled without precompiled headers (as requested in the make file).

> 
> Otherwise as long as this works it seems fine. (I presume the necessary compilers didn't support this when we made the original switch from includeDB.)

... or no one involved in that changed figured out that this was a possibility.

> 
> I expect there are copyrights that need updating (though not too many once Coleen has finished with her changes :) ).

Right. As long as we should update the copyrights even if we just remove code ...

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23146#issuecomment-2597664562

From jwaters at openjdk.org  Fri Jan 17 08:28:42 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Jan 2025 08:28:42 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <TjJpdLzmCytac5a1Rz551BUxdm3vszWrNUlIH9sHg-k=.843f2f2a-fdd9-4fe0-928e-c7785c7b83e8@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/3f725101...9d05cb8e

> Member

Fixing the JVM under LTO is likely to be a heavy undertaking, much more so than just unbreaking compilation and linking of the JVM (Ignoring that the JVM later crashes when the newly compiled JDK is used to build parts of itself), I'm not sure it would be feasible under the current Pull Request

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2597685300

From mbaesken at openjdk.org  Fri Jan 17 08:43:37 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 17 Jan 2025 08:43:37 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <TjJpdLzmCytac5a1Rz551BUxdm3vszWrNUlIH9sHg-k=.843f2f2a-fdd9-4fe0-928e-c7785c7b83e8@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <TjJpdLzmCytac5a1Rz551BUxdm3vszWrNUlIH9sHg-k=.843f2f2a-fdd9-4fe0-928e-c7785c7b83e8@github.com>
Message-ID: <2y8p-J2SCTANChv8WvrXmYI1UjVxbC7n8tUJzBOMzEE=.7c2b48a5-423e-4138-8671-3037e8963730@github.com>

On Fri, 17 Jan 2025 08:26:17 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > Member
> 
> Fixing the JVM under LTO is likely to be a heavy undertaking, much more so than just unbreaking compilation and linking of the JVM (Ignoring that the JVM later crashes when the newly compiled JDK is used to build parts of itself), I'm not sure it would be feasible under the current Pull Request

I was able to build the OpenJDK with LTO enabled on Linux and Windows (so the new JVM does not crash in the build). I just had to not enable gtest because this is currently not compiling with LTO enabled.  I was able to run a few benchmarks with the LTO enabled JVM , but  as far as I remember a couple of HS jtreg tests fail with LTO enabled  because they have some expectations that might not (yet) work with LTO.

Regarding gtest, I created
https://bugs.openjdk.org/browse/JDK-8346987
8346987: [lto] gtest build fails
 Do you think it would be okay to change the build so that the LTO related flags (in case lto is enabled) do not 'go'  into the gtest build ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2597709145

From shade at openjdk.org  Fri Jan 17 08:46:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 17 Jan 2025 08:46:49 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23170#pullrequestreview-2558274955

From rehn at openjdk.org  Fri Jan 17 08:51:45 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 17 Jan 2025 08:51:45 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads
Message-ID: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>

Hi, please consider!

This patch the Zfa zli floating point immediate load.
As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.

When using one of the 32 'popular' floats we can now materialze them without a load.
E.g.
`float f = f1 * 0.5 + f2 * 2.0;`
Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.

As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.

Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.

Passes:
./test/jdk/java/lang/Math
./test/hotspot/jtreg/compiler/floatingpoint/
./test/jdk/java/util/Formatter/
./test/jdk/java/lang/Float/
./test/jdk/java/lang/Double/
./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
./test/hotspot/jtreg/compiler/eliminateAutobox/
./test/hotspot/jtreg/vmTestbase/jit/

Running tier1

Thanks!

-------------

Commit messages:
 - Baseline

Changes: https://git.openjdk.org/jdk/pull/23171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23171&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347981
  Stats: 201 lines in 7 files changed: 192 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23171/head:pull/23171

PR: https://git.openjdk.org/jdk/pull/23171

From jwaters at openjdk.org  Fri Jan 17 08:55:39 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Jan 2025 08:55:39 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <WGOBVoOwj2WxmcoXh_fXM917Rk9QNrTZPKea-agaJK0=.58b7d1ff-c107-4d48-9a03-744b8f4a36dd@github.com>

On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
>> 
>> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
>> - -flto is set to $(JOBS) instead of auto to better match what the user requested
>> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/133b1009...9d05cb8e

That's great news that the JVM can run with LTO enabled! (Well, even if only briefly) I think not doing LTO for gtest is fine, since it's a test suite and not the product itself. I think it would be cleaner to cut out the LTO flags rather than pass -fno-lto to gtest however. Out of curiosity, does gtest fail to compile on Linux or Windows for you? Even with LTO active, 100% of it compiles on my end, under Windows/gcc

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2597730525

From mbaesken at openjdk.org  Fri Jan 17 09:25:37 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 17 Jan 2025 09:25:37 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <WGOBVoOwj2WxmcoXh_fXM917Rk9QNrTZPKea-agaJK0=.58b7d1ff-c107-4d48-9a03-744b8f4a36dd@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <WGOBVoOwj2WxmcoXh_fXM917Rk9QNrTZPKea-agaJK0=.58b7d1ff-c107-4d48-9a03-744b8f4a36dd@github.com>
Message-ID: <kPRtrY7CnMHSpoTlAgdOfK74eT8UKS-u503DVt4NeBw=.e3813468-b021-4196-a347-1d2b1204d4d7@github.com>

On Fri, 17 Jan 2025 08:52:43 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Out of curiosity, does gtest fail to compile on Linux or Windows for you?

On Linux.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2597788634

From mdoerr at openjdk.org  Fri Jan 17 11:01:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 17 Jan 2025 11:01:50 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
Message-ID: <a7tM86M47I4t69BX1UQPNyx56yMDKeQL7j7GV8fCuBQ=.fd3af16e-fc72-46e3-93a3-55887b308f16@github.com>

On Wed, 15 Jan 2025 14:00:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

We have also run tests and found a problem while running TestCodeEntryAlignment on MacOS x64:

assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000000116f36800 <= 0x0000000116f4a941 <= 0x0000000116f4a940



V  [libjvm.dylib+0x2cfa52]  AbstractAssembler::emit_int24(int, int, int)+0x112
V  [libjvm.dylib+0x2d5a2c]  Assembler::vex_prefix_and_encode(int, int, int, Assembler::VexSimdPrefix, Assembler::VexOpcode, InstructionAttr*, bool, bool, bool)+0x19c
V  [libjvm.dylib+0x3681d8]  Assembler::rorxq(Register, Register, int)+0x98
V  [libjvm.dylib+0xe5232c]  MacroAssembler::sha512_AVX2_one_round_compute(Register, Register, Register, Register, Register, Register, Register, Register, Register, int)+0x1ac
V  [libjvm.dylib+0xe54222]  MacroAssembler::sha512_AVX2(XMMRegister, XMMRegister, XMMRegister, XMMRegister, XMMRegister, XMMRegister, XMMRegister, XMMRegister, Register, Register, Register, Register, Register, bool, XMMRegister)+0x1552
V  [libjvm.dylib+0x12ba8a4]  StubGenerator::generate_sha512_implCompress(StubGenStubId)+0xf4
V  [libjvm.dylib+0x12c4d42]  StubGenerator::generate_compiler_stubs()+0x8d2
V  [libjvm.dylib+0x12c563a]  StubGenerator_generate(CodeBuffer*, StubGenBlobId)+0x1a
V  [libjvm.dylib+0x1324efb]  initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*)+0xcb
V  [libjvm.dylib+0x1325376]  compiler_stubs_init(bool)+0x96
V  [libjvm.dylib+0x4cb317]  C2Compiler::init_c2_runtime()+0x117


In addition, gc/shenandoah/TestStringInternCleanup_default failed on MacOS aarch64 and linuxmuslx86_64:

assert(nk >= _lowest_valid_narrow_klass_id && nk <= _highest_valid_narrow_klass_id) failed: narrowKlass ID out of range (3131947710)



V  [libjvm.dylib+0x59052c]  print_error_for_unit_test(char const*, char const*, char*)+0x0
V  [libjvm.dylib+0x59f294]  PromoteFailureClosure::do_oop(oop*)+0x0
V  [libjvm.dylib+0x727f5c]  oopDesc::klass() const+0xfc
V  [libjvm.dylib+0x8b1c38]  java_lang_String::equals(oop, oop)+0xa0
V  [libjvm.dylib+0x118b548]  StringTableLookupOop::equals(WeakHandle*)+0xec
V  [libjvm.dylib+0x118b390]  ConcurrentHashTable<StringTableConfig, (MemTag)11>::Node* ConcurrentHashTable<StringTableConfig, (MemTag)11>::get_node<StringTableLookupOop>(ConcurrentHashTable<StringTableConfig, (MemTag)11>::Bucket const*, StringTableLookupOop&, bool*, unsigned long*) const+0x80
V  [libjvm.dylib+0x118c050]  bool ConcurrentHashTable<StringTableConfig, (MemTag)11>::internal_insert_get<StringTableLookupOop, bool ConcurrentHashTable<StringTableConfig, (MemTag)11>::insert<StringTableLookupOop>(Thread*, StringTableLookupOop&, WeakHandle const&, bool*, bool*)::NOP>(Thread*, StringTableLookupOop&, WeakHandle const&, bool ConcurrentHashTable<StringTableConfig, (MemTag)11>::insert<StringTableLookupOop>(Thread*, StringTableLookupOop&, WeakHandle const&, bool*, bool*)::NOP&, bool*, bool*)+0x178
V  [libjvm.dylib+0x1187684]  StringTable::do_intern(StringWrapperInternal const&, unsigned long, JavaThread*)+0x234
V  [libjvm.dylib+0x1187074]  StringTable::intern(StringWrapperInternal const&, JavaThread*)+0x238
V  [libjvm.dylib+0x11872a4]  StringTable::intern(oop, JavaThread*)+0x1b4
V  [libjvm.dylib+0xa39b30]  JVM_InternString+0x148

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2598064527

From mdoerr at openjdk.org  Fri Jan 17 11:13:36 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 17 Jan 2025 11:13:36 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <KgEhmgv_Fi10MEnLFlnhom1-EgF6-6H7c0Ac2zZapJA=.a145a10b-d65c-4fae-a3f2-d538663863c2@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 600:

> 598: 
> 599:   __ ld(tmp, in_bytes(ShenandoahThreadLocalData::card_table_offset()), R16_thread);
> 600:   __ add(tmp, /* card_table_base */ tmp, R0);

This looks wrong. R0 is an uninitialized register. We shouldn't add it. (Note that it is used as scratch register in the old code.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920010189

From aph at openjdk.org  Fri Jan 17 11:15:39 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 17 Jan 2025 11:15:39 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
Message-ID: <j9MUYAMBNROCxl5XZgTZcjVuktgGtU9Atc9acN_xHn8=.e280036d-f9e5-4157-bf9d-c1d0399dac7f@github.com>

On Thu, 9 Jan 2025 09:07:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

This reference is even better, and comes with complete source code as well as the proofs:

https://web.archive.org/web/20110609115824/https://software.intel.com/file/24918

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2598113867

From gcao at openjdk.org  Fri Jan 17 11:34:41 2025
From: gcao at openjdk.org (Gui Cao)
Date: Fri, 17 Jan 2025 11:34:41 GMT
Subject: Integrated: 8342881: RISC-V: secondary_super_cache does not scale
 well: C1 and interpreter
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <KsZYkpn72zoliBSy0tfdD6blcmySAmcp1D87-ZPhJbw=.fec787b9-4a60-415b-906e-c41b25364f78@github.com>

On Wed, 6 Nov 2024 10:33:55 GMT, Gui Cao <gcao at openjdk.org> wrote:

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

This pull request has now been integrated.

Changeset: 8460072f
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8460072f9ddcec5d1f86e3c4de3d1457771b805c
Stats:     374 lines in 5 files changed: 300 ins; 23 del; 51 mod

8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

Reviewed-by: fyang, fjiang

-------------

PR: https://git.openjdk.org/jdk/pull/21922

From coleenp at openjdk.org  Fri Jan 17 12:18:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 12:18:52 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
Message-ID: <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>

> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Added the needed blank.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23160/files
  - new: https://git.openjdk.org/jdk/pull/23160/files/87fdb72f..c646de2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23160&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23160&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23160/head:pull/23160

PR: https://git.openjdk.org/jdk/pull/23160

From coleenp at openjdk.org  Fri Jan 17 12:18:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 12:18:52 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <t4eG8WFq2zfyOk8f-50NQfaMSN6VRSwTA8Zkd7worZ0=.bc702046-7e9c-4e4d-86cf-7f245bc0f058@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
 <t4eG8WFq2zfyOk8f-50NQfaMSN6VRSwTA8Zkd7worZ0=.bc702046-7e9c-4e4d-86cf-7f245bc0f058@github.com>
Message-ID: <G3Er8sZIxdK7xTk9U13W7HjD-Vtmq8zH45ASZV2RZJk=.f6210dc4-e7ce-428f-af04-89003f3f0739@github.com>

On Fri, 17 Jan 2025 04:00:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added the needed blank.
>
> src/hotspot/share/oops/array.hpp line 77:
> 
>> 75: 
>> 76:     size_t elements = left / sizeof(T);
>> 77:     assert(elements <= (size_t)INT_MAX, "number of elements %zudoesn't fit into an int.", elements);
> 
> Nit: It seems that a space is needed after `%zu`. This was this way originally.

I added the space, since you read through carefully enough to see it.  Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23160#discussion_r1920107348

From azafari at openjdk.org  Fri Jan 17 12:58:43 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 17 Jan 2025 12:58:43 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v15]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <--YvZjvTYg5GMCaEfoILeaR7Nmh_RYgp9rreZiL8X6A=.da5d032d-f8fe-40e5-b8e4-f19e0473b932@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  undo overlapping checks.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/abaf0b37..c8aa9c5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=13-14

  Stats: 68 lines in 4 files changed: 0 ins; 68 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 coleenp at openjdk.org  Fri Jan 17 13:51:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 13:51:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <jHXmlfEjYUya7xtaqiYVhlpjL1CrkDTiSRJgHtqToJE=.0e33ebfe-6ef6-4405-b3f2-fc07c6b520b6@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

I reran our internal tests tier1-7 on this change and they all passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2598408532

From mbaesken at openjdk.org  Fri Jan 17 13:53:35 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 17 Jan 2025 13:53:35 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <2y8p-J2SCTANChv8WvrXmYI1UjVxbC7n8tUJzBOMzEE=.7c2b48a5-423e-4138-8671-3037e8963730@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <TjJpdLzmCytac5a1Rz551BUxdm3vszWrNUlIH9sHg-k=.843f2f2a-fdd9-4fe0-928e-c7785c7b83e8@github.com>
 <2y8p-J2SCTANChv8WvrXmYI1UjVxbC7n8tUJzBOMzEE=.7c2b48a5-423e-4138-8671-3037e8963730@github.com>
Message-ID: <3peOk4hOWRVX3sn5BHQbRh5ymyP8Sr146H66jDWkePA=.ef3d0788-2bfa-421b-ad92-a1e46fd0feb5@github.com>

On Fri, 17 Jan 2025 08:40:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I was able to run a few benchmarks with the LTO enabled JVM , 
> but as far as I remember a couple of HS jtreg tests fail with LTO enabled because they have some expectations that might not (yet) work with LTO

On Linux x86_64  (gcc 11.3 devkit) ,  when building with lto enabled, the  jdk  :tier1  jtreg  tests all worked nicely in my environment.
The HS :tier1 jtreg tests  had  51 failures, 50 in the  serviceability/sa  area .
Those failures (from  serviceability/sa) seem to have in common that they show such an exception 

 stderr: [Exception in thread "main" java.lang.InternalError: Metadata does not appear to be polymorphic
	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40)
	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82)
	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101)
	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$19.doit(CommandProcessor.java:926)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2230)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2200)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2071)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:285)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)

or   test   serviceability/sa/TestJhsdbJstackMixed.java

 stderr: [java.lang.InternalError: Metadata does not appear to be polymorphic
	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Oop.getKlassForOopHandle(Oop.java:224)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:180)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.VMOopHandle.resolve(VMOopHandle.java:61)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getThreadObj(JavaThread.java:365)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:438)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:80)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:79)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
]


Not sure what it exactly means, maybe the lto optimization removes some metadata related information that is expected ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2598410228

From duke at openjdk.org  Fri Jan 17 14:41:38 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 17 Jan 2025 14:41:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <WEiFAz-FShZOwNi18bW4sNlJ6o4L62hJ0W_59bbhCLc=.972d8c09-cad5-423c-b0f4-e2229d64fec9@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

Thank you everyone for your feedback and time reviewing this!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2598509189

From duke at openjdk.org  Fri Jan 17 14:41:39 2025
From: duke at openjdk.org (duke)
Date: Fri, 17 Jan 2025 14:41:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <yuKDaZnvBXvb06vkHPpzUk9a-AgBuH1KHFr8_RWc1fo=.f261eb1e-4f20-4bb1-8f42-7258a9a20416@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

@roberttoyonaga 
Your change (at version 57d0fba0f8abaa1afaf42c5380770adc80d20a0d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2598511295

From mli at openjdk.org  Fri Jan 17 14:49:41 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 17 Jan 2025 14:49:41 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads [v3]
In-Reply-To: <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>
Message-ID: <GSEhT091cRPUlZoYgf2-ZTnT8IMsPc5-9_qRSMYFpFE=.8ffc09a5-e292-4de9-b48d-4b79757b192a@github.com>

On Fri, 10 Jan 2025 11:59:10 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
>> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
>> 
>> If we need them before hwprobe we can add a flag for manually enabling them.
>> 
>> Sanity tested.
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove header

Looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23003#pullrequestreview-2559204355

From stuefe at openjdk.org  Fri Jan 17 14:49:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Jan 2025 14:49:55 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
Message-ID: <X_pNb22tPnaIOxkTmu_vn4WBHUrgUNaV0U2LlS-JqfQ=.67b0ac6b-8ad6-41bf-bc6e-f8e467975c4d@github.com>

On Fri, 10 Jan 2025 10:03:22 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified comment

Checked basic tree rotation functions, more to follow later

src/hotspot/share/utilities/rbTree.hpp line 93:

> 91:     void replace_child(RBNode* old_child, RBNode* new_child);
> 92: 
> 93:     // Move node down to the left, and right child up

Suggestion:

    // This node down, right child up
    // Returns right child (now parent)

(different papers use left/right in different ways, I always get confused. A clear concise comment helps)

src/hotspot/share/utilities/rbTree.hpp line 96:

> 94:     RBNode* rotate_left();
> 95: 
> 96:     // Move node down to the right, and left child up

Suggestion:

    // This node down, left child up
    // Returns left child (now parent)

src/hotspot/share/utilities/rbTree.inline.hpp line 39:

> 37:   } else if (_right == old_child) {
> 38:     _right = new_child;
> 39:   }

I would add an assert for the else case here, since not matching any child is an error in all call cases.

src/hotspot/share/utilities/rbTree.inline.hpp line 51:

> 49:   if (old_right->_left != nullptr) {
> 50:     old_right->_left->_parent = this;
> 51:   }

Suggestion:

  if (_right != nullptr) {
    _right->_parent = this;
  }

Alternatively  a `set_parent(node)`, equivalent to the existing `set_child()`, with nullptr handling, would be even better

src/hotspot/share/utilities/rbTree.inline.hpp line 58:

> 56:   } else if (is_right_child()) {
> 57:     _parent->_right = old_right;
> 58:   }

Suggestion:

   _parent->replace_child(this, old_right);

src/hotspot/share/utilities/rbTree.inline.hpp line 75:

> 73:   if (old_left->_right != nullptr) {
> 74:     old_left->_right->_parent = this;
> 75:   }

Suggestion:

  if (_left != nullptr) {
    _left->_parent = this;
  }

src/hotspot/share/utilities/rbTree.inline.hpp line 82:

> 80:   } else if (is_right_child()) {
> 81:     _parent->_right = old_left;
> 82:   }

Suggestion:

  _parent->replace_child(this, old_left);

-------------

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2559047396
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920281600
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920282747
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920209864
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920275899
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920277700
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920291041
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920292496

From matsaave at openjdk.org  Fri Jan 17 15:02:41 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 17 Jan 2025 15:02:41 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
 <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
Message-ID: <I2SjOxy8Z_lIxUiHHivS7yc4xXIyXuagiMiMJaPtjL4=.1cca72fa-5d61-4baf-8e91-453f9350514d@github.com>

On Fri, 17 Jan 2025 12:18:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the needed blank.

Changes look good!

src/hotspot/share/utilities/globalDefinitions.hpp line 137:

> 135: #define UINT64_FORMAT_0          "%016"       PRIx64
> 136: 
> 137: 

Extra newline added here, was that on purpose?

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23160#pullrequestreview-2559235603
PR Review Comment: https://git.openjdk.org/jdk/pull/23160#discussion_r1920318853

From ysr at openjdk.org  Fri Jan 17 15:09:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 17 Jan 2025 15:09:35 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <lNguXjkHP0ET0RdCYmR_QIlNUQlwa_jIxklZ4pMLqYc=.952dcda2-8cdf-4bd9-bf8f-6897f9267d1a@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

Thanks for implementing this very important feature which already improves performance (and which will further unlock better performance when init-mark becomes a per-thread handshake in the future).

> Our internal performance testing showed a significant reduction in the duration of init-mark pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.

It would be great if you can include some performance numbers either in this PR or, preferably, in the JBS ticket.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2598567393

From stuefe at openjdk.org  Fri Jan 17 15:12:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Jan 2025 15:12:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <WEiFAz-FShZOwNi18bW4sNlJ6o4L62hJ0W_59bbhCLc=.972d8c09-cad5-423c-b0f4-e2229d64fec9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
 <WEiFAz-FShZOwNi18bW4sNlJ6o4L62hJ0W_59bbhCLc=.972d8c09-cad5-423c-b0f4-e2229d64fec9@github.com>
Message-ID: <ixNGddhDA_Rv9EOvzjVdjLKB89Ufw8P-yPd6uuUqANg=.eed96e42-9018-4921-bb7f-27857e317a0e@github.com>

On Fri, 17 Jan 2025 14:37:49 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert back to using a flag.
>
> Thank you everyone for your feedback and time reviewing this!

@roberttoyonaga Hold off, I still wait for the SAP people to report back with their tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2598574044

From galder at openjdk.org  Fri Jan 17 15:31:46 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 17 Jan 2025 15:31:46 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v9]
In-Reply-To: <F09kHLR226iJitk5GW7_WBxmN2eXSBQ_JE3QRWa4ZbA=.0c043e20-6f7f-4db4-bfae-f6c6784472aa@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com>
 <F09kHLR226iJitk5GW7_WBxmN2eXSBQ_JE3QRWa4ZbA=.0c043e20-6f7f-4db4-bfae-f6c6784472aa@github.com>
Message-ID: <zcdiXHJupu94Ts4Za4MhJFI-1Stkp1wSzUH2R4RuCqQ=.fa106716-088e-4d08-99ff-9bf8c819006d@github.com>

On Tue, 14 Jan 2025 08:33:36 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make sure it runs with cpus with either avx512 or asimd
>
> test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 107:
> 
>> 105:         int aboveCount, abovePercent;
>> 106: 
>> 107:         // Iterate until you find a set that matches the requirement probability
> 
> Can you give a high-level definition / explanation what this does?
> Also: what is the expected number of rounds you iterate here? I'm asking because I would like to be sure that a timeout is basically impossible because the probability is too low.

Sure I'll add. It's an approximation to make it run fast as sizes increase. In the worst case I've seen it take 15 rounds when size was 100, 50% probability and got 50 below max and 50 above. But with bigger array sizes, say 10'000, and 50% probability aim, it can take 1 or 2 rounds ending up with 5027 above max, 4973 below max.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1920359437

From lmesnik at openjdk.org  Fri Jan 17 15:45:49 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Jan 2025 15:45:49 GMT
Subject: Integrated: 8347840: Fix testlibrary compilation warnings
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <u7VnWMvtDBNYJIVxaVgjlaGgU5QhleZEEPfFtt5KXiM=.4916d0dd-7d9b-4255-ab0c-1e673451c50c@github.com>

On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

This pull request has now been integrated.

Changeset: 2ca1b4d4
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ca1b4d48da7eb9b5baf0ac213f3ce87f47dd316
Stats:     120 lines in 30 files changed: 25 ins; 42 del; 53 mod

8347840: Fix testlibrary compilation warnings

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/23143

From galder at openjdk.org  Fri Jan 17 15:48:43 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 17 Jan 2025 15:48:43 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
 <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
Message-ID: <3rstCr_f43zEJRn6I1q5D-oUKH84wNWO4h_I6ZrOGc4=.014f8a93-2471-45d0-9634-73dbd086c428@github.com>

On Tue, 14 Jan 2025 05:07:55 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> @galderz So you want me to review again?
>
> @eme64 I've fixed the test issue, it's ready to be reviewed

> @galderz I don't remember from above, but did you ever run the Long Min/Max benchmarks from this?
https://github.com/openjdk/jdk/pull/21032 Would just be nice to see that they have an improvement after this change :)

Looking at the benchmark the arrays are loaded with random data with no control over which branch side will be taken. So there's no guarantees that you will see an improvement for the reasons I explained in https://github.com/openjdk/jdk/pull/20098#issuecomment-2379386872. To summarise what was observed there:

* In AVX-512 you will only see an improvement when one of the min/max branches is taken ~100% of the time.
* In non-AVX-512 this patch will create a regression when one of the min/max branches is taken ~100% of time.

If it helps I'm happy to document this in detail in the `MinMaxVector` benchmark added here.

I would expect a similar thing to happen when it comes to asimd envs with max vector size >= 32 (e.g. Graviton 3). Those will see vectorization occur and improvements kick in at 100%. Other systems (e.g. Graviton 4) will see a regression at 100%. This means that your work in https://github.com/openjdk/jdk/pull/20098#discussion_r1901576209 to avoid the max vector size limitation might become more important once my PR here goes in.

I'm wondering if the long min/max benchmarks introduced in https://github.com/openjdk/jdk/pull/21032 should remain because their results are not predictable and that's not a good situation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2598645987

From luhenry at openjdk.org  Fri Jan 17 15:56:39 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Fri, 17 Jan 2025 15:56:39 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads
In-Reply-To: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
Message-ID: <yI5YtZKwsMUtmnfkfieMLGxeGA0l0lBvVrP6_CeFvnI=.c6af5027-6154-43d8-b3ae-6b3241cc55fa@github.com>

On Fri, 17 Jan 2025 08:47:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider!
> 
> This patch the Zfa zli floating point immediate load.
> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
> 
> When using one of the 32 'popular' floats we can now materialze them without a load.
> E.g.
> `float f = f1 * 0.5 + f2 * 2.0;`
> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
> 
> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
> 
> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
> 
> Passes:
> ./test/jdk/java/lang/Math
> ./test/hotspot/jtreg/compiler/floatingpoint/
> ./test/jdk/java/util/Formatter/
> ./test/jdk/java/lang/Float/
> ./test/jdk/java/lang/Double/
> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> ./test/hotspot/jtreg/compiler/eliminateAutobox/
> ./test/hotspot/jtreg/vmTestbase/jit/
> 
> Running tier1
> 
> Thanks!

src/hotspot/cpu/riscv/assembler_riscv.hpp line 335:

> 333: private:
> 334: 
> 335:   bool static zfa_zli_lookup_double(uint64_t value, int* Rs) {

Suggestion:

  static bool zfa_zli_lookup_double(uint64_t value, int* Rs) {

src/hotspot/cpu/riscv/assembler_riscv.hpp line 376:

> 374: 
> 375: 
> 376:   bool static zfa_zli_lookup_float(uint32_t value, int* Rs = nullptr) {

Suggestion:

  static bool zfa_zli_lookup_float(uint32_t value, int* Rs = nullptr) {

src/hotspot/cpu/riscv/assembler_riscv.hpp line 431:

> 429:     }
> 430:     uint64_t d_bits = (uint64_t)julong_cast(d);
> 431:     return zfa_zli_lookup_double(d_bits, Rs);

Would it better to inline the switch here directly? Is it used anywhere else?

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2634:

> 2632:   }
> 2633:   int Rs = -1;
> 2634:   can_zfa_zli_float(imm, &Rs);

should that be a `guarantee(can_zfa_zli_float(imm, &Rs));`?

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2645:

> 2643:   }
> 2644:   int Rs = -1;
> 2645:   can_zfa_zli_double(imm, &Rs);

should that be a `guarantee(can_zfa_zli_double(imm, &Rs));`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1920394378
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1920393982
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1920393473
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1920392131
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1920388910

From lmesnik at openjdk.org  Fri Jan 17 15:59:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Jan 2025 15:59:50 GMT
Subject: RFR: 8338428: Add logging if final VM flags while setting
 properties [v5]
In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
Message-ID: <UW34yuClWQ6bI52wdtBnQskObcxFzjExYyiAq5VjWx0=.a7d52212-8f9b-4a96-a44f-3ffbd9946c24@github.com>

> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
> 
> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
> 
> Update:
> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  copyrights updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23054/files
  - new: https://git.openjdk.org/jdk/pull/23054/files/28b05e9b..b28439c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=03-04

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23054/head:pull/23054

PR: https://git.openjdk.org/jdk/pull/23054

From jbhateja at openjdk.org  Fri Jan 17 16:02:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 17 Jan 2025 16:02:55 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions incorporated.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/43aa3eb7..692de9c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=09-10

  Stats: 116 lines in 6 files changed: 67 ins; 17 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Fri Jan 17 16:02:55 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 17 Jan 2025 16:02:55 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v9]
In-Reply-To: <iPfktRIFP--gP1VL1_lyV_Shj-5GRpbRFMit_h9A8Cg=.c9415921-b0b8-475d-8b9c-3bff3bc75d26@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <wrRabGtlKbJzKd8AobAos1COfWY4NkLx1MOxXiuF4NA=.87576761-eb9c-4546-b098-71d1532324d7@github.com>
 <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com>
 <zX9mex0SPUb8umMa8uRwPvj9nsKwzoOqNio0CF8xPrA=.1c82220b-e200-4654-a67e-7ffbcf7a3bdb@github.com>
 <j0cnWHdkWhJSs8CvM6EbIQpPld66a-mRHKbXKl-cOZw=.edc40acc-c892-4e46-8bbf-b6205336ecad@github.com>
 <dwyK1YzhzuD35JrKaxQdjACVH6-BgEQZCdvclQKhra4=.27cd66d0-b881-435e-b369-1c081e6a4444@github.com>
 <DEFSfPceUTnEqdWftLVAaf_6LUl7rsD3nV1drpBsdnY=.ec2bd11e-123a-4891-a8ea-82f7d0423c84@github.com>
 <iPfktRIFP--gP1VL1_lyV_Shj-5GRpbRFMit_h9A8Cg=.c9415921-b0b8-475d-8b9c-3bff3bc75d26@github.com>
Message-ID: <qZjMz7JQTsrcI0yN0EZ7tJ3ToSSf5Y6n8yeUvCmDRHs=.47f8f2aa-8681-4e76-bcf6-d0a4586e64d9@github.com>

On Wed, 15 Jan 2025 00:28:50 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi @PaulSandoz ,
>> 
>> In  above code snippet the return type 'short' of intrinsic call does not comply with the value being returned which is of box type, thereby mandating addition glue code. 
>> 
>> Regular primitive type boxing APIs are lazily intrinsified, thereby generating  an intrinsifiable Call IR during parsing. 
>> LoadNode?s idealization can fetch a boxed value from the input of boxing call IR and directly forward it to users.
>> 
>> Q1. What is the problem in directly passing Float16 boxes to FMA and SQRT intrinsic entry points?
>> 
>> A. The compiler will have to unbox them before the actual operation. There are multiple schemes to perform unboxing, such as name-based, offset-based, and index-based field lookup. 
>> Vector API unbox expansion uses an offset-based payload field lookup, for this it bookkeeps the payload?s offset over runtime representation of VectorPayload class created as part of VM initialization.
>> However, VM can only bookkeep this information for classes that are part of java.base module, Float16 being part of incubation module cannot use offset-based field lookup.  Thus only viable alternative is to unbox using field name/index based lookup.
>> For this compiler will first verify that the incoming oop is of Float16 type and then use a hardcoded name-based lookup to Load the field value. This looks fragile as it establishes an unwanted dependency b/w Float16 field names and compiler implementation, same applies to index-based lookup as index values are dependent onthe combined field count of class and instance-specific fields, thus any addition or deletion of a class-level static helper field before the field of interest can invalidate any hardcoded index value used by the compiler. 
>> All in all, for safe and reliable unboxing by compiler, it's necessary to create an upfront VM representation like vector_VectorPayload.
>> 
>> Q2. What are the pros and cons of passing both the unboxed value and boxed values to the intrinsic entry point?
>> A.  
>> Pros:
>> - This will save unsafe unboxing implementation if the holder class is not part of java.base module.
>> - We can leverage existing box intrinsification infrastructure which directly forwards the embedded values to its users.
>> - Also, it will minimize the changes in the Java side implementation.
>> 
>> Cons:
>> - It's suboptimal in case the call is neither intrinsified or inlined, as it will add additional spills before the call.
>> 
>> Q3.  Primitive box class boxing API ?valueOf? accepts...
>
>> Given the above observations passing 3 additional box arguments to intrinsic and returning a box value needs additional changes in the compiler while minor re-structuring in Java implementation packed with in the glue logic looks like a reasonable approach.
> 
> Did you mean to say *no* additional changes in the compiler? Otherwise, if not what would those changes be?

Hi @PaulSandoz ,

Many thanks for your suggestion. From a compiler standpoint, changes are mainly around unboxing/boxing arguments and return values. Since the _Float16_ class is defined in the incubation module, we cannot refer to it in the wrapper class _Float16Math_ which is part of _java.base_ module. Thus, lambda must pass the boxes as _java.lang.Object_ type arguments will introduce additional type sharpening casts in lambda and defeat our purpose of preserving unmodified code in lambda. The current scheme only deals in intrinsic with short parameters and return values and is free from these concerns.

The user may declare MUL and ADD as separate operations, and to honor JLS specification and precise floating-point model semantics we should not infer an FMA scalar operation, thus, intrinsification is appropriate here rather than a pattern match.

With this incremental commit, I am trying to minimize the Java side changes. Let me know if this looks fine to you.

Verified that auto-vectorization planned for follow-on patch is aligned with new changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1920398466

From cnorrbin at openjdk.org  Fri Jan 17 16:15:18 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 17 Jan 2025 16:15:18 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v13]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <7UzEIAt_1LRqLecETD910uvyl4KaOFYBexUk9_9DLgc=.ae1be7f2-1d79-4400-9acf-cd7c58ad9f94@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with two additional commits since the last revision:

 - thomas feedback
 - axel feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/b2835590..e1790595

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=11-12

  Stats: 468 lines in 3 files changed: 205 ins; 148 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From stuefe at openjdk.org  Fri Jan 17 16:15:19 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Jan 2025 16:15:19 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
Message-ID: <XKQd5cNu_MfeszXsQhqV40nTTy8RbfIwI7yA81iPnE0=.c0e92195-2cdb-4cfe-ab44-af05ca0208d6@github.com>

On Fri, 10 Jan 2025 10:03:22 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarified comment

Some more comments, continue next week

src/hotspot/share/utilities/rbTree.hpp line 121:

> 119:   }
> 120: 
> 121:   static inline bool is_black(RBNode* node) {

Suggestion:

  // True if node is black (nil nodes count as black)
  static inline bool is_black(const RBNode* node) {

src/hotspot/share/utilities/rbTree.hpp line 125:

> 123:   }
> 124: 
> 125:   static inline bool is_red(RBNode* node) {

Suggestion:

  static inline bool is_red(const RBNode* node) {

src/hotspot/share/utilities/rbTree.hpp line 129:

> 127:   }
> 128: 
> 129:   RBNode* find_node(RBNode* curr, const K& k);

All callers start at `_root`, you may just as well scrap the `curr` parameter and hard-wire root as starting point.
Also, as others remarked, a const version would be good (const_cast<> redirection is fine). Then, `find()` can also be const.

src/hotspot/share/utilities/rbTree.inline.hpp line 136:

> 134: RBTree<K, V, COMPARATOR, ALLOCATOR>::find_node(RBNode* curr, const K& k) {
> 135:   while (curr != nullptr) {
> 136:     int key_cmp_k = COMPARATOR::cmp(k, curr->key());

Suggestion:

    const int key_cmp_k = COMPARATOR::cmp(k, curr->key());

(Matter of taste, up to you. I litter my code with const, but others don't.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2559217922
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920308441
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920311319
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920319795
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920327264

From gziemski at openjdk.org  Fri Jan 17 16:21:35 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 17 Jan 2025 16:21:35 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory
In-Reply-To: <Ip4bXpuQrTVWWtbGxNqfLqBVuh2lehZnNBSiiKO21OE=.aa2791be-9e8e-4874-94ed-dfd50777e538@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <Ip4bXpuQrTVWWtbGxNqfLqBVuh2lehZnNBSiiKO21OE=.aa2791be-9e8e-4874-94ed-dfd50777e538@github.com>
Message-ID: <7qAPUArhTmcIGjvpoI_hxrE7Edm2FUruEK0UaVHQg3s=.82976906-0dc8-4e9a-964b-3983b8873715@github.com>

On Thu, 16 Jan 2025 22:28:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @gerard-ziemski we should not have a bunch of Java files for this in the hotspot source tree. Benchmarks should be in the test tree somewhere. Can this not be integrated into existing benchmark frameworks i.e. JMH?

The java related files are totally optional and are example of one way to analyze the results. They are NOT in `hotspot`, they are in `src/utils`:


# ls -la src/utils
total 0
drwxr-xr-x   7 gerard  staff   224 Jan 14 13:09 .
drwxr-xr-x  76 gerard  staff  2432 Jan 14 13:09 ..
drwxr-xr-x  24 gerard  staff   768 Jan 13 15:46 IdealGraphVisualizer
drwxr-xr-x   7 gerard  staff   224 Jan 13 15:46 LogCompilation
drwxr-xr-x   8 gerard  staff   256 Jan 13 15:46 hsdis
drwxr-xr-x  18 gerard  staff   576 Jan 14 14:47 nmt
drwxr-xr-x   3 gerard  staff    96 Jan 13 15:46 src


together with other weird tools.

There are only 2 new files in `src/hotspot/share/nmt`:

`memLogRecorder.cpp` and `memLogRecorder.hpp`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2598711069

From cnorrbin at openjdk.org  Fri Jan 17 16:22:45 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 17 Jan 2025 16:22:45 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
Message-ID: <IM-DKmNqrABbqAyvyqWlD75NX2Bv1EIreKNFGbZximw=.f5b9d3f6-a79d-4fb9-96a4-1c1e1e62aa17@github.com>

On Thu, 16 Jan 2025 11:09:38 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified comment
>
> Good work on the RB-tree implementation.
> 
> I am no expert in RB-trees but the implementation does not look obviously incorrect. And the gtest and verification looks comprehensive. (Only thing I might have extended is to randomness to also check the visitor and iterators. Something like generating a random ordered set of keys in a different container, insert them in some random order, maybe including insertions and removals of other keys and then check that the visitor and iterator visit this set correctly.) 
> 
> The RB-tree logic looks good to me.
> 
> Except for some small nits most of my feedback is about the API and the iteration.
> 
> I would like to avoid GrowableArrays in the implementation, but maybe I am missing a reason why they are preferable. If we could design the iterators to work more like standard C++ iterators (at least simplified but compatible versions) would make them more useful and ergonomic. There is also an opportunity to use such iterators as cursors and create a nice interface for using this tree in many different scenarios.
> 
> The second is if we should add more const version of the APIs to make it easier to work with the tree in const context (e.g. pass around the tree as a `const& Tree`). At least `const V* find(const K& key) const` seems useful to have a const `contains`.
> 
> Overall I think this is nice. But I would like some feedback on my comments w.r.t. the API before approving.

Thank you for reviewing @xmas92 and @tstuefe! I just pushed a bunch of changes based on your feedback, I'll reply with details on the specific comments.

Like Johan said, I'm working on an intrusive tree with cursors, and with that re-writing some of the internal logic to use those as well. That should also give more freedom of how and where nodes are allocated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2598712727

From coleenp at openjdk.org  Fri Jan 17 16:27:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 16:27:44 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
 <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
Message-ID: <9wf10scKR45T8HuK0DSglfRB8geI79INMllteJGJufM=.4c8e945e-8400-42ab-993d-2b69bb4d1d81@github.com>

On Fri, 17 Jan 2025 12:18:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the needed blank.

Thank you for reviewing Serguei, David and Matias.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23160#issuecomment-2598723117

From coleenp at openjdk.org  Fri Jan 17 16:27:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 16:27:45 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <I2SjOxy8Z_lIxUiHHivS7yc4xXIyXuagiMiMJaPtjL4=.1cca72fa-5d61-4baf-8e91-453f9350514d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
 <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
 <I2SjOxy8Z_lIxUiHHivS7yc4xXIyXuagiMiMJaPtjL4=.1cca72fa-5d61-4baf-8e91-453f9350514d@github.com>
Message-ID: <EmAb1l4mXm1ntE11cNZeMZ-AT4dDnAlbIsm2mCPadxI=.08fecc30-9216-4355-825c-557c1ece4d90@github.com>

On Fri, 17 Jan 2025 14:59:33 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added the needed blank.
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 137:
> 
>> 135: #define UINT64_FORMAT_0          "%016"       PRIx64
>> 136: 
>> 137: 
> 
> Extra newline added here, was that on purpose?

No it wasn't on purpose.  I can clean this up when sending out the PR for JDK-8347990.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23160#discussion_r1920437819

From coleenp at openjdk.org  Fri Jan 17 16:27:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 16:27:46 GMT
Subject: Integrated: 8347733: Replace SIZE_FORMAT in runtime code
In-Reply-To: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
Message-ID: <DkLD4hdmeV3Av9gG4Se2tlBDGXUay5cCYLGxyisNuLE=.8257c7ba-5534-4c04-bd5b-68737600b0c7@github.com>

On Thu, 16 Jan 2025 16:48:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: baca7daa
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/baca7daa32d553b647bdb33bb74a0eb84542deeb
Stats:     341 lines in 68 files changed: 3 ins; 6 del; 332 mod

8347733: Replace SIZE_FORMAT in runtime code

Reviewed-by: matsaave, sspitsyn, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/23160

From cnorrbin at openjdk.org  Fri Jan 17 16:32:44 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 17 Jan 2025 16:32:44 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <QHQk528UPyi4fOqS5AE0TvyUx-478-GETPZxcdgafdw=.ef4fa11b-e48c-4d7c-bc8e-b8fbd3bf0cc1@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
 <QHQk528UPyi4fOqS5AE0TvyUx-478-GETPZxcdgafdw=.ef4fa11b-e48c-4d7c-bc8e-b8fbd3bf0cc1@github.com>
Message-ID: <hWvZdhykCREtXTXUhDO_ZfC4anykgJ-RwC76oVCNoEw=.5d7b7edd-154d-42cd-af4b-c98f9cbc3574@github.com>

On Thu, 16 Jan 2025 12:02:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.hpp line 167:
>> 
>>> 165:   // Removes the given node from the tree.
>>> 166:   // Returns true if the node was successfully removed, false otherwise.
>>> 167:   bool remove(RBNode* node);
>> 
>> I find it confusing that removing a node can fail. It seems to be to handle `nullptr`. I'd rather restrict this and have `bool remove(const K& k)` check the return value of `find_node`.
>
> Wouldn't that require two traversals down the tree? Would a `enum RemovalResult { Removed, NotFound }` be preferred?

`remove(RBNode* node)` doesn't traverse the tree, so it is only ever one traversal. I moved the check to `remove(const K& k)` like you suggested, with an added assumption with a comment and assert that the node has to be valid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920447563

From gziemski at openjdk.org  Fri Jan 17 16:33:41 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 17 Jan 2025 16:33:41 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory
In-Reply-To: <GDRx6XhicQAtd5RKTvco86EIrz3hyCB1cjYvLcQ6rtA=.757b1b51-2786-4c3e-b974-ccaf3398b832@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <GDRx6XhicQAtd5RKTvco86EIrz3hyCB1cjYvLcQ6rtA=.757b1b51-2786-4c3e-b974-ccaf3398b832@github.com>
Message-ID: <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>

On Thu, 16 Jan 2025 22:41:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm really not sure what this is actually trying to benchmark - who will be collecting this data and analysing it and what will they do with their results?
> 
> That aside, generating the logs in a training run is okay, but the tool for processing those logs should reside elsewhere.
> 
> A few initial passing comments.

Thank you David for taking a look - very appreciated!

The processing tools are indeed somewhere else - `jdk/src/utils`

This benchmark records chronologically all the `malloc/realloc/free`  calls so teey ca be played back later, which allows developers to test their code before/after with respect to malloc calls to measure speed/memory usage.

I believe it should be a requirement to run this benchmark with your changes both to look for speed, but also memory usage, ebfore checkign in anything (though we can start with NTM related code) It was already used successfully to  optimize Treap.

The main idea behind it is that you need to record the pattern only once (using some fancy expensive use case), then iterate quickly over your fix and test against that pattern, without needing to actually run that use case.

> src/demo/share/jfc/J2Ddemo/java2d/Intro.java line 449:
> 
>> 447:                   System.exit(0);
>> 448:               }
>> 449:               Scene scene = director.get(index);
> 
> Leftover debugging code?

Yes, it is. I wanted a way to quit Java2Demo at the exact same point. I will revert it.

> src/hotspot/share/nmt/memLogRecorder.cpp line 43:
> 
>> 41: // then to actually run the benchmark:
>> 42: //
>> 43: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=43100 -XX:NMTBenchmarkRecordedLoops=10
> 
> ?? How does this run anything - you haven't passed an initial class to the Java invocation?

We check for the flags when we initialize NMT and run only when NMTBenchmarkRecordedPID is set.

> src/hotspot/share/nmt/memLogRecorder.hpp line 37:
> 
>> 35: #elif defined(WINDOWS)
>> 36:  // ???
>> 37: #endif
> 
> You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work.

Why do we need to use existing synchronization API here? IS it because we can deadlock by introducing a new lock?

I have run the existing code many times, no deadlocks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2598729741
PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1920446882
PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1920445805
PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1920448480

From cnorrbin at openjdk.org  Fri Jan 17 16:41:49 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 17 Jan 2025 16:41:49 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <00XoZuuL7TwIyfS86NNSV5SJaswDgHu7HC6rUZK44Ys=.c2ad7bf5-8405-49dd-a35d-1f940e96f950@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
 <00XoZuuL7TwIyfS86NNSV5SJaswDgHu7HC6rUZK44Ys=.c2ad7bf5-8405-49dd-a35d-1f940e96f950@github.com>
Message-ID: <k86WUsElT6Dvk_JTjzp8krDipOQCeqRf137KJbldKfc=.160e5508-042a-47dd-a6fb-b4e4e2fd5bd6@github.com>

On Thu, 16 Jan 2025 10:23:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.hpp line 183:
>> 
>>> 181:     _num_nodes = 0;
>>> 182:     _root = nullptr;
>>> 183:   }
>> 
>> I feel like this could have been done recursively and using the stack as a stack. Or at least skip the heap allocation with fixed sized array `RBNode* stack[128];`.
>
> Can probably do this for a lot of the other iteration done in this patch. I would think for most we would only need 64 entries. And even this could be written to just use at most a stack depth of 64.

I removed all the GAs in favour of the stack solution. In the future intrusive tree, these could be replaced with cursors instead.

>> src/hotspot/share/utilities/rbTree.hpp line 236:
>> 
>>> 234:     RBNode* end = closest_gt(addr);
>>> 235:     return Range(start, end);
>>> 236:   }
>> 
>> This seems somewhat out of place. The signature is miss-matched from all the other APIs both in terms of the name and type.
>> 
>> I am wrong in that end is always the next node after start? I think the closest_gt call is unnecessary and we can simply find the next node after start.
>
> Also note that this is not tested in the gtest.

I believe I got this from the treap, but it is not actively used anywhere. After a second look I feel like this belongs more on the caller's side. If someone would want this in the future, it would be trivial for them to implement instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920454567
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920458691

From cnorrbin at openjdk.org  Fri Jan 17 16:41:50 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 17 Jan 2025 16:41:50 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
Message-ID: <gt82dABuPazoc5SxeUOTykBsNhvHGcmjdDuzY-UpcBQ=.878602d5-c6a7-49da-91b0-10e8f5785c80@github.com>

On Thu, 16 Jan 2025 07:41:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified comment
>
> src/hotspot/share/utilities/rbTree.hpp line 273:
> 
>> 271:     NONCOPYABLE(IteratorImpl);
>> 272: 
>> 273:     IteratorImpl(const RBTree* tree) : _tree(tree) {
> 
> Given that our tree node have a parent pointer. I wonder why this is implemented with a GrowableArray rather than just keeping track of a node and walking the tree on next / previous. (Are we afraid that the pointer chasing back up the tree will be to costly? It seems very rare that you walk up the tree without also dereferencing the data)
> 
> This would have multiple benefits. We could make it O(1) space rather than O(log(n)).
> I think the biggest benefit is that it can be copy constructible and assignable making it much easier to work with including making it easily adaptable to work like a C++ iterator so that we can have begin() and end(), ranged for loops. Many of the APIs like find, enclosing range, visit etc could be implemented in terms of these, making it less cumbersome to design external algorithms which interacts with the tree rather than having to extend the functionality on the tree directly. It also makes iterators usable while inserting in the tree.
> 
> Johan talk about using a cursor to enable inserts and removals (to for example enable an intrusive node). I think we could also design an API which achieves the same with iterators. 
> ```c++
> auto it = tree.find_leq(key);
> if (cmp(key, *it) != 0) {
>   Node* node = get_intrusive_node(key);
>   tree.insert(it, node);
> } else {
>   Node* node = *it;
>   // Update node inplace or maybe replace it with a new intrusive node.
> }

After some thoughts, I've opted to remove the iterator code in its entirety. This would be replaced by cursors in the intrusive tree. The cursors have the same functionality and are more versatile, so it makes little sense to keep this in.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920456211

From cnorrbin at openjdk.org  Fri Jan 17 16:48:46 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 17 Jan 2025 16:48:46 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <_SIamvGXXQ7x9aqeB-QM25CEyB_v0W2PcrGxE6sO4FE=.4d947ee3-93fc-45d9-98ab-0bb92236ebf2@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <_SIamvGXXQ7x9aqeB-QM25CEyB_v0W2PcrGxE6sO4FE=.4d947ee3-93fc-45d9-98ab-0bb92236ebf2@github.com>
Message-ID: <P1H8kGtmQzTTzNNtbjWBfn3iq-r1RDhBRExAKhVsO4M=.7ea4e36c-b236-4483-8700-7f03edfb70d3@github.com>

On Thu, 16 Jan 2025 17:27:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified comment
>
> src/hotspot/share/utilities/rbTree.hpp line 55:
> 
>> 53:   class RBNode {
>> 54:     friend RBTree;
>> 55:     friend class RBTreeTest;
> 
> Is there a reason to be friends of RBTree? Even RBTreeTest?

RBTree edits the private fields of the nodes during insertion, and RBTreeTest is for more access to verification in the tests.

> src/hotspot/share/utilities/rbTree.hpp line 66:
> 
>> 64: 
>> 65:     enum Color : uint8_t { BLACK, RED };
>> 66:     Color _color;
> 
> Possibly for a future optimization. You could keep the color information as one bit overlayed in one of the pointers. That saves four to eight bytes per Node structure.
> 
> The Node pointers have to be aligned to `sizeof(void*)`, so we will always have an alignment shadow of at least two bits. If you encapsulate accessing the tagged pointer correctly, this should not be complicated.
> 
> (I believe the kernel RB tree does the same thing)

The LSB of the parent pointer now encodes the color information of the node

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920468182
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920467256

From cnorrbin at openjdk.org  Fri Jan 17 16:48:47 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 17 Jan 2025 16:48:47 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <ex--F1AE6c3hJE_x8RsbMvjCYv1wWV-5gHowNqnW4EY=.1228da9e-461e-4387-9720-f03957b5676a@github.com>
Message-ID: <7WXBPuZ892hs9yT1L0kzrEcB8a5cUYPc_GMftQfGas0=.c5aa3e69-0822-404e-8990-5edd9dd3a4e5@github.com>

On Thu, 16 Jan 2025 10:26:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified comment
>
> src/hotspot/share/utilities/rbTree.inline.hpp line 444:
> 
>> 442: template <typename K, typename V, typename COMPARATOR, typename ALLOCATOR>
>> 443: template <typename F>
>> 444: inline void RBTree<K, V, COMPARATOR, ALLOCATOR>::visit_range_in_order(const K& from, const K& to, F f) {
> 
> This could be written in terms of `closest_leq` and `closest_gt` and just walk the tree between these nodes, and only do `O(log(n))` `CMP` calls instead of `O(log(n) + log(k))` where `k` is the size of the node range.

I added a `BoundMode` to closest_(leq/gt) to allow for this. Now we use two `closest_gt(INCLUSIVE)` calls (becoming more like closest_geq)

Since the we want to go through the range [from, to}, these additions were needed to guarantee that the start node is found.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920464808

From rriggs at openjdk.org  Fri Jan 17 16:52:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Jan 2025 16:52:42 GMT
Subject: RFR: 8338428: Add logging if final VM flags while setting
 properties [v5]
In-Reply-To: <UW34yuClWQ6bI52wdtBnQskObcxFzjExYyiAq5VjWx0=.a7d52212-8f9b-4a96-a44f-3ffbd9946c24@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <UW34yuClWQ6bI52wdtBnQskObcxFzjExYyiAq5VjWx0=.a7d52212-8f9b-4a96-a44f-3ffbd9946c24@github.com>
Message-ID: <Vou3UZ9z428QJ5qTkbh_2orpUT8nDZY2aHK7yFtrUqk=.d2b8ea57-3bf0-4a71-8167-af6bbdb5901b@github.com>

On Fri, 17 Jan 2025 15:59:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights updated

This has a very broad impact on all tests and should have a second reviewer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2598774949

From cnorrbin at openjdk.org  Fri Jan 17 16:55:40 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 17 Jan 2025 16:55:40 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <_SIamvGXXQ7x9aqeB-QM25CEyB_v0W2PcrGxE6sO4FE=.4d947ee3-93fc-45d9-98ab-0bb92236ebf2@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <_SIamvGXXQ7x9aqeB-QM25CEyB_v0W2PcrGxE6sO4FE=.4d947ee3-93fc-45d9-98ab-0bb92236ebf2@github.com>
Message-ID: <gUPUg8pwoi5eUF-SJ9O1VxO1bdAf55y1qMp2xipJe0U=.d3518ce5-56d5-4da6-8589-f4b4ad28dd8f@github.com>

On Thu, 16 Jan 2025 17:15:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarified comment
>
> src/hotspot/share/utilities/rbTree.inline.hpp line 92:
> 
>> 90: #ifdef ASSERT
>> 91: template <typename K, typename V, typename COMPARATOR, typename ALLOCATOR>
>> 92: inline bool RBTree<K, V, COMPARATOR, ALLOCATOR>::RBNode::is_correct(
> 
> Some proposals for better/more useful/more expressive verification:
> 
> 1) I would use asserts inside the `Node::is_correct` function. I would not bother returning a bool but assert right away. This is used during tree verification only, and ideally, we want to crash hard and fast right there to have aa point to quickly debug. Arguably, I would rename the function to something like `verify()` (I'll use that name from now on)
> 
> 2) I would then also not use combined asserts but assert each condition separately.
> 
> 3) Please use size_t (or uintx, which I prefer but I know others don't) for the number of nodes/number of blacks in the arguments of this function. 
> 
> 4) I would not pass in limits to be checked by the node. Instead would let Node::verify() increase stats.
> 
> 5) I would also return longest/shortest path to any leaf, and black-nodes-til-leaf, like this (see below point(6)):
> 
> 
> void verify(
>   size_t& num_nodes,          // total nodes 
>   size_t& blacks_until_leaf,  // returns the number of black nodes from here to its leafs
>   size_t& longest_leaf_path,  // length of longest to-leaf path from here
>   size_t& shortest_leaf_path, // length of shortest to-leaf path from here
>   size_t current_depth
>   ) const;
> 
> you also can create a Stat struct and pass a reference to that if you dislike so many arguments.
> 
> 6) In Node::verify(), I would explicitly check the following red-black tree rules: 
>   - If Node is red, it shall have no red childs; (I see you do this already)
>   - If a Node has exactly one child, the child must be red (consequently, the node must be black)
>   - After calling `Node::verify() `for left and right child recursively, the blacks-until-leaf for right node and the one for the left node should be the same (which is also why we return just one value for `blacks_until_leaf`)
>   - the longest leaf path and the shortest leaf path must never be farther apart than factor 2 (so, `shortest_leaf_path <= longest_leaf_path <= shortest_leaf_path * 2 `). That asserts that we are balanced as far as RB trees go.
> 
> 7) In debug builds, please give the Node class a marker bit: `DEBUG_ONLY(bool _visited)`. Keep inside of the Tree class a `DEBUG_ONLY("bool _expected_visited")` bit. On Node creation/addition, set node->_visited to tree->_expected_vi...

Thank you for the many suggestions! I have reworked the verification based on this, including everything in the list.

We assert quicker and separately, values and limits are sent up instead of down to be validated, and I added a lot more checks. The visited bit and gtest was a very elegant solution (especially for the future intrusive nodes)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1920475051

From rriggs at openjdk.org  Fri Jan 17 17:30:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Jan 2025 17:30:38 GMT
Subject: RFR: 8338428: Add logging if final VM flags while setting
 properties [v5]
In-Reply-To: <UW34yuClWQ6bI52wdtBnQskObcxFzjExYyiAq5VjWx0=.a7d52212-8f9b-4a96-a44f-3ffbd9946c24@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <UW34yuClWQ6bI52wdtBnQskObcxFzjExYyiAq5VjWx0=.a7d52212-8f9b-4a96-a44f-3ffbd9946c24@github.com>
Message-ID: <KoSsRmNhQJGeUGfQJQkD5joKpus96tRsGZgcb7PLl0M=.717c5cf8-409c-413c-a8d3-bffe8f1f96d4@github.com>

On Fri, 17 Jan 2025 15:59:50 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights updated

This seems like overkill for a weak use case.

The resulting log file is in the scratch directory so it will not be retained for long.
In local builds, whoever is running the test could add the arguments.

Have there been any negative interactions with any of the test tiers due to the addition of extra logging flags?

test/hotspot/jtreg/TEST.ROOT line 51:

> 49: requires.extraPropDefns.javacOpts = --add-exports java.base/jdk.internal.foreign=ALL-UNNAMED
> 50: requires.extraPropDefns.vmOpts = \
> 51:     -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:-DisplayVMOutput -XX:LogFile=vmprops.flags.final.vm.log \

The -XX:+UnlockDiagnosticVMOptions is repeated, that shouldn't be necessary. (in either TEST.ROOT)

-------------

PR Review: https://git.openjdk.org/jdk/pull/23054#pullrequestreview-2559549496
PR Review Comment: https://git.openjdk.org/jdk/pull/23054#discussion_r1920505779

From galder at openjdk.org  Fri Jan 17 17:45:25 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 17 Jan 2025 17:45:25 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v10]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <LHH45x_f7eU_mgPT4zrDhoEmGuQQylrxFq04midfdeM=.9fa8c508-f9f0-468d-96f8-fb463ef043ec@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request incrementally with two additional commits since the last revision:

 - Renaming methods and variables and add docu on algorithms
 - Fix copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/abbaf875..f83d8863

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=08-09

  Stats: 38 lines in 3 files changed: 25 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From galder at openjdk.org  Fri Jan 17 17:45:25 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 17 Jan 2025 17:45:25 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <w6HsRaKvY1VAALkXyMUM5UjJelIDFZXv51Rbr8cv-Fg=.fbb0189d-4bba-47c1-b737-34488f829a33@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
 <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
 <w6HsRaKvY1VAALkXyMUM5UjJelIDFZXv51R
 br8cv-Fg=.fbb0189d-4bba-47c1-b737-34488f829a33@github.com>
Message-ID: <4NGZx_gqvc7xMcXCTef2c_ns-nMxznsB42NnlQJqX4Q=.8cdc00f9-c9a7-409a-b5c3-885d0677b952@github.com>

On Tue, 14 Jan 2025 08:54:34 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 I've fixed the test issue, it's ready to be reviewed
>
> @galderz I ran some testing on our side, feel free to ping me in 1-2 days for the results.

@eme64 I've addressed all the comments. I've not run the `VectorReduction2` for the reasons explained in the previous comment. Happy to add more details to `MinMaxVector` if you feel it's necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2598873155

From galder at openjdk.org  Fri Jan 17 17:53:24 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 17 Jan 2025 17:53:24 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v11]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/f83d8863..724a346a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From lmesnik at openjdk.org  Fri Jan 17 18:50:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Jan 2025 18:50:22 GMT
Subject: RFR: 8338428: Add logging if final VM flags while setting
 properties [v6]
In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
Message-ID: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>

> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
> 
> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
> 
> Update:
> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  updated flags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23054/files
  - new: https://git.openjdk.org/jdk/pull/23054/files/b28439c0..5f87d72f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=04-05

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23054/head:pull/23054

PR: https://git.openjdk.org/jdk/pull/23054

From lmesnik at openjdk.org  Fri Jan 17 19:17:36 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Jan 2025 19:17:36 GMT
Subject: RFR: 8338428: Add logging if final VM flags while setting
 properties [v5]
In-Reply-To: <KoSsRmNhQJGeUGfQJQkD5joKpus96tRsGZgcb7PLl0M=.717c5cf8-409c-413c-a8d3-bffe8f1f96d4@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <UW34yuClWQ6bI52wdtBnQskObcxFzjExYyiAq5VjWx0=.a7d52212-8f9b-4a96-a44f-3ffbd9946c24@github.com>
 <KoSsRmNhQJGeUGfQJQkD5joKpus96tRsGZgcb7PLl0M=.717c5cf8-409c-413c-a8d3-bffe8f1f96d4@github.com>
Message-ID: <KRqlJaLeJkPCD6VdYjpvK8jIqbrZBcLIoIafzb0EfnQ=.810012e5-7b6a-41a0-817e-f6ae5fc370e2@github.com>

On Fri, 17 Jan 2025 17:27:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This seems like overkill for a weak use case.
> 
> The resulting log file is in the scratch directory so it will not be retained for long. In local builds, whoever is running the test could add the arguments.

Thanks for your feedback.

Currently, typical size of artifacts for *passed* run take a tens of MB, so it is less then 0.5% increase.  The main consumer are .jtr files.

> 
> Have there been any negative interactions with any of the test tiers due to the addition of extra logging flags?

Which negative interactions  you suppose? This fix shouldn't interfere with executed tests completely. 
The only restriction is that we shouldn't use added 
XX:+LogVMOutput -XX:-DisplayVMOutput -XX:LogFile
in VMProps to calclulate their final values. 
However, they are not used in \requires` at all.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2599032748

From coleenp at openjdk.org  Fri Jan 17 20:55:08 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 20:55:08 GMT
Subject: RFR: 8347990: Remove SIZE_FORMAT macros and replace remaining uses
Message-ID: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>

Please review this patch that removes the SIZE_FORMAT macros and the remaining uses I missed in metaspace and the gtests.
Tested with tier1-4, and cross-compiled other platforms (except they fail for other reasons).

-------------

Commit messages:
 - 8347990: Remove SIZE_FORMAT macros and replace remaining uses

Changes: https://git.openjdk.org/jdk/pull/23180/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23180&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347990
  Stats: 86 lines in 25 files changed: 2 ins; 8 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/23180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23180/head:pull/23180

PR: https://git.openjdk.org/jdk/pull/23180

From kdnilsen at openjdk.org  Fri Jan 17 21:25:37 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Jan 2025 21:25:37 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

Thanks for figuring out how to make all of this work.  It represents a very significant improvement to the GenShen implementation.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp line 120:

> 118:   if (ShenandoahCardBarrier) {
> 119:     // Every thread always have a pointer to the _current_ _write_ version of the card table.
> 120:     // The JIT'ed code will use this address (+card entry offset) to marke card's as dirty.

typo here: "to mark cards as dirty"

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 228:

> 226: // This avoids the need to synchronize reads of the table by the GC workers doing
> 227: // remset scanning, on the one hand, with the dirtying of the table by mutators
> 228: // and by the GC workers doing remset scans, on the other.

Remove "and by the the GC workers doing remset scans" from this comment, so it reads:
"This avoids the need to synchronize reads of the table by the GC workers doing
remset scanning, on the one hand, with the dirtying of the table by mutators on the other.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 121:

> 119:   CardValue* bp = &(read_table)[0];
> 120:   CardValue* end_bp = &(read_table)[_card_table->last_valid_index()];
> 121: 

Looks like there may be an off-by-one error here, or a bad name for "last_valid_index()".  The following loop should continue while bp <= end_bp.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 632:

> 630:   CardValue* end_bp = &(new_ptr)[_card_table->last_valid_index()];
> 631: 
> 632:   while (start_bp < end_bp) {

Same issue here as mentioned above.  So our validation test doesn't catch our failure to overwrite last index value with clean value.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23170#pullrequestreview-2559986861
PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920769089
PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920775685
PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920778272
PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920779535

From duke at openjdk.org  Fri Jan 17 22:17:39 2025
From: duke at openjdk.org (duke)
Date: Fri, 17 Jan 2025 22:17:39 GMT
Subject: Withdrawn: 8341102: Add element type information to vector types
In-Reply-To: <l_Vrxk69jcMuC-lIAgn2w9UF196tQ9ZQ9nD8wGsOq1U=.b34d00b3-77af-46ae-a398-de8555a08778@github.com>
References: <l_Vrxk69jcMuC-lIAgn2w9UF196tQ9ZQ9nD8wGsOq1U=.b34d00b3-77af-46ae-a398-de8555a08778@github.com>
Message-ID: <u42O31wB3P_4ERhwD3RNhp6utbRSZB9jUScJxxzLbGA=.616a6f54-223c-423b-9275-91ca9fc6b478@github.com>

On Fri, 27 Sep 2024 18:06:36 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch adds the type information of each element in a `TypeVect`. This helps constant folding vectors as well as strength reduction of several complex operations such as `Rearrange`. Some notable points:
> 
> - I only implement `ConV` rule on x86, looking at other architectures it seems that I would not only need to implement the `ConV` implementations, but several other rules that match `ReplicateNode` of a constant.
> - I changed the implementation of an array constant in `constanttable`, I think working with `jbyte` is easier as it allows `memcpy` and at this point, we are close to the metal anyway.
> - Constant folding for a `VectorUnboxNode`, this is special because an element of a normal stable array is only constant if it is non-zero, so implementing constant folding on a load node seems less trivial.
> - Memory fences because `Vector::payload` is a final field and we should respect that.
> - Several places expect a `const Type*` when in reality it expects a `BasicType`, I refactor that so that the intent is clearer and there is less room for possible errors, this is needed because `byte`, `short` and `int` share the same kind of `const Type*`.
> 
> Please take a look and leave your reviews, thanks a lot.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21229

From rriggs at openjdk.org  Fri Jan 17 23:11:37 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Jan 2025 23:11:37 GMT
Subject: RFR: 8338428: Add logging if final VM flags while setting
 properties [v6]
In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
Message-ID: <P0s8GMefX9qdOFShzp9f6c0doRCzB4Y4_A7TsPMNa6Y=.4a65580f-02c0-492d-842c-a024841fda1f@github.com>

On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated flags

I don't see when these new flags come into use.  I built the PR and ran tests through make and did not see the flags (PrintFinalFlags) used when running the tests in the resulting jtr files. (I ran a subset of both jdk and hotspot/jtreg tests.)
Is there an examine test showing the flags working?  Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2599353392

From wkemper at openjdk.org  Fri Jan 17 23:22:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Jan 2025 23:22:44 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
Message-ID: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>

This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

-------------

Commit messages:
 - Fix whitespace
 - Do not let heap inspection/dump run GC on VM thread

Changes: https://git.openjdk.org/jdk/pull/23186/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23186&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345750
  Stats: 23 lines in 4 files changed: 15 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23186/head:pull/23186

PR: https://git.openjdk.org/jdk/pull/23186

From wkemper at openjdk.org  Fri Jan 17 23:37:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Jan 2025 23:37:37 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <Xo6j7jhnwGy6HmYI8cCz8ZwzrELhpkINTIxZi2dDB8E=.364b3488-d140-4183-876b-763fabe4498e@github.com>

On Fri, 17 Jan 2025 05:18:39 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp line 44:

> 42: #define BIND(label) bind(label); BLOCK_COMMENT(#label ":")
> 43: 
> 44: void CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,

Is it necessary to modify the `cardTableBarrierSetAssembler*` classes? I believe Shenandoah just uses the `shenandoahBarrierSetAssembler*` classes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1920873939

From kdnilsen at openjdk.org  Fri Jan 17 23:47:35 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Jan 2025 23:47:35 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <SnfMsHvY_xs0wrr4eOBK_gEhj-Pu5ZXxzhsvnU_8F0I=.bbc037cc-dd23-4f07-b985-a52c12717aca@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

Thanks for handling this.

-------------

Marked as reviewed by kdnilsen (Author).

PR Review: https://git.openjdk.org/jdk/pull/23186#pullrequestreview-2560162856

From lmesnik at openjdk.org  Sat Jan 18 00:44:36 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 18 Jan 2025 00:44:36 GMT
Subject: RFR: 8338428: Add logging if final VM flags while setting
 properties [v6]
In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
Message-ID: <cMauDJdg0447s5wn2o9vs5DiOKdac5xbs3RvVVIDEyc=.c84016cf-9aee-420f-9ab3-6a21abd4ba0e@github.com>

On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated flags

This flag is not used while tests are executed. It is used only when jtreg run VMProps, executed before all tests are run and you can find result in scratch directory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2599422465

From ysr at openjdk.org  Sat Jan 18 01:55:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 18 Jan 2025 01:55:35 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <lgntdS6_JTPWVv8wie7b9mt5QiWgv8X3_WT9fust2C4=.992dc3e8-c9e6-47b4-a251-185a5491cc01@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

LGTM ?

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23186#pullrequestreview-2560240341

From ysr at openjdk.org  Sat Jan 18 01:59:44 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 18 Jan 2025 01:59:44 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <_6iRDLUcANVcjyQJOF-M9G8boXICY8mSiQRkl8efsDA=.5dc4916f-0707-44b4-a384-af946bea8518@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

Please add a suitable testing section/description to the PR (perhaps inducing the conditions that might cause the original issue to manifest without the fix).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23186#issuecomment-2599466706

From rehn at openjdk.org  Sat Jan 18 08:48:33 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Sat, 18 Jan 2025 08:48:33 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads
In-Reply-To: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
Message-ID: <wVt4o3ntsqM_OkywQIA7N9GcMLfuam0VwdEhbpaT8CQ=.cf5cb0e5-65ca-41aa-b7ab-10e0fff9f16d@github.com>

On Fri, 17 Jan 2025 08:47:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider!
> 
> This patch the Zfa zli floating point immediate load.
> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
> 
> When using one of the 32 'popular' floats we can now materialze them without a load.
> E.g.
> `float f = f1 * 0.5 + f2 * 2.0;`
> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
> 
> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
> 
> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
> 
> Passes:
> ./test/jdk/java/lang/Math
> ./test/hotspot/jtreg/compiler/floatingpoint/
> ./test/jdk/java/util/Formatter/
> ./test/jdk/java/lang/Float/
> ./test/jdk/java/lang/Double/
> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> ./test/hotspot/jtreg/compiler/eliminateAutobox/
> ./test/hotspot/jtreg/vmTestbase/jit/
> 
> Running tier1
> 
> Thanks!

Thanks for havinga look @luhenry !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23171#issuecomment-2599633530

From rehn at openjdk.org  Sat Jan 18 08:48:36 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Sat, 18 Jan 2025 08:48:36 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads
In-Reply-To: <yI5YtZKwsMUtmnfkfieMLGxeGA0l0lBvVrP6_CeFvnI=.c6af5027-6154-43d8-b3ae-6b3241cc55fa@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <yI5YtZKwsMUtmnfkfieMLGxeGA0l0lBvVrP6_CeFvnI=.c6af5027-6154-43d8-b3ae-6b3241cc55fa@github.com>
Message-ID: <ZXlJqtmjHbMgonfdHwckVk6GQFSEMOrKOOFpK08WViE=.45d985f5-999c-4ea6-b77c-859b051bc7cf@github.com>

On Fri, 17 Jan 2025 15:54:00 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hi, please consider!
>> 
>> This patch the Zfa zli floating point immediate load.
>> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
>> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
>> 
>> When using one of the 32 'popular' floats we can now materialze them without a load.
>> E.g.
>> `float f = f1 * 0.5 + f2 * 2.0;`
>> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
>> 
>> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
>> 
>> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
>> 
>> Passes:
>> ./test/jdk/java/lang/Math
>> ./test/hotspot/jtreg/compiler/floatingpoint/
>> ./test/jdk/java/util/Formatter/
>> ./test/jdk/java/lang/Float/
>> ./test/jdk/java/lang/Double/
>> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> ./test/hotspot/jtreg/compiler/eliminateAutobox/
>> ./test/hotspot/jtreg/vmTestbase/jit/
>> 
>> Running tier1
>> 
>> Thanks!
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 335:
> 
>> 333: private:
>> 334: 
>> 335:   bool static zfa_zli_lookup_double(uint64_t value, int* Rs) {
> 
> Suggestion:
> 
>   static bool zfa_zli_lookup_double(uint64_t value, int* Rs) {

Yes, thanks!

> src/hotspot/cpu/riscv/assembler_riscv.hpp line 376:
> 
>> 374: 
>> 375: 
>> 376:   bool static zfa_zli_lookup_float(uint32_t value, int* Rs = nullptr) {
> 
> Suggestion:
> 
>   static bool zfa_zli_lookup_float(uint32_t value, int* Rs = nullptr) {

Yes, thanks!

> src/hotspot/cpu/riscv/assembler_riscv.hpp line 431:
> 
>> 429:     }
>> 430:     uint64_t d_bits = (uint64_t)julong_cast(d);
>> 431:     return zfa_zli_lookup_double(d_bits, Rs);
> 
> Would it better to inline the switch here directly? Is it used anywhere else?

I think that would make the code messier.
Now this method is very easy to read, check ZFA on and see if we have the bit pattern in lookup 'table', no?

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2634:
> 
>> 2632:   }
>> 2633:   int Rs = -1;
>> 2634:   can_zfa_zli_float(imm, &Rs);
> 
> should that be a `guarantee(can_zfa_zli_float(imm, &Rs));`?

Same, my bad. (guarantee in zli_s on that Rs is uimm5.)

As we already an guarantee, maybe assert(can_zfa..) ?

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2645:
> 
>> 2643:   }
>> 2644:   int Rs = -1;
>> 2645:   can_zfa_zli_double(imm, &Rs);
> 
> should that be a `guarantee(can_zfa_zli_double(imm, &Rs));`?

Sorry my bad for not adding a comment.
I'm using the guarantee in zli_d on that Rs is uimm5.

As we already an guarantee, maybe assert(can_zfa..) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1921023289
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1921023243
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1921023199
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1921022978
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1921022923

From rehn at openjdk.org  Sat Jan 18 09:14:17 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Sat, 18 Jan 2025 09:14:17 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
Message-ID: <jit0wEWz-BVEVN1-x2Rlf9vldHLzrXRqcYzqZcCkZuU=.970de563-05c7-41ca-836e-bb6c097a741a@github.com>

> Hi, please consider!
> 
> This patch the Zfa zli floating point immediate load.
> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
> 
> When using one of the 32 'popular' floats we can now materialze them without a load.
> E.g.
> `float f = f1 * 0.5 + f2 * 2.0;`
> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
> 
> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
> 
> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
> 
> Passes:
> ./test/jdk/java/lang/Math
> ./test/hotspot/jtreg/compiler/floatingpoint/
> ./test/jdk/java/util/Formatter/
> ./test/jdk/java/lang/Float/
> ./test/jdk/java/lang/Double/
> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> ./test/hotspot/jtreg/compiler/eliminateAutobox/
> ./test/hotspot/jtreg/vmTestbase/jit/
> 
> Running tier1
> 
> Thanks!

Robbin Ehn 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 three additional commits since the last revision:

 - Flip bool static decl
 - Merge branch 'master' into zfa
 - Baseline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23171/files
  - new: https://git.openjdk.org/jdk/pull/23171/files/60491784..6b3affe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23171&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23171&range=00-01

  Stats: 7237 lines in 454 files changed: 4499 ins; 666 del; 2072 mod
  Patch: https://git.openjdk.org/jdk/pull/23171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23171/head:pull/23171

PR: https://git.openjdk.org/jdk/pull/23171

From rehn at openjdk.org  Sat Jan 18 09:22:39 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Sat, 18 Jan 2025 09:22:39 GMT
Subject: RFR: 8347343: RISC-V: Unchecked zicntr csr reads [v3]
In-Reply-To: <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
 <Egvuj5paCRfeXnsQhk7ko6rwuvqMl87hCq5PlvSzhts=.0c56580a-c93c-47ab-9107-66aeae1f325c@github.com>
Message-ID: <uiU0dHKjPFw8FhbVoic2ORHQti45lyZcSZVzAxlgWVM=.7f7acd61-acb5-41d2-a642-3d5872bdbca4@github.com>

On Fri, 10 Jan 2025 11:59:10 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
>> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
>> 
>> If we need them before hwprobe we can add a flag for manually enabling them.
>> 
>> Sanity tested.
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove header

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23003#issuecomment-2599642674

From rehn at openjdk.org  Sat Jan 18 09:22:39 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Sat, 18 Jan 2025 09:22:39 GMT
Subject: Integrated: 8347343: RISC-V: Unchecked zicntr csr reads
In-Reply-To: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
References: <rnxEAI7SQbY9G1jTT7Mhs9CEq3OHys9A7BUd7VhldSs=.ac378e95-4611-4553-8879-13d1842e0602@github.com>
Message-ID: <hGZDWLykEaGqxIm6DOMcykEdjKlI8mCGUkS6MG4oNdE=.4f902ab2-7dcc-4c36-941c-2f81c039795b@github.com>

On Thu, 9 Jan 2025 12:55:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> The rdinstret/rdcycle/rdtime are really useful and would be great to add in e.g. JFR.
> But as of now they are not used and zicntr is not yet in hwprobe therefore this patch just make sure they can't be used.
> 
> If we need them before hwprobe we can add a flag for manually enabling them.
> 
> Sanity tested.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 1f0efc00
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f0efc00913e57690b57b7425bcc7dd6373e698f
Stats:     36 lines in 3 files changed: 9 ins; 18 del; 9 mod

8347343: RISC-V: Unchecked zicntr csr reads

Reviewed-by: fyang, mli

-------------

PR: https://git.openjdk.org/jdk/pull/23003

From rehn at openjdk.org  Sat Jan 18 09:42:14 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Sat, 18 Jan 2025 09:42:14 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v2]
In-Reply-To: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
Message-ID: <CuFHBmefbwsp4F0ylTsUCv8x8uaQBlGs5Ewsne8H0dY=.75dcc8aa-0868-4bc7-b817-86f81d7a4e44@github.com>

> Hey, please consider.
> 
> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
> We also had this same format repeated many times.
> 
> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
> fadd_s is thus described in code as:
> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
> Instead of:
> `INSN(fadd_s,   0b1010011, 0b0000000);`
> 
> It then moves zfh/zfhmin to a sepererate section and assert checks them.
> 
> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
> 
> Tested:
> jdk/java/lang/Math
> jdk/java/util/Formatter/
> jdk/java/lang/Float/
> jdk/java/lang/Double/
> hotspot/jtreg/compiler/floatingpoint/
> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> hotspot/jtreg/compiler/eliminateAutobox/
> hotspot/jtreg/vmTestbase/jit/
> 
> And tier1 twice, no FP issues. (Using UseZfh/min)
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into zfhmin
 - Baseline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23130/files
  - new: https://git.openjdk.org/jdk/pull/23130/files/586225e3..cafa8043

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=00-01

  Stats: 7322 lines in 455 files changed: 4529 ins; 684 del; 2109 mod
  Patch: https://git.openjdk.org/jdk/pull/23130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23130/head:pull/23130

PR: https://git.openjdk.org/jdk/pull/23130

From luhenry at openjdk.org  Sat Jan 18 13:07:35 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Sat, 18 Jan 2025 13:07:35 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <ZXlJqtmjHbMgonfdHwckVk6GQFSEMOrKOOFpK08WViE=.45d985f5-999c-4ea6-b77c-859b051bc7cf@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <yI5YtZKwsMUtmnfkfieMLGxeGA0l0lBvVrP6_CeFvnI=.c6af5027-6154-43d8-b3ae-6b3241cc55fa@github.com>
 <ZXlJqtmjHbMgonfdHwckVk6GQFSEMOrKOOFpK08WViE=.45d985f5-999c-4ea6-b77c-859b051bc7cf@github.com>
Message-ID: <lXQwN2CBE30F8CasExcQ0D70mMaFrtywS294YS5PE4w=.5a960085-f0e5-4f2e-93b9-160efbf3e2bf@github.com>

On Sat, 18 Jan 2025 08:42:29 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2645:
>> 
>>> 2643:   }
>>> 2644:   int Rs = -1;
>>> 2645:   can_zfa_zli_double(imm, &Rs);
>> 
>> should that be a `guarantee(can_zfa_zli_double(imm, &Rs));`?
>
> Sorry my bad for not adding a comment.
> I'm using the guarantee in zli_d on that Rs is uimm5.
> 
> As we already an guarantee, maybe assert(can_zfa..) ?

`assert(can_zfa..)` are not compiled in on release builds. You could then have `bool ret = can_zfa_zli_double(imm, &Rs); assert(ret);`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1921061045

From gziemski at openjdk.org  Sat Jan 18 14:20:46 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Sat, 18 Jan 2025 14:20:46 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v2]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <X9PS6WzWCxCZcjyCONHHs7u_QKkrtOM2Mm5GO6z4d64=.c38f6030-afd6-442e-a257-5dedcda58b7f@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`
> 
> This will run the target app, and log all the allocations in chronological order. This will produce a few files:
> - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations)
> - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state)
> - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing)
> 
> Now you can use those recording to actually benchmark your proposed changes, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10`
> 
> Which will produce yet another file:
> 
> - hs_nmt_pid23527_benchmark.log
> 
> that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output.
> 
> The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  skip if not using

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/a83389ab..a925e3d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=00-01

  Stats: 15 lines in 1 file changed: 6 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From gziemski at openjdk.org  Sat Jan 18 14:24:17 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Sat, 18 Jan 2025 14:24:17 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v3]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <nTQtoeJWhkhMIYcyXTRIvSTXY8jJuNASoDiYz0h-JR8=.3cd2c412-6bdc-4705-aeb7-1fe622d241a6@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`
> 
> This will run the target app, and log all the allocations in chronological order. This will produce a few files:
> - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations)
> - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state)
> - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing)
> 
> Now you can use those recording to actually benchmark your proposed changes, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10`
> 
> Which will produce yet another file:
> 
> - hs_nmt_pid23527_benchmark.log
> 
> that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output.
> 
> The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  move the optional tool into it's own issue/PR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/a925e3d5..cf8acc0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=01-02

  Stats: 2461 lines in 16 files changed: 0 ins; 2461 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From gziemski at openjdk.org  Sat Jan 18 14:29:17 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Sat, 18 Jan 2025 14:29:17 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v4]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <oV33xQsOuZsZ-WQs3jRPkSyeeYwy6n1nErj46X9-gQE=.4eec5970-d06d-4303-a8e2-6393e1217021@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar`
> 
> This will run the target app, and log all the allocations in chronological order. This will produce a few files:
> - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations)
> - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state)
> - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing)
> 
> Now you can use those recording to actually benchmark your proposed changes, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10`
> 
> Which will produce yet another file:
> 
> - hs_nmt_pid23527_benchmark.log
> 
> that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output.
> 
> The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change.

Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:

 - undo white change
 - undo debug change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/cf8acc0a..6c8c054f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From stuefe at openjdk.org  Sat Jan 18 15:57:35 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 18 Jan 2025 15:57:35 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v4]
In-Reply-To: <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <GDRx6XhicQAtd5RKTvco86EIrz3hyCB1cjYvLcQ6rtA=.757b1b51-2786-4c3e-b974-ccaf3398b832@github.com>
 <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>
Message-ID: <49spRgXYoY8YnH7s0q7-fbAQjqwMWCN3HEV6-th1QGw=.cceb034f-33bf-48e3-8d45-8b2c2d163bb5@github.com>

On Fri, 17 Jan 2025 16:27:40 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> I'm really not sure what this is actually trying to benchmark - who will be collecting this data and analysing it and what will they do with their results?

+1. Gerard, could provide a description of what this benchmark does, without having to analyze the patch? Neither text nor jbs text seem to explain that. How does this replay mechanism work, and why no simpler alternative?

Basic first question, what exactly is replayed? the recordings, or the recordings + allocations themselves? If the former, why not just measure NMT overhead by comparing NMT on with off?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2599767212

From stuefe at openjdk.org  Sat Jan 18 17:21:44 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 18 Jan 2025 17:21:44 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use
Message-ID: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>

If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 

Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.

We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.

This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.

Additionally, the patch provides a helpful output in the register/stack section, e.g:


RDI=0x0000000800000000 points into nKlass protection zone



Testing: 
- GHAs.
- I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
- I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)

-------------

Commit messages:
 - fix 32bit build
 - fix windows crash on os::protect
 - start

Changes: https://git.openjdk.org/jdk/pull/23190/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330174
  Stats: 166 lines in 8 files changed: 147 ins; 16 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23190/head:pull/23190

PR: https://git.openjdk.org/jdk/pull/23190

From stuefe at openjdk.org  Sat Jan 18 17:24:45 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 18 Jan 2025 17:24:45 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <DE_dlnYg5sHRSSeCoKcN5x0xOQFS2rFa87ojXIRy5Ec=.37fb5783-d1e0-4bc7-92ce-f4a11bc7a0b1@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

Okay, SAP gave green light too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2599796001

From duke at openjdk.org  Sat Jan 18 17:24:46 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Sat, 18 Jan 2025 17:24:46 GMT
Subject: Integrated: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <SJkQD6WvQnKbOH11ETqQCFzlLw6VDf5F2XjlFChXxe0=.726e2342-1a29-4fe6-bdb6-81c0b22ef441@github.com>

On Fri, 13 Dec 2024 21:29:53 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

This pull request has now been integrated.

Changeset: 3804082c
Author:    Robert Toyonaga <rtoyonag at redhat.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3804082cba56e6d26c500880cc5cbe6d4332d8f8
Stats:     124 lines in 19 files changed: 75 ins; 28 del; 21 mod

8346123: [REDO] NMT should not use ThreadCritical

Reviewed-by: dholmes, coleenp, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/22745

From rehn at openjdk.org  Sat Jan 18 20:02:36 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Sat, 18 Jan 2025 20:02:36 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <lXQwN2CBE30F8CasExcQ0D70mMaFrtywS294YS5PE4w=.5a960085-f0e5-4f2e-93b9-160efbf3e2bf@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <yI5YtZKwsMUtmnfkfieMLGxeGA0l0lBvVrP6_CeFvnI=.c6af5027-6154-43d8-b3ae-6b3241cc55fa@github.com>
 <ZXlJqtmjHbMgonfdHwckVk6GQFSEMOrKOOFpK08WViE=.45d985f5-999c-4ea6-b77c-859b051bc7cf@github.com>
 <lXQwN2CBE30F8CasExcQ0D70mMaFrtywS294YS5PE4w=.5a960085-f0e5-4f2e-93b9-160efbf3e2bf@github.com>
Message-ID: <K6jHkPjsVkKG7cE-1X_N7CJ-M8Mc3kmIHF3DKL12djs=.4fe1484f-f69c-48bf-9742-f58c6e872a02@github.com>

On Sat, 18 Jan 2025 13:04:34 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Sorry my bad for not adding a comment.
>> I'm using the guarantee in zli_d on that Rs is uimm5.
>> 
>> As we already an guarantee, maybe assert(can_zfa..) ?
>
> `assert(can_zfa..)` are not compiled in on release builds. You could then have `bool ret = can_zfa_zli_double(imm, &Rs); assert(ret);`

Yes, thanks. Easy to forget about :)

`assert(Rs != -1, "Invalid zli lookup");`

Is also an alternative. What you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1921142359

From stuefe at openjdk.org  Sun Jan 19 07:55:07 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 19 Jan 2025 07:55:07 GMT
Subject: RFR: 8348029: Make gtest death tests work with real crash signals
Message-ID: <3Ff8PvDpBAlZgaib29g7jHf6lBzKqIyhP766MH0GWjA=.498e7384-720e-426c-89db-18f874656256@github.com>

Small change adds a new macro to the gtest TEST macro zoo: `TEST_VM_CRASH_SIGNAL`. This one is a companion to `TEST_VM_FATAL_ERROR_MSG` and `TEST_VM_ASSERT_MSG` and allows to write gtest that test expected crashes to happen. I will need that for a regression test for https://bugs.openjdk.org/browse/JDK-8330174 , among other things.

You use it like this:


TEST_VM_CRASH_SIGNAL(Testtest, test, "SIGSEGV") {
  ... do something that you expect should result in a specific crash ...
}

Note that the string provided is platform dependent (signal names on Posix, SEH names on Windows).

-------------

Commit messages:
 - start

Changes: https://git.openjdk.org/jdk/pull/23191/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23191&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348029
  Stats: 26 lines in 2 files changed: 24 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23191.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23191/head:pull/23191

PR: https://git.openjdk.org/jdk/pull/23191

From stuefe at openjdk.org  Sun Jan 19 09:54:23 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 19 Jan 2025 09:54:23 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v2]
In-Reply-To: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
Message-ID: <OExJi0h-B9ljGqcI67G8a5HNIRWcysnq4uxhpl826aA=.cc973e9d-8356-4a4d-be78-95e7316931f6@github.com>

> If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 
> 
> Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.
> 
> We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.
> 
> This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.
> 
> Additionally, the patch provides a helpful output in the register/stack section, e.g:
> 
> 
> RDI=0x0000000800000000 points into nKlass protection zone
> 
> 
> 
> Testing: 
> - GHAs.
> - I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
> - I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  treat not-found protection zone buffer as fatal error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23190/files
  - new: https://git.openjdk.org/jdk/pull/23190/files/f18450bf..aa063d94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=00-01

  Stats: 9 lines in 3 files changed: 2 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23190/head:pull/23190

PR: https://git.openjdk.org/jdk/pull/23190

From dholmes at openjdk.org  Sun Jan 19 21:21:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 19 Jan 2025 21:21:10 GMT
Subject: RFR: 8348040: Bad use of ifdef with INCLUDE_xxx GC macros
Message-ID: <s10VNBkxJMbIFv9db-KibK-H-QX3XHqefTz9TQXAsts=.9c0d17dd-144b-44b3-adb1-8b55387aef1f@github.com>

The `INCLUDE_xxx` macros should be used with `#if` not `#ifdef` as the value is alway defined as either 1 or 0. So with `#ifdef` the guard is always true. This would lead to build problems in some cases if you built a configuration without the specified GC.

Testing:
 - tiers 1-3 sanity
 - tiers 4-5 builds

Thanks

-------------

Commit messages:
 - 8348040: Bad use of ifdef with INCLUDE_xxx GC macros

Changes: https://git.openjdk.org/jdk/pull/23193/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23193&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348040
  Stats: 8 lines in 3 files changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23193.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23193/head:pull/23193

PR: https://git.openjdk.org/jdk/pull/23193

From dholmes at openjdk.org  Mon Jan 20 01:41:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jan 2025 01:41:43 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory
In-Reply-To: <7qAPUArhTmcIGjvpoI_hxrE7Edm2FUruEK0UaVHQg3s=.82976906-0dc8-4e9a-964b-3983b8873715@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <Ip4bXpuQrTVWWtbGxNqfLqBVuh2lehZnNBSiiKO21OE=.aa2791be-9e8e-4874-94ed-dfd50777e538@github.com>
 <7qAPUArhTmcIGjvpoI_hxrE7Edm2FUruEK0UaVHQg3s=.82976906-0dc8-4e9a-964b-3983b8873715@github.com>
Message-ID: <WcZDKIjzVPk0GT8p9Cy5IjSqTxFS3oESWT6B1OFTftE=.9400fe1b-2de0-4265-85c4-e7c62296262b@github.com>

On Fri, 17 Jan 2025 16:18:53 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> They are NOT in hotspot, they are in src/utils

Apologies I misread as hotspot/src/utils (which doesn't exist of course)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2601152580

From dholmes at openjdk.org  Mon Jan 20 01:41:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jan 2025 01:41:44 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v4]
In-Reply-To: <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <GDRx6XhicQAtd5RKTvco86EIrz3hyCB1cjYvLcQ6rtA=.757b1b51-2786-4c3e-b974-ccaf3398b832@github.com>
 <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>
Message-ID: <hWlawB4rhrQOgbWBNEKWsqRusg7dnD5V_7IZi0QPRGM=.da650821-58fc-46af-b51e-4f4aabb8b50e@github.com>

On Fri, 17 Jan 2025 16:31:12 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/hotspot/share/nmt/memLogRecorder.hpp line 37:
>> 
>>> 35: #elif defined(WINDOWS)
>>> 36:  // ???
>>> 37: #endif
>> 
>> You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work.
>
> Why do we need to use existing synchronization API here? IS it because we can deadlock by introducing a new lock?
> 
> I have run the existing code many times, no deadlocks.

We have synchronization abstractions so that we don't litter shared code with platform specific code - and don't yu need a solution for Windows? We also need to ensure synchronization plays nicely with safepoints and yes to watch for potential deadlock issues. Testing can never prove the absence of deadlock.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1921693423

From dholmes at openjdk.org  Mon Jan 20 01:58:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jan 2025 01:58:43 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v4]
In-Reply-To: <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <GDRx6XhicQAtd5RKTvco86EIrz3hyCB1cjYvLcQ6rtA=.757b1b51-2786-4c3e-b974-ccaf3398b832@github.com>
 <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>
Message-ID: <g_StbwSW8Tk2FDJHx2Kp8FNUVmjF_-2qkskRAZI3Fm4=.aa8ea6fc-1696-4b63-8b72-99df7c052a38@github.com>

On Fri, 17 Jan 2025 16:29:00 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/hotspot/share/nmt/memLogRecorder.cpp line 43:
>> 
>>> 41: // then to actually run the benchmark:
>>> 42: //
>>> 43: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=43100 -XX:NMTBenchmarkRecordedLoops=10
>> 
>> ?? How does this run anything - you haven't passed an initial class to the Java invocation?
>
> We check for the flags when we initialize NMT and run only when NMTBenchmarkRecordedPID is set.

We do have some terminal flags like `-version` and `-Xshare:dump`, but generally the VM does not have magic flags that behave that way. I still don't have a clear picture of the different phases involved with this work. We have a recording phase. Then we have the benchmarking phase that does something (I can't figure out what) with the recording. Then we have the Java tool which does ... what?

In any case I have concerns about how the "benchmarking" is initiated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1921701378

From dholmes at openjdk.org  Mon Jan 20 02:25:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jan 2025 02:25:37 GMT
Subject: RFR: 8347990: Remove SIZE_FORMAT macros and replace remaining uses
In-Reply-To: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>
References: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>
Message-ID: <kfxljrF4uOc5NBGs1-ftYphN7Mu1oxbtnkgRl8cd1oU=.929c7f49-bc1a-46df-b3bc-33e67b907dda@github.com>

On Fri, 17 Jan 2025 18:46:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this patch that removes the SIZE_FORMAT macros and the remaining uses I missed in metaspace and the gtests.
> Tested with tier1-4, and cross-compiled other platforms (except they fail for other reasons).

LGTM!

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23180#pullrequestreview-2561199171

From fyang at openjdk.org  Mon Jan 20 03:14:36 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 20 Jan 2025 03:14:36 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v2]
In-Reply-To: <CuFHBmefbwsp4F0ylTsUCv8x8uaQBlGs5Ewsne8H0dY=.75dcc8aa-0868-4bc7-b817-86f81d7a4e44@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <CuFHBmefbwsp4F0ylTsUCv8x8uaQBlGs5Ewsne8H0dY=.75dcc8aa-0868-4bc7-b817-86f81d7a4e44@github.com>
Message-ID: <4NKz0Nx4yEqPtoMRfW2b5Kvr2VRMayNCTIdc5qXDr64=.c69bbffa-577d-4430-a7a7-954a1875ac54@github.com>

On Sat, 18 Jan 2025 09:42:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hey, please consider.
>> 
>> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
>> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
>> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
>> We also had this same format repeated many times.
>> 
>> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
>> fadd_s is thus described in code as:
>> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
>> Instead of:
>> `INSN(fadd_s,   0b1010011, 0b0000000);`
>> 
>> It then moves zfh/zfhmin to a sepererate section and assert checks them.
>> 
>> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
>> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
>> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
>> 
>> Tested:
>> jdk/java/lang/Math
>> jdk/java/util/Formatter/
>> jdk/java/lang/Float/
>> jdk/java/lang/Double/
>> hotspot/jtreg/compiler/floatingpoint/
>> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> hotspot/jtreg/compiler/eliminateAutobox/
>> hotspot/jtreg/vmTestbase/jit/
>> 
>> And tier1 twice, no FP issues. (Using UseZfh/min)
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into zfhmin
>  - Baseline

Thanks for making this cleanup! I only have one minor comment.

src/hotspot/cpu/riscv/assembler_riscv.hpp line 977:

> 975:  public:
> 976: 
> 977:   enum FClassBit {

Since we have composed members like `zero`, `subnorm` etc. , maybe we should rename this to `FClassBits`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23130#pullrequestreview-2561233443
PR Review Comment: https://git.openjdk.org/jdk/pull/23130#discussion_r1921735141

From dholmes at openjdk.org  Mon Jan 20 04:28:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jan 2025 04:28:36 GMT
Subject: RFR: 8338428: Add logging if final VM flags while setting
 properties [v6]
In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
Message-ID: <zg9CYyMqwaoWyAFdJrKAUMoAqz-IXP9opZ2zqCEstrw=.3d0576f6-9193-4d1d-945b-3b687e5712c2@github.com>

On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated flags

Nit: the JBS title should be "Add logging of final VM flags ..." not 'if'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2601301926

From rehn at openjdk.org  Mon Jan 20 07:35:11 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 20 Jan 2025 07:35:11 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v3]
In-Reply-To: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
Message-ID: <03CcZJ0q9C9SXLJ0Ie0UatsB-Br1VxG2chTwNDPRFWs=.cbfe2100-3ccd-42e2-a45f-5bc33f07c053@github.com>

> Hey, please consider.
> 
> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
> We also had this same format repeated many times.
> 
> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
> fadd_s is thus described in code as:
> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
> Instead of:
> `INSN(fadd_s,   0b1010011, 0b0000000);`
> 
> It then moves zfh/zfhmin to a sepererate section and assert checks them.
> 
> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
> 
> Tested:
> jdk/java/lang/Math
> jdk/java/util/Formatter/
> jdk/java/lang/Float/
> jdk/java/lang/Double/
> hotspot/jtreg/compiler/floatingpoint/
> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> hotspot/jtreg/compiler/eliminateAutobox/
> hotspot/jtreg/vmTestbase/jit/
> 
> And tier1 twice, no FP issues. (Using UseZfh/min)
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  FClassBits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23130/files
  - new: https://git.openjdk.org/jdk/pull/23130/files/cafa8043..2eb4fa21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=01-02

  Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23130/head:pull/23130

PR: https://git.openjdk.org/jdk/pull/23130

From rehn at openjdk.org  Mon Jan 20 07:35:12 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 20 Jan 2025 07:35:12 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v2]
In-Reply-To: <4NKz0Nx4yEqPtoMRfW2b5Kvr2VRMayNCTIdc5qXDr64=.c69bbffa-577d-4430-a7a7-954a1875ac54@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <CuFHBmefbwsp4F0ylTsUCv8x8uaQBlGs5Ewsne8H0dY=.75dcc8aa-0868-4bc7-b817-86f81d7a4e44@github.com>
 <4NKz0Nx4yEqPtoMRfW2b5Kvr2VRMayNCTIdc5qXDr64=.c69bbffa-577d-4430-a7a7-954a1875ac54@github.com>
Message-ID: <gZe8WlmvP_jlinTt1xGY4TXiVDKLF-YOXVeOp9LD_v4=.64db6558-a378-45a8-a8b8-d7764d67643f@github.com>

On Mon, 20 Jan 2025 03:11:21 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Thanks for making this cleanup! I only have one minor comment.

Thanks!

> src/hotspot/cpu/riscv/assembler_riscv.hpp line 977:
> 
>> 975:  public:
>> 976: 
>> 977:   enum FClassBit {
> 
> Since we have composed members like `zero`, `subnorm` etc. , maybe we should rename this to `FClassBits`?

Yes!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23130#issuecomment-2601622137
PR Review Comment: https://git.openjdk.org/jdk/pull/23130#discussion_r1921914789

From aboldtch at openjdk.org  Mon Jan 20 08:02:25 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 20 Jan 2025 08:02:25 GMT
Subject: RFR: 8347564: ZGC: Crash in
 DependencyContext::clean_unloading_dependents
Message-ID: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>

The proposed change here is the following:
 1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object
 2. Remove the Context object and its corresponding cleaner

(1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose.

First what goes wrong without this patch.

Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. 

For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. 

The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection.

If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection  would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. 

For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce a bogus oop because the field will not have been tracked (and remapped) correctly. This will cause the crash.

The solution in this patch is to remove the Context object and store the `vmdependencies` list head directly in the CallSite object. This avoids any cross generation pointers. 

An alternative would have been to keep the cleaner and change the GC code to only look at CallSite object which are reachable. However this would require a per-GC adaption and would be a larger change. (Even if it is only really ZGC which would need to do anything, maybe that generational Shenandoah is also affected, but not something I have looked into)

I've tried to dig and find why a cleaner was used in the first place as it seems like the GC has cleaned these / removed unloading nmethods for a while. Maybe someone else have more insight.

The lifetime of the native memory is now solely tied to the lifetime of the nmthod it tracks a dependency for. This means that it is important that after `add_dependent_nmethod` it will eventually be seen by and can be unlinked by the GC. As far as I can tell this seem to be the case, `add_dependent_nmethod` is called after a nmethod has been created in the code cache. 

Tested:
 * Github Actions
 * Oracle supported platforms tier1 through 8

-------------

Commit messages:
 - 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents

Changes: https://git.openjdk.org/jdk/pull/23194/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23194&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347564
  Stats: 168 lines in 13 files changed: 8 ins; 143 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/23194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23194/head:pull/23194

PR: https://git.openjdk.org/jdk/pull/23194

From epeter at openjdk.org  Mon Jan 20 08:03:44 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 20 Jan 2025 08:03:44 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <4NGZx_gqvc7xMcXCTef2c_ns-nMxznsB42NnlQJqX4Q=.8cdc00f9-c9a7-409a-b5c3-885d0677b952@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
 <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
 <w6HsRaKvY1VAALkXyMUM5UjJelIDFZXv51R
 br8cv-Fg=.fbb0189d-4bba-47c1-b737-34488f829a33@github.com>
 <4NGZx_gqvc7xMcXCTef2c_ns-nMxznsB42NnlQJqX4Q=.8cdc00f9-c9a7-409a-b5c3-885d0677b952@github.com>
Message-ID: <AAn1vaqU5jjKtskChE7Mvnq8Kmg8IhZ54HdPYMYs2Dc=.33d24865-8120-4e29-8760-a263c437c830@github.com>

On Fri, 17 Jan 2025 17:41:47 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> @galderz I ran some testing on our side, feel free to ping me in 1-2 days for the results.
>
> @eme64 I've addressed all the comments. I've not run the `VectorReduction2` for the reasons explained in the previous comment. Happy to add more details to `MinMaxVector` if you feel it's necessary.

@galderz Ah, right. I understand about the branch probability.

Hmm, maybe we should eventually change the `VectorReduction2` benchmark, or just remove the `min/max` benchmark there completely, as it depends on the random input values.

Ah, though we have a fixed `seed`, so rerunning the benchmark would at least have consistent branching characteristics. So then it could make sense to run the benchmark, we just don't know the probability. I mean I ran it before for the `in/float/double min/max`, and all of them see a solid speedup. So I would expect the same for `long`, it would be nice to at least see the numbers.

You could extend your benchmark to `float / double` as well, to make it complete. But that could also be a follow-up RFE.

>I would expect a similar thing to happen when it comes to asimd envs with max vector size >= 32 (e.g. Graviton 3). Those will see vectorization occur and improvements kick in at 100%. Other systems (e.g. Graviton 4) will see a regression at 100%. This means that your work in https://github.com/openjdk/jdk/pull/20098#discussion_r1901576209 to avoid the max vector size limitation might become more important once my PR here goes in.

So are you saying there are machines where we are now getting some regressions with your patch (2-element cases)? It would be nice to see the numbers summarized here. I'm losing the overview a little over the 50+ messages now ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2601678386

From sroy at openjdk.org  Mon Jan 20 08:09:44 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 20 Jan 2025 08:09:44 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
Message-ID: <kRKTzDt_NUY6wxYnIMpYVzGXBQs4sdUaT8Wp6JP1pD4=.f3d73f22-a6ab-424f-9961-7feedb15c5cf@github.com>

On Thu, 9 Jan 2025 09:07:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

> I guess that this PR does not even compile.



> This reference is even better, and comes with complete source code as well as the proofs:
> 
> https://web.archive.org/web/20110609115824/https://software.intel.com/file/24918

Thank you.Yes the reduction algorithm is derived from here. 
However there is one more paper referred for the Karatsuba Multiplication. 
https://link.springer.com/content/pdf/10.1007/978-3-319-16715-2_9.pdf

I think even that can be mentioned in the comments then ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2601690731

From stefank at openjdk.org  Mon Jan 20 09:27:38 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 Jan 2025 09:27:38 GMT
Subject: RFR: 8348040: Bad use of ifdef with INCLUDE_xxx GC macros
In-Reply-To: <s10VNBkxJMbIFv9db-KibK-H-QX3XHqefTz9TQXAsts=.9c0d17dd-144b-44b3-adb1-8b55387aef1f@github.com>
References: <s10VNBkxJMbIFv9db-KibK-H-QX3XHqefTz9TQXAsts=.9c0d17dd-144b-44b3-adb1-8b55387aef1f@github.com>
Message-ID: <sRDPqSIkeFlacBkMUuruiCikKa0jZ3Jv4Uu6KBXzLJY=.157a3d07-0751-4537-9b77-d8fd4ba1332a@github.com>

On Sun, 19 Jan 2025 21:15:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The `INCLUDE_xxx` macros should be used with `#if` not `#ifdef` as the value is alway defined as either 1 or 0. So with `#ifdef` the guard is always true. This would lead to build problems in some cases if you built a configuration without the specified GC.
> 
> Testing:
>  - tiers 1-3 sanity
>  - tiers 4-5 builds
> 
> Thanks

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23193#pullrequestreview-2561806330

From shade at openjdk.org  Mon Jan 20 09:27:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 20 Jan 2025 09:27:38 GMT
Subject: RFR: 8348040: Bad use of ifdef with INCLUDE_xxx GC macros
In-Reply-To: <s10VNBkxJMbIFv9db-KibK-H-QX3XHqefTz9TQXAsts=.9c0d17dd-144b-44b3-adb1-8b55387aef1f@github.com>
References: <s10VNBkxJMbIFv9db-KibK-H-QX3XHqefTz9TQXAsts=.9c0d17dd-144b-44b3-adb1-8b55387aef1f@github.com>
Message-ID: <EyQ-YIRZvwLN_VPCcbTOBHgyWkpU_Rnmcyh5lKfEwl4=.15f3616f-f395-4137-a8ce-7820eeb29816@github.com>

On Sun, 19 Jan 2025 21:15:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The `INCLUDE_xxx` macros should be used with `#if` not `#ifdef` as the value is alway defined as either 1 or 0. So with `#ifdef` the guard is always true. This would lead to build problems in some cases if you built a configuration without the specified GC.
> 
> Testing:
>  - tiers 1-3 sanity
>  - tiers 4-5 builds
> 
> Thanks

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23193#pullrequestreview-2561810287

From eosterlund at openjdk.org  Mon Jan 20 10:01:44 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 20 Jan 2025 10:01:44 GMT
Subject: RFR: 8347564: ZGC: Crash in
 DependencyContext::clean_unloading_dependents
In-Reply-To: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
References: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
Message-ID: <rKNCt7qdBPl1mnjRCHiETd8u_osR4NLPBoPweu0xckc=.af93f77a-f710-4e92-b9ff-6756f7739218@github.com>

On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The proposed change here is the following:
>  1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object
>  2. Remove the Context object and its corresponding cleaner
> 
> (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose.
> 
> First what goes wrong without this patch.
> 
> Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. 
> 
> For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. 
> 
> The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection.
> 
> If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection  would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. 
> 
> For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ...

This looks great. Solving the problem by removing pointless code is great. Now it looks much... cleaner.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23194#pullrequestreview-2561911632

From stefank at openjdk.org  Mon Jan 20 10:06:16 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 Jan 2025 10:06:16 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v4]
In-Reply-To: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
Message-ID: <ajywiQd_SdD7aHHe_Zqo8umf8wmCnSycPnjnaS1OO5o=.097ed873-db3f-4d22-9cfb-bec72449bea9@github.com>

> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
> 
> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
> 
> The make files changes to support this are:
> 1) Remove share/precompiled/ from the list of include directories,
> 2) Compiler-specific changes to support this:
> 
> *Windows cl*:
> * Add the share/precompiled/ include directory when generating the PCH file.
> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
> 
> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
> 
> *gcc*:
> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
> 
> *clang*:
> * No changes needed, the -include-pch line is all that we need.
> 
> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
> 
> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
> 
> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
> 
> Tested by letting GHA build and running tier1-2 in our CI pipeline.

Stefan Karlsson 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:

 - Copyright
 - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Remove precompiled.hpp include from source files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23146/files
  - new: https://git.openjdk.org/jdk/pull/23146/files/9a73f271..512941c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=02-03

  Stats: 7375 lines in 1664 files changed: 3969 ins; 378 del; 3028 mod
  Patch: https://git.openjdk.org/jdk/pull/23146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23146/head:pull/23146

PR: https://git.openjdk.org/jdk/pull/23146

From mdoerr at openjdk.org  Mon Jan 20 10:28:40 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 20 Jan 2025 10:28:40 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
Message-ID: <F3AYbcwQfsPUBmtISrCY4VcQm33wwlYDthjCmpJ8OPg=.4b229de2-4a74-4624-a639-7b2b2657dcaf@github.com>

On Wed, 15 Jan 2025 14:00:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

You can ignore the gc/shenandoah/TestStringInternCleanup_default test failure. We were able to reproduce it without your PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2602016332

From aph at openjdk.org  Mon Jan 20 10:36:43 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 20 Jan 2025 10:36:43 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v6]
In-Reply-To: <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <ivX6ECkzHRAq1LLTUpoWowZKdCgS0I8unh_s9SThMA4=.fbb0b591-0aa8-4f56-91bd-15b401112819@github.com>
Message-ID: <-uO62TuHklNIcCYMFTCiE5iSlP83pncNv5jm264Wf1M=.da317586-4dbf-4943-97e3-c628ba35e6f5@github.com>

On Thu, 9 Jan 2025 09:07:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

On 1/20/25 08:09, Suchismith Roy wrote:

>> This reference is even better, and comes with complete source code as well as the proofs:
>>
>> https://web.archive.org/web/20110609115824/https://software.intel.com/file/24918
> 
> Thank you.Yes the reduction algorithm is derived from here.
> However there is one more paper referred for the Karatsuba Multiplication.
> https://link.springer.com/content/pdf/10.1007/978-3-319-16715-2_9.pdf
> 
> I think even that can be mentioned in the comments then ?
Sure, but it's not a great idea to reference a non-open access paper in free
software. There's a copy of the Intel paper that does explain the use of
Karatsuba on Page 12 here:

https://github.com/intel/intel-ipsec-mb/wiki/doc/optimized-gcm-implementation.pdf

There's a comment in
src/hotspot/cpu/aarch64/macroAssembler_aarch64_aes.cpp:290, like this:


  // Karatsuba multiplication performs a 128*128 -> 256-bit
  // multiplication in three 128-bit multiplications and a few
  // additions.
  //
  // (C1:C0) = A1*B1, (D1:D0) = A0*B0, (E1:E0) = (A0+A1)(B0+B1)
  // (A1:A0)(B1:B0) = C1:(C0+C1+D1+E1):(D1+C0+D0+E0):D0
  //
  // Inputs:
  //
  // A0 in a.d[0]     (subkey)
  // A1 in a.d[1]
  // (A1+A0) in a1_xor_a0.d[0]
  //
  // B0 in b.d[0]     (state)
  // B1 in b.d[1]


In your case, the register names (a and b) would be different, of course.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2602041665

From amitkumar at openjdk.org  Mon Jan 20 11:30:08 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 20 Jan 2025 11:30:08 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
Message-ID: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>

Fixes `foreign/normalize/TestNormalize.java` failure on s390x.

-------------

Commit messages:
 - updates sender_sp for upcall_stub frame

Changes: https://git.openjdk.org/jdk/pull/23197/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23197&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345285
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23197/head:pull/23197

PR: https://git.openjdk.org/jdk/pull/23197

From jsjolen at openjdk.org  Mon Jan 20 11:49:39 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 20 Jan 2025 11:49:39 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v4]
In-Reply-To: <oV33xQsOuZsZ-WQs3jRPkSyeeYwy6n1nErj46X9-gQE=.4eec5970-d06d-4303-a8e2-6393e1217021@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <oV33xQsOuZsZ-WQs3jRPkSyeeYwy6n1nErj46X9-gQE=.4eec5970-d06d-4303-a8e2-6393e1217021@github.com>
Message-ID: <WLAbSs2sgeEJrPLVWBdqJiJRcvOgtjKNod14zLg7s24=.76f5aef2-eea0-42a3-b8fa-5d8bcc41913c@github.com>

On Sat, 18 Jan 2025 14:29:17 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
>> 
>> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
>> 
>> VM interacts with these through these APIs:
>> 
>>   ```
>>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>>   NMT_LogRecorder::logThreadName(name);
>>   NMT_LogRecorder::finish();
>> 
>> 
>> For controlling their liveness and through their "log" APIs for the actual logging.
>> 
>> For memory logger those are:
>> 
>> 
>>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
>> 
>> 
>> and for virtual memory logger, those are:
>> 
>> 
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
>> 
>> 
>> That's the entirety of the surface area of the new code.
>> 
>> The actual implementation extends one existing VM API:
>> 
>> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
>> `
>> 
>> and adds a few APIs to permit_forbidden_function.hpp:
>> 
>> 
>>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
>> 
>>  #if defined(LINUX)
>>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>>  #elif defined(WINDOWS)
>>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>>  #elif defined(__APPLE__)
>>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>>  #endif
>> 
>> 
>> Those are need if we want to calculate the memory overhead
>> 
>> To u...
>
> Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo white change
>  - undo debug change

I haven't read the code yet, but this is something that we have used internally for testing different optimizations in NMT.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2602206211

From aph at openjdk.org  Mon Jan 20 12:10:37 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 20 Jan 2025 12:10:37 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
In-Reply-To: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
Message-ID: <qbJQjaZFKO8EDaJ-oWm8svT0WmZbyBBaDsU9I_ml4IM=.fe48d42a-fdc1-40f5-ab94-a9f30d2e266b@github.com>

On Mon, 20 Jan 2025 11:24:39 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Fixes `foreign/normalize/TestNormalize.java` failure on s390x.

I'm not sure why this change is correct. Hopefully @mcimadamore has some idea why we want to skip an upcall frame.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23197#issuecomment-2602253174

From stuefe at openjdk.org  Mon Jan 20 13:39:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 20 Jan 2025 13:39:40 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v4]
In-Reply-To: <WLAbSs2sgeEJrPLVWBdqJiJRcvOgtjKNod14zLg7s24=.76f5aef2-eea0-42a3-b8fa-5d8bcc41913c@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <oV33xQsOuZsZ-WQs3jRPkSyeeYwy6n1nErj46X9-gQE=.4eec5970-d06d-4303-a8e2-6393e1217021@github.com>
 <WLAbSs2sgeEJrPLVWBdqJiJRcvOgtjKNod14zLg7s24=.76f5aef2-eea0-42a3-b8fa-5d8bcc41913c@github.com>
Message-ID: <qDQP65MuNM-W2yYqyOPCJmxgx7yKMa9evcAwm5bOpSY=.1987e6b4-440f-4534-927b-2971c108a1b6@github.com>

On Mon, 20 Jan 2025 11:45:14 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> I haven't read the code yet, but this is something that we have used internally for testing different optimizations in NMT.

I had a quick read through the code to get the gist of it. Some sort of design document would be rather helpful here.

I am not really sure what that benchmark does. We can "replay" operations, which for malloc means we re-execute the mallocs, for maps it means we just execute the NMT bookkeeping operation without the associated sys calls and without the locking needed to bracket the latter with the former. What do we measure here?

I have the feeling the purpose is to somehow extract the time cost for NMT bookkeeping? To separate it from the cost associated with synchronization and associated with OS-side allocation calls (but then, why do we execute mallocs on replay?) ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2602450326

From mdoerr at openjdk.org  Mon Jan 20 13:47:35 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 20 Jan 2025 13:47:35 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
In-Reply-To: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
Message-ID: <bcyHyG1sE9nQLoizMbj-s4UuRy3DcVecUAoI4X68Oz4=.14aa0d1d-e0a6-41ff-9167-77127d07970f@github.com>

On Mon, 20 Jan 2025 11:24:39 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Fixes `foreign/normalize/TestNormalize.java` failure on s390x.

I was wondering why the entry frame uses the "extended sp" while the upcall stub should use the "unextended sp".
This seems to be due to the fact that the normal entries use `from_interpreted_entry()`:
https://github.com/openjdk/jdk/blob/9346984725ed09e9917e825094b34c3a033af23e/src/hotspot/share/runtime/javaCalls.cpp#L397
The upcall stubs load the call target address from `Method::from_compiled_offset()` and use c2i if needed.
So, it looks correct to me. But the PR should get a 2nd review.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23197#pullrequestreview-2562434223

From rehn at openjdk.org  Mon Jan 20 13:48:52 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 20 Jan 2025 13:48:52 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v3]
In-Reply-To: <1t4xQC7fgk7qfYH_3WTaTdxcuX2Yq8KXXpUJCJXfDxw=.b373802a-0f75-4401-a040-787091b51e27@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <03CcZJ0q9C9SXLJ0Ie0UatsB-Br1VxG2chTwNDPRFWs=.cbfe2100-3ccd-42e2-a45f-5bc33f07c053@github.com>
 <1t4xQC7fgk7qfYH_3WTaTdxcuX2Yq8KXXpUJCJXfDxw=.b373802a-0f75-4401-a040-787091b51e27@github.com>
Message-ID: <ICXvT_1y5UcovyhDjj9qcuA2ruskvNE-0YmA1wXZpEU=.892ce90d-1e65-4191-b4e4-095a1efd8401@github.com>

On Mon, 20 Jan 2025 11:53:15 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   FClassBits
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 927:
> 
>> 925:   template <FmtPrecision Fmt, uint8_t funct5>
>> 926:   void fp_base(FloatRegister Rd, FloatRegister Rs1, FloatRegister Rs2, RoundingMode rm) {
>> 927:     fp_base<Fmt, funct5>(Rd->raw_encoding(), Rs1->raw_encoding(), Rs2->raw_encoding(), (RoundingMode)rm);
> 
> Nit: Is this explicit type conversion necessary here? `(RoundingMode)rm`

No, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23130#discussion_r1922429056

From rehn at openjdk.org  Mon Jan 20 13:48:51 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 20 Jan 2025 13:48:51 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v4]
In-Reply-To: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
Message-ID: <c9BLP5IMoFeJSsxZOI3uhcICsWdkcepJKCExjJBz9SQ=.a7525b9c-73e0-49a9-8d38-2e2018307089@github.com>

> Hey, please consider.
> 
> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
> We also had this same format repeated many times.
> 
> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
> fadd_s is thus described in code as:
> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
> Instead of:
> `INSN(fadd_s,   0b1010011, 0b0000000);`
> 
> It then moves zfh/zfhmin to a sepererate section and assert checks them.
> 
> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
> 
> Tested:
> jdk/java/lang/Math
> jdk/java/util/Formatter/
> jdk/java/lang/Float/
> jdk/java/lang/Double/
> hotspot/jtreg/compiler/floatingpoint/
> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> hotspot/jtreg/compiler/eliminateAutobox/
> hotspot/jtreg/vmTestbase/jit/
> 
> And tier1 twice, no FP issues. (Using UseZfh/min)
> 
> Thanks, Robbin

Robbin Ehn 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:

 - Fix nit
 - Merge branch 'master' into zfhmin
 - FClassBits
 - Merge branch 'master' into zfhmin
 - Baseline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23130/files
  - new: https://git.openjdk.org/jdk/pull/23130/files/2eb4fa21..a63ee5cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=02-03

  Stats: 806 lines in 49 files changed: 509 ins; 138 del; 159 mod
  Patch: https://git.openjdk.org/jdk/pull/23130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23130/head:pull/23130

PR: https://git.openjdk.org/jdk/pull/23130

From rehn at openjdk.org  Mon Jan 20 13:48:51 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 20 Jan 2025 13:48:51 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v4]
In-Reply-To: <1t4xQC7fgk7qfYH_3WTaTdxcuX2Yq8KXXpUJCJXfDxw=.b373802a-0f75-4401-a040-787091b51e27@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <03CcZJ0q9C9SXLJ0Ie0UatsB-Br1VxG2chTwNDPRFWs=.cbfe2100-3ccd-42e2-a45f-5bc33f07c053@github.com>
 <1t4xQC7fgk7qfYH_3WTaTdxcuX2Yq8KXXpUJCJXfDxw=.b373802a-0f75-4401-a040-787091b51e27@github.com>
Message-ID: <YfV2URC7i6ChbE21i5ZCt20yqfLuZZ6YDXuN4-mtIRg=.f5dafc46-17e9-4550-870d-33d032cf87c9@github.com>

On Mon, 20 Jan 2025 12:58:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Looks good to me.

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23130#issuecomment-2602468198

From cnorrbin at openjdk.org  Mon Jan 20 15:03:06 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 20 Jan 2025 15:03:06 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v14]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <7uETGf-b8UH8j4OEow-u89ec_08pC-HEvtisfPJr258=.9aac817c-f33c-4619-9b76-069d9219367d@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  const functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/e1790595..8272e43f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=12-13

  Stats: 51 lines in 3 files changed: 19 ins; 5 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From stefank at openjdk.org  Mon Jan 20 15:24:35 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 Jan 2025 15:24:35 GMT
Subject: RFR: 8347564: ZGC: Crash in
 DependencyContext::clean_unloading_dependents
In-Reply-To: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
References: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
Message-ID: <e_8waG3xxA3lj1FpyF-8ihhctI5eadTQeSgJe12ag0c=.3ee80cf8-eb13-43d5-bed9-bf8f6646622c@github.com>

On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The proposed change here is the following:
>  1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object
>  2. Remove the Context object and its corresponding cleaner
> 
> (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose.
> 
> First what goes wrong without this patch.
> 
> Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. 
> 
> For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. 
> 
> The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection.
> 
> If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection  would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. 
> 
> For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ...

Looks good to me. I think it would be good if someone more familiar with the MethodHandle code also reviewed this.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23194#pullrequestreview-2562657174

From cnorrbin at openjdk.org  Mon Jan 20 15:28:05 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 20 Jan 2025 15:28:05 GMT
Subject: RFR: 8337997: MallocHeader description refers to non-existent NMT
 state "minimal"
Message-ID: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>

Hi everyone,

Small fix to a comment in `mallocHeader.hpp`, which referenced a non-existant NMT state. This has been changed to the correct (existing) state.

-------------

Commit messages:
 - fix mallocheader comment

Changes: https://git.openjdk.org/jdk/pull/23199/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23199&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337997
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23199/head:pull/23199

PR: https://git.openjdk.org/jdk/pull/23199

From ihse at openjdk.org  Mon Jan 20 16:37:48 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 20 Jan 2025 16:37:48 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v4]
In-Reply-To: <ajywiQd_SdD7aHHe_Zqo8umf8wmCnSycPnjnaS1OO5o=.097ed873-db3f-4d22-9cfb-bec72449bea9@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <ajywiQd_SdD7aHHe_Zqo8umf8wmCnSycPnjnaS1OO5o=.097ed873-db3f-4d22-9cfb-bec72449bea9@github.com>
Message-ID: <BRjQmyixixrLrXzXu2sSVfnqT0soCqc4cCbP2yEWH8g=.583c5ce4-bdb1-4ac5-8a7c-ba4d7688ec8b@github.com>

On Mon, 20 Jan 2025 10:06:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
>> 
>> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
>> 
>> The make files changes to support this are:
>> 1) Remove share/precompiled/ from the list of include directories,
>> 2) Compiler-specific changes to support this:
>> 
>> *Windows cl*:
>> * Add the share/precompiled/ include directory when generating the PCH file.
>> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
>> 
>> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
>> 
>> *gcc*:
>> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
>> 
>> *clang*:
>> * No changes needed, the -include-pch line is all that we need.
>> 
>> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
>> 
>> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
>> 
>> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
>> 
>> Tested by letting GHA build and running tier1-2 in our CI pipeline.
>
> Stefan Karlsson 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:
> 
>  - Copyright
>  - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Remove precompiled.hpp include from source files

Build changes looks good to me.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23146#pullrequestreview-2562807313

From lkorinth at openjdk.org  Mon Jan 20 17:42:38 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 20 Jan 2025 17:42:38 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v4]
In-Reply-To: <ajywiQd_SdD7aHHe_Zqo8umf8wmCnSycPnjnaS1OO5o=.097ed873-db3f-4d22-9cfb-bec72449bea9@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <ajywiQd_SdD7aHHe_Zqo8umf8wmCnSycPnjnaS1OO5o=.097ed873-db3f-4d22-9cfb-bec72449bea9@github.com>
Message-ID: <xRTM3Ch7KTLsEz5qbntcWl-yj0xYx5T_u6G2zQXin0I=.82cc5c6a-964b-4ab6-9f45-cfaaf14d8795@github.com>

On Mon, 20 Jan 2025 10:06:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
>> 
>> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
>> 
>> The make files changes to support this are:
>> 1) Remove share/precompiled/ from the list of include directories,
>> 2) Compiler-specific changes to support this:
>> 
>> *Windows cl*:
>> * Add the share/precompiled/ include directory when generating the PCH file.
>> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
>> 
>> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
>> 
>> *gcc*:
>> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
>> 
>> *clang*:
>> * No changes needed, the -include-pch line is all that we need.
>> 
>> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
>> 
>> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
>> 
>> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
>> 
>> Tested by letting GHA build and running tier1-2 in our CI pipeline.
>
> Stefan Karlsson 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:
> 
>  - Copyright
>  - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Remove precompiled.hpp include from source files

Looks great, thanks for doing this!!!

src/hotspot/share/classfile/dictionary.cpp line 1:

> 1: 

Added new-line at start of file, please remove.

src/hotspot/share/utilities/events.cpp line 1:

> 1: 

Added new-line at start of file, please remove.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23146#pullrequestreview-2562911221
PR Review Comment: https://git.openjdk.org/jdk/pull/23146#discussion_r1922707284
PR Review Comment: https://git.openjdk.org/jdk/pull/23146#discussion_r1922710809

From jsjolen at openjdk.org  Mon Jan 20 17:55:34 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 20 Jan 2025 17:55:34 GMT
Subject: RFR: 8337997: MallocHeader description refers to non-existent NMT
 state "minimal"
In-Reply-To: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
References: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
Message-ID: <PAGjjVTYniDXiNO08PETDLLrjXjshy5rs6QdjWysano=.01159475-c5ca-46cd-87e0-35dbd9d02515@github.com>

On Mon, 20 Jan 2025 15:16:10 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Small fix to a comment in `mallocHeader.hpp`, which referenced a non-existant NMT state. This has been changed to the correct (existing) state.

LGTM and trivial, thank you!

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23199#pullrequestreview-2562943798

From zgu at openjdk.org  Mon Jan 20 19:14:35 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 20 Jan 2025 19:14:35 GMT
Subject: RFR: 8337997: MallocHeader description refers to non-existent NMT
 state "minimal"
In-Reply-To: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
References: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
Message-ID: <M8Ipyd2xfrktU2hdRrfktcgXp9DfXMh1Vj10l_CJJl0=.9f1ea317-118c-4610-8d28-a68c6bdc8c92@github.com>

On Mon, 20 Jan 2025 15:16:10 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Small fix to a comment in `mallocHeader.hpp`, which referenced a non-existant NMT state. This has been changed to the correct (existing) state.

LGTM

-------------

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23199#pullrequestreview-2563033392

From dholmes at openjdk.org  Mon Jan 20 20:34:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jan 2025 20:34:38 GMT
Subject: RFR: 8348040: Bad use of ifdef with INCLUDE_xxx GC macros
In-Reply-To: <sRDPqSIkeFlacBkMUuruiCikKa0jZ3Jv4Uu6KBXzLJY=.157a3d07-0751-4537-9b77-d8fd4ba1332a@github.com>
References: <s10VNBkxJMbIFv9db-KibK-H-QX3XHqefTz9TQXAsts=.9c0d17dd-144b-44b3-adb1-8b55387aef1f@github.com>
 <sRDPqSIkeFlacBkMUuruiCikKa0jZ3Jv4Uu6KBXzLJY=.157a3d07-0751-4537-9b77-d8fd4ba1332a@github.com>
Message-ID: <hX1SnU3n-iUVErCm6dtSnkTSZz7_6fDl6lDukSm1T0o=.bc788192-6ff8-4d22-85d8-bc53817d2099@github.com>

On Mon, 20 Jan 2025 09:23:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The `INCLUDE_xxx` macros should be used with `#if` not `#ifdef` as the value is alway defined as either 1 or 0. So with `#ifdef` the guard is always true. This would lead to build problems in some cases if you built a configuration without the specified GC.
>> 
>> Testing:
>>  - tiers 1-3 sanity
>>  - tiers 4-5 builds
>> 
>> Thanks
>
> Marked as reviewed by stefank (Reviewer).

Thanks for the reviews @stefank and @shipilev !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23193#issuecomment-2603190039

From dholmes at openjdk.org  Mon Jan 20 20:34:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jan 2025 20:34:38 GMT
Subject: Integrated: 8348040: Bad use of ifdef with INCLUDE_xxx GC macros
In-Reply-To: <s10VNBkxJMbIFv9db-KibK-H-QX3XHqefTz9TQXAsts=.9c0d17dd-144b-44b3-adb1-8b55387aef1f@github.com>
References: <s10VNBkxJMbIFv9db-KibK-H-QX3XHqefTz9TQXAsts=.9c0d17dd-144b-44b3-adb1-8b55387aef1f@github.com>
Message-ID: <huc_-hY7bgIV4Yag96sugnTC4zGGk0nWk2vg8Y7rsFQ=.1ffbf014-7cf6-4873-9ec0-0c31cef99051@github.com>

On Sun, 19 Jan 2025 21:15:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The `INCLUDE_xxx` macros should be used with `#if` not `#ifdef` as the value is alway defined as either 1 or 0. So with `#ifdef` the guard is always true. This would lead to build problems in some cases if you built a configuration without the specified GC.
> 
> Testing:
>  - tiers 1-3 sanity
>  - tiers 4-5 builds
> 
> Thanks

This pull request has now been integrated.

Changeset: 955bf185
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/955bf185c38ec0fcedb0a549461fc85367b37fbb
Stats:     8 lines in 3 files changed: 0 ins; 1 del; 7 mod

8348040: Bad use of ifdef with INCLUDE_xxx GC macros

Reviewed-by: stefank, shade

-------------

PR: https://git.openjdk.org/jdk/pull/23193

From fyang at openjdk.org  Tue Jan 21 01:16:38 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Jan 2025 01:16:38 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v4]
In-Reply-To: <c9BLP5IMoFeJSsxZOI3uhcICsWdkcepJKCExjJBz9SQ=.a7525b9c-73e0-49a9-8d38-2e2018307089@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <c9BLP5IMoFeJSsxZOI3uhcICsWdkcepJKCExjJBz9SQ=.a7525b9c-73e0-49a9-8d38-2e2018307089@github.com>
Message-ID: <egy7-Spr6451bel3HUfkdgCsqArc67HoZCcMuqiQHyk=.0ca366cd-6cfa-46c7-a77d-ac5f6a801028@github.com>

On Mon, 20 Jan 2025 13:48:51 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hey, please consider.
>> 
>> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
>> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
>> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
>> We also had this same format repeated many times.
>> 
>> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
>> fadd_s is thus described in code as:
>> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
>> Instead of:
>> `INSN(fadd_s,   0b1010011, 0b0000000);`
>> 
>> It then moves zfh/zfhmin to a sepererate section and assert checks them.
>> 
>> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
>> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
>> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
>> 
>> Tested:
>> jdk/java/lang/Math
>> jdk/java/util/Formatter/
>> jdk/java/lang/Float/
>> jdk/java/lang/Double/
>> hotspot/jtreg/compiler/floatingpoint/
>> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> hotspot/jtreg/compiler/eliminateAutobox/
>> hotspot/jtreg/vmTestbase/jit/
>> 
>> And tier1 twice, no FP issues. (Using UseZfh/min)
>> 
>> Thanks, Robbin
>
> Robbin Ehn 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:
> 
>  - Fix nit
>  - Merge branch 'master' into zfhmin
>  - FClassBits
>  - Merge branch 'master' into zfhmin
>  - Baseline

Thanks for the update. One minor question remain.

src/hotspot/cpu/riscv/assembler_riscv.hpp line 941:

> 939: 
> 940:   template <FmtPrecision Fmt, uint8_t funct5>
> 941:   void fp_base(FloatRegister Rd, FloatRegister Rs1, int Rs2, int8_t rm) {

Minor question: Should `int Rs2` be `uint8_t Rs2` for consistency with friends?

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23130#pullrequestreview-2563291463
PR Review Comment: https://git.openjdk.org/jdk/pull/23130#discussion_r1922950560

From fyang at openjdk.org  Tue Jan 21 02:39:38 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Jan 2025 02:39:38 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <jit0wEWz-BVEVN1-x2Rlf9vldHLzrXRqcYzqZcCkZuU=.970de563-05c7-41ca-836e-bb6c097a741a@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <jit0wEWz-BVEVN1-x2Rlf9vldHLzrXRqcYzqZcCkZuU=.970de563-05c7-41ca-836e-bb6c097a741a@github.com>
Message-ID: <BmxErHoAoZgIZPFWkoJTi1pSZ2jqCLukHo7Qo6-fd8M=.341eb67f-9936-4cdf-b05d-1f3c5711d997@github.com>

On Sat, 18 Jan 2025 09:14:17 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider!
>> 
>> This patch the Zfa zli floating point immediate load.
>> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
>> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
>> 
>> When using one of the 32 'popular' floats we can now materialze them without a load.
>> E.g.
>> `float f = f1 * 0.5 + f2 * 2.0;`
>> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
>> 
>> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
>> 
>> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
>> 
>> Passes:
>> ./test/jdk/java/lang/Math
>> ./test/hotspot/jtreg/compiler/floatingpoint/
>> ./test/jdk/java/util/Formatter/
>> ./test/jdk/java/lang/Float/
>> ./test/jdk/java/lang/Double/
>> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> ./test/hotspot/jtreg/compiler/eliminateAutobox/
>> ./test/hotspot/jtreg/vmTestbase/jit/
>> 
>> Running tier1
>> 
>> Thanks!
>
> Robbin Ehn 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 three additional commits since the last revision:
> 
>  - Flip bool static decl
>  - Merge branch 'master' into zfa
>  - Baseline

src/hotspot/cpu/riscv/globals_riscv.hpp line 106:

> 104:   product(bool, UseZbb, false, DIAGNOSTIC, "Use Zbb instructions")               \
> 105:   product(bool, UseZbs, false, DIAGNOSTIC, "Use Zbs instructions")               \
> 106:   product(bool, UseZfa, false, DIAGNOSTIC, "Use Zfa instructions")               \

Is there any hardware available for testing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1922959920

From fyang at openjdk.org  Tue Jan 21 02:39:39 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Jan 2025 02:39:39 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <ZXlJqtmjHbMgonfdHwckVk6GQFSEMOrKOOFpK08WViE=.45d985f5-999c-4ea6-b77c-859b051bc7cf@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <yI5YtZKwsMUtmnfkfieMLGxeGA0l0lBvVrP6_CeFvnI=.c6af5027-6154-43d8-b3ae-6b3241cc55fa@github.com>
 <ZXlJqtmjHbMgonfdHwckVk6GQFSEMOrKOOFpK08WViE=.45d985f5-999c-4ea6-b77c-859b051bc7cf@github.com>
Message-ID: <Qy-WZ4eKz_YB4YaScL653RsYmHyxvGPs2gT0DefGieA=.539791b0-4144-4f9d-8ea9-fc66e8f8c7f7@github.com>

On Sat, 18 Jan 2025 08:43:10 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2634:
>> 
>>> 2632:   }
>>> 2633:   int Rs = -1;
>>> 2634:   can_zfa_zli_float(imm, &Rs);
>> 
>> should that be a `guarantee(can_zfa_zli_float(imm, &Rs));`?
>
> Same, my bad. (guarantee in zli_s on that Rs is uimm5.)
> 
> As we already an guarantee, maybe assert(can_zfa..) ?

How about we do this directly on the callsite?

  int Rs = -1;
  if (can_zfa_zli_float(imm, &Rs)) {
    _fli_s(Rd, Rs);
  }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1922990549

From amitkumar at openjdk.org  Tue Jan 21 03:52:37 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 21 Jan 2025 03:52:37 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
In-Reply-To: <bcyHyG1sE9nQLoizMbj-s4UuRy3DcVecUAoI4X68Oz4=.14aa0d1d-e0a6-41ff-9167-77127d07970f@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
 <bcyHyG1sE9nQLoizMbj-s4UuRy3DcVecUAoI4X68Oz4=.14aa0d1d-e0a6-41ff-9167-77127d07970f@github.com>
Message-ID: <prbuxWjSn7IOQlfPSNTvi8yAyG_EwmxZJdvM_-b77pA=.8eceadf5-33ee-419d-ab52-5e161e5062cf@github.com>

On Mon, 20 Jan 2025 13:45:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I was wondering why the entry frame uses the "extended sp" while the upcall stub should use the "unextended sp".



diff --git a/src/hotspot/cpu/s390/abstractInterpreter_s390.cpp b/src/hotspot/cpu/s390/abstractInterpreter_s390.cpp
index 866ebedfe3e..fb410f7186c 100644
--- a/src/hotspot/cpu/s390/abstractInterpreter_s390.cpp
+++ b/src/hotspot/cpu/s390/abstractInterpreter_s390.cpp
@@ -192,7 +192,8 @@ void AbstractInterpreter::layout_activation(Method* method,
            "must initialize sender_sp of bottom skeleton frame when pushing it");
   } else if (caller->is_upcall_stub_frame()) {
     // deoptimization case, sender_sp as unextended_sp, see frame::sender_for_interpreter_frame()
-    sender_sp = caller->unextended_sp();
+    if (!is_bottom_frame)
+      sender_sp = caller->unextended_sp();
   } else {
     assert(caller->is_entry_frame(), "is there a new frame type??");
     sender_sp = caller->sp(); // Call_stub only uses it's fp.
@@ -204,6 +205,7 @@ void AbstractInterpreter::layout_activation(Method* method,
   interpreter_frame->interpreter_frame_set_monitor_end((BasicObjectLock *)monitor);
   *interpreter_frame->interpreter_frame_cache_addr() = method->constants()->cache();
   interpreter_frame->interpreter_frame_set_tos_address(tos);
-  interpreter_frame->interpreter_frame_set_sender_sp(sender_sp);
+  if (!is_bottom_frame)
+    interpreter_frame->interpreter_frame_set_sender_sp(sender_sp);
   interpreter_frame->interpreter_frame_set_top_frame_sp(top_frame_sp);
 }

I did change similar to ppc, this also fixes the test case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23197#issuecomment-2603601666

From mbaesken at openjdk.org  Tue Jan 21 08:13:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 21 Jan 2025 08:13:38 GMT
Subject: RFR: 8348029: Make gtest death tests work with real crash signals
In-Reply-To: <3Ff8PvDpBAlZgaib29g7jHf6lBzKqIyhP766MH0GWjA=.498e7384-720e-426c-89db-18f874656256@github.com>
References: <3Ff8PvDpBAlZgaib29g7jHf6lBzKqIyhP766MH0GWjA=.498e7384-720e-426c-89db-18f874656256@github.com>
Message-ID: <LBnNsGRaASJvyJpZeMiPCio1hnGj_A_QEocGHqsEmUo=.2445052d-71b6-4c94-b998-44f0b6bca565@github.com>

On Sat, 18 Jan 2025 17:05:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small change adds a new macro to the gtest TEST macro zoo: `TEST_VM_CRASH_SIGNAL`. This one is a companion to `TEST_VM_FATAL_ERROR_MSG` and `TEST_VM_ASSERT_MSG` and allows to write gtest that test expected crashes to happen. I will need that for a regression test for https://bugs.openjdk.org/browse/JDK-8330174 , among other things.
> 
> You use it like this:
> 
> 
> TEST_VM_CRASH_SIGNAL(Testtest, test, "SIGSEGV") {
>   ... do something that you expect should result in a specific crash ...
> }
> 
> Note that the string provided is platform dependent (signal names on Posix, SEH names on Windows).

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23191#pullrequestreview-2563757641

From rehn at openjdk.org  Tue Jan 21 08:27:40 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Jan 2025 08:27:40 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <BmxErHoAoZgIZPFWkoJTi1pSZ2jqCLukHo7Qo6-fd8M=.341eb67f-9936-4cdf-b05d-1f3c5711d997@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <jit0wEWz-BVEVN1-x2Rlf9vldHLzrXRqcYzqZcCkZuU=.970de563-05c7-41ca-836e-bb6c097a741a@github.com>
 <BmxErHoAoZgIZPFWkoJTi1pSZ2jqCLukHo7Qo6-fd8M=.341eb67f-9936-4cdf-b05d-1f3c5711d997@github.com>
Message-ID: <2qE27an84fZ1Z8t4iXvd70KZOrh6ZZpRVO4_ybOmQ7U=.170e34bd-a38d-4296-afd6-31c3c3cce99f@github.com>

On Tue, 21 Jan 2025 01:33:43 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn 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 three additional commits since the last revision:
>> 
>>  - Flip bool static decl
>>  - Merge branch 'master' into zfa
>>  - Baseline
>
> src/hotspot/cpu/riscv/globals_riscv.hpp line 106:
> 
>> 104:   product(bool, UseZbb, false, DIAGNOSTIC, "Use Zbb instructions")               \
>> 105:   product(bool, UseZbs, false, DIAGNOSTIC, "Use Zbs instructions")               \
>> 106:   product(bool, UseZfa, false, DIAGNOSTIC, "Use Zfa instructions")               \
> 
> Is there any hardware available for testing?

I don't have such hardware anyways. Make exprimental?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1923265309

From rehn at openjdk.org  Tue Jan 21 08:28:22 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Jan 2025 08:28:22 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v5]
In-Reply-To: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
Message-ID: <X-LkQru8kli9XmuwNpPiH6o-9ZFz8o3RuwqWUBl2yng=.935afded-7cbc-47b4-8661-28c9f2928d6a@github.com>

> Hey, please consider.
> 
> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
> We also had this same format repeated many times.
> 
> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
> fadd_s is thus described in code as:
> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
> Instead of:
> `INSN(fadd_s,   0b1010011, 0b0000000);`
> 
> It then moves zfh/zfhmin to a sepererate section and assert checks them.
> 
> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
> 
> Tested:
> jdk/java/lang/Math
> jdk/java/util/Formatter/
> jdk/java/lang/Float/
> jdk/java/lang/Double/
> hotspot/jtreg/compiler/floatingpoint/
> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> hotspot/jtreg/compiler/eliminateAutobox/
> hotspot/jtreg/vmTestbase/jit/
> 
> And tier1 twice, no FP issues. (Using UseZfh/min)
> 
> Thanks, Robbin

Robbin Ehn 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:

 - Fixed type Rs2
 - Merge branch 'master' into zfhmin
 - Fix nit
 - Merge branch 'master' into zfhmin
 - FClassBits
 - Merge branch 'master' into zfhmin
 - Baseline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23130/files
  - new: https://git.openjdk.org/jdk/pull/23130/files/a63ee5cd..e6255851

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23130&range=03-04

  Stats: 4335 lines in 29 files changed: 2046 ins; 1598 del; 691 mod
  Patch: https://git.openjdk.org/jdk/pull/23130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23130/head:pull/23130

PR: https://git.openjdk.org/jdk/pull/23130

From rehn at openjdk.org  Tue Jan 21 08:28:23 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Jan 2025 08:28:23 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v4]
In-Reply-To: <egy7-Spr6451bel3HUfkdgCsqArc67HoZCcMuqiQHyk=.0ca366cd-6cfa-46c7-a77d-ac5f6a801028@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <c9BLP5IMoFeJSsxZOI3uhcICsWdkcepJKCExjJBz9SQ=.a7525b9c-73e0-49a9-8d38-2e2018307089@github.com>
 <egy7-Spr6451bel3HUfkdgCsqArc67HoZCcMuqiQHyk=.0ca366cd-6cfa-46c7-a77d-ac5f6a801028@github.com>
Message-ID: <lOF8TOEG6ndeE3vbBMAqWt-QqiSNWeLB6LlIYqWFEYQ=.aca8c515-bc05-4c34-b41d-fb9d73aed1a6@github.com>

On Tue, 21 Jan 2025 01:12:58 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn 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:
>> 
>>  - Fix nit
>>  - Merge branch 'master' into zfhmin
>>  - FClassBits
>>  - Merge branch 'master' into zfhmin
>>  - Baseline
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 941:
> 
>> 939: 
>> 940:   template <FmtPrecision Fmt, uint8_t funct5>
>> 941:   void fp_base(FloatRegister Rd, FloatRegister Rs1, int Rs2, int8_t rm) {
> 
> Minor question: Should `int Rs2` be `uint8_t Rs2` for consistency with friends?

Yes, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23130#discussion_r1923262888

From fyang at openjdk.org  Tue Jan 21 08:40:36 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Jan 2025 08:40:36 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v5]
In-Reply-To: <X-LkQru8kli9XmuwNpPiH6o-9ZFz8o3RuwqWUBl2yng=.935afded-7cbc-47b4-8661-28c9f2928d6a@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <X-LkQru8kli9XmuwNpPiH6o-9ZFz8o3RuwqWUBl2yng=.935afded-7cbc-47b4-8661-28c9f2928d6a@github.com>
Message-ID: <JcsCEM9O3KF7bfybZMScmykg5RV8qQxS01f9YUeVzr0=.d68080e1-865f-4b41-bb83-3458a2e79286@github.com>

On Tue, 21 Jan 2025 08:28:22 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hey, please consider.
>> 
>> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
>> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
>> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
>> We also had this same format repeated many times.
>> 
>> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
>> fadd_s is thus described in code as:
>> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
>> Instead of:
>> `INSN(fadd_s,   0b1010011, 0b0000000);`
>> 
>> It then moves zfh/zfhmin to a sepererate section and assert checks them.
>> 
>> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
>> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
>> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
>> 
>> Tested:
>> jdk/java/lang/Math
>> jdk/java/util/Formatter/
>> jdk/java/lang/Float/
>> jdk/java/lang/Double/
>> hotspot/jtreg/compiler/floatingpoint/
>> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> hotspot/jtreg/compiler/eliminateAutobox/
>> hotspot/jtreg/vmTestbase/jit/
>> 
>> And tier1 twice, no FP issues. (Using UseZfh/min)
>> 
>> Thanks, Robbin
>
> Robbin Ehn 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:
> 
>  - Fixed type Rs2
>  - Merge branch 'master' into zfhmin
>  - Fix nit
>  - Merge branch 'master' into zfhmin
>  - FClassBits
>  - Merge branch 'master' into zfhmin
>  - Baseline

Marked as reviewed by fyang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23130#pullrequestreview-2563836186

From rehn at openjdk.org  Tue Jan 21 08:45:36 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Jan 2025 08:45:36 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <jit0wEWz-BVEVN1-x2Rlf9vldHLzrXRqcYzqZcCkZuU=.970de563-05c7-41ca-836e-bb6c097a741a@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <jit0wEWz-BVEVN1-x2Rlf9vldHLzrXRqcYzqZcCkZuU=.970de563-05c7-41ca-836e-bb6c097a741a@github.com>
Message-ID: <Ykg2B-lRKQDYphRv1YqMNhOUgj_iTLkp4SLhK2JylYA=.8fc488e0-b7ae-46ab-bc09-bc6b3064ea2f@github.com>

On Sat, 18 Jan 2025 09:14:17 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider!
>> 
>> This patch the Zfa zli floating point immediate load.
>> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
>> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
>> 
>> When using one of the 32 'popular' floats we can now materialze them without a load.
>> E.g.
>> `float f = f1 * 0.5 + f2 * 2.0;`
>> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
>> 
>> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
>> 
>> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
>> 
>> Passes:
>> ./test/jdk/java/lang/Math
>> ./test/hotspot/jtreg/compiler/floatingpoint/
>> ./test/jdk/java/util/Formatter/
>> ./test/jdk/java/lang/Float/
>> ./test/jdk/java/lang/Double/
>> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> ./test/hotspot/jtreg/compiler/eliminateAutobox/
>> ./test/hotspot/jtreg/vmTestbase/jit/
>> 
>> Running tier1
>> 
>> Thanks!
>
> Robbin Ehn 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 three additional commits since the last revision:
> 
>  - Flip bool static decl
>  - Merge branch 'master' into zfa
>  - Baseline

It's seem you made a non-review comment above, I can't reply.

**can_zfa_zli_float()** method only  checks if we can use a zli for that imm.
**can_fp_imm_load()** checks if we can do something better than loading the imm.

Right now we have two cases:
- imm == 0-bits sets
- imm == zli Rs pattern

As many application are memory bound and loading may miss L1.
This means we want to do plain materializing if we can't more or less guarantee L1 hit and the load do not stall other loads.

Therefore we should add more cases to above, for exampel:
lui + slli + fmw

The callsite is asking do I need to load from an address using fld/flw or can I materialize.
So I prefer the callsite to be unaware that in one of the cases we map an imm to a bit pattern in Rs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23171#issuecomment-2603987527

From dholmes at openjdk.org  Tue Jan 21 08:50:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Jan 2025 08:50:08 GMT
Subject: RFR: 8348117: The two-argument overload of
 SignatureHandlerLibrary::add is not used
Message-ID: <vW88xKa_FXz0vVgGDhxMTVLTLu_MgkFbcGhf2xcSKJs=.a7692e6c-ac3c-4035-ac7e-141952c7a457@github.com>

The  `SignatureHandlerLibrary::add` two-arg API was added to support closed code under [JDK-8087333](https://bugs.openjdk.org/browse/JDK-8087333) in JDK 9. That closed code was removed again, still in JDK 9, as part of JEP 297 ([JDK-8168503](https://bugs.openjdk.org/browse/JDK-8168503)) which unified the closed and open ARM ports - leaving the API unused.

There were other leftovers from the same set of changes so they are cleaned up as well - nothing significant, just unnecessary friend declarations, comments, and one other method.

Testing:
 - all builds in tiers 1-5

Thanks.

-------------

Commit messages:
 - 8348117: The two-argument overload of SignatureHandlerLibrary::add is not used

Changes: https://git.openjdk.org/jdk/pull/23207/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23207&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348117
  Stats: 40 lines in 9 files changed: 0 ins; 40 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23207/head:pull/23207

PR: https://git.openjdk.org/jdk/pull/23207

From stuefe at openjdk.org  Tue Jan 21 09:11:35 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 21 Jan 2025 09:11:35 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v2]
In-Reply-To: <OExJi0h-B9ljGqcI67G8a5HNIRWcysnq4uxhpl826aA=.cc973e9d-8356-4a4d-be78-95e7316931f6@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
 <OExJi0h-B9ljGqcI67G8a5HNIRWcysnq4uxhpl826aA=.cc973e9d-8356-4a4d-be78-95e7316931f6@github.com>
Message-ID: <KY7u0N2N4iipkMi_OWm8HrfaC4T7hWETVU3cEHLYmjw=.9deab570-8fb3-4a56-8c4b-09a2af1f5d4c@github.com>

On Sun, 19 Jan 2025 09:54:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 
>> 
>> Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.
>> 
>> We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.
>> 
>> This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.
>> 
>> Additionally, the patch provides a helpful output in the register/stack section, e.g:
>> 
>> 
>> RDI=0x0000000800000000 points into nKlass protection zone
>> 
>> 
>> 
>> Testing: 
>> - GHAs.
>> - I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
>> - I tested manually on Windows x64
>> - I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   treat not-found protection zone buffer as fatal error

I cannot reproduce the test error on Windows (gc/shenandoah/compiler/TestClone#generational-no-coops-verify) on my machine, but don't think it relates to my patch.

I made sure the feature works on Windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23190#issuecomment-2604104496

From stefank at openjdk.org  Tue Jan 21 09:20:50 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jan 2025 09:20:50 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v5]
In-Reply-To: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
Message-ID: <l323t12391ubLZysKn-6kfj3TxxsyRlR-yPj_DfbTDY=.bfb11407-1ec5-4f0a-95cb-2e97172e9735@github.com>

> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
> 
> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
> 
> The make files changes to support this are:
> 1) Remove share/precompiled/ from the list of include directories,
> 2) Compiler-specific changes to support this:
> 
> *Windows cl*:
> * Add the share/precompiled/ include directory when generating the PCH file.
> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
> 
> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
> 
> *gcc*:
> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
> 
> *clang*:
> * No changes needed, the -include-pch line is all that we need.
> 
> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
> 
> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
> 
> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
> 
> Tested by letting GHA build and running tier1-2 in our CI pipeline.

Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:

 - Update events.cpp
 - Update dictionary.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23146/files
  - new: https://git.openjdk.org/jdk/pull/23146/files/512941c0..a591e434

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23146/head:pull/23146

PR: https://git.openjdk.org/jdk/pull/23146

From lliu at openjdk.org  Tue Jan 21 09:25:37 2025
From: lliu at openjdk.org (Liming Liu)
Date: Tue, 21 Jan 2025 09:25:37 GMT
Subject: [jdk24] RFR: 8343978: Update the default value of
 CodeEntryAlignment for Ampere-1A and 1B
In-Reply-To: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
References: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
Message-ID: <HQWOQeFofV-hqyHbF0FNvnhDskQveQGwDRPqUT-z74s=.1bcda67b-b6a1-4e6b-b97c-5a4bac4356d9@github.com>

On Fri, 10 Jan 2025 07:42:33 GMT, Liming Liu <lliu at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 89ee1a55 from the openjdk/jdk repository.
> 
> The commit being backported was authored by Liming Liu on 9 Jan 2025 and was reviewed by Dean Long and Vladimir Kozlov.
> 
> Thanks!

Hi, @dean-long, @vnkozlov,

Could you please take a look? The RDP2 of JDK 24 will end on Feb. 6th, while I will be on vacation for the next two weeks, so I want to integrate this patch this week. Thanks in advance!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23027#issuecomment-2604137997

From stefank at openjdk.org  Tue Jan 21 09:26:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jan 2025 09:26:55 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v6]
In-Reply-To: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
Message-ID: <gOgUOQQUee9Ogkmd_50tX_oQiM-22OWjPVRPSsIw_hw=.6d86fca0-7a5d-429a-8544-7f5300ff6962@github.com>

> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
> 
> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
> 
> The make files changes to support this are:
> 1) Remove share/precompiled/ from the list of include directories,
> 2) Compiler-specific changes to support this:
> 
> *Windows cl*:
> * Add the share/precompiled/ include directory when generating the PCH file.
> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
> 
> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
> 
> *gcc*:
> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
> 
> *clang*:
> * No changes needed, the -include-pch line is all that we need.
> 
> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
> 
> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
> 
> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
> 
> Tested by letting GHA build and running tier1-2 in our CI pipeline.

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
 - Update events.cpp
 - Update dictionary.cpp
 - Copyright
 - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/common/native/CompileFile.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Remove precompiled.hpp include from source files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23146/files
  - new: https://git.openjdk.org/jdk/pull/23146/files/a591e434..e4a9309a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23146&range=04-05

  Stats: 5179 lines in 48 files changed: 2565 ins; 1837 del; 777 mod
  Patch: https://git.openjdk.org/jdk/pull/23146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23146/head:pull/23146

PR: https://git.openjdk.org/jdk/pull/23146

From lkorinth at openjdk.org  Tue Jan 21 09:31:39 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 21 Jan 2025 09:31:39 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v6]
In-Reply-To: <gOgUOQQUee9Ogkmd_50tX_oQiM-22OWjPVRPSsIw_hw=.6d86fca0-7a5d-429a-8544-7f5300ff6962@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <gOgUOQQUee9Ogkmd_50tX_oQiM-22OWjPVRPSsIw_hw=.6d86fca0-7a5d-429a-8544-7f5300ff6962@github.com>
Message-ID: <YEYkZtIh8PHbh3ZvjiQ15jbP4KufvA40JYm4zsoVEsY=.441627a8-904f-47a2-925e-d5aa5befe777@github.com>

On Tue, 21 Jan 2025 09:26:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
>> 
>> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
>> 
>> The make files changes to support this are:
>> 1) Remove share/precompiled/ from the list of include directories,
>> 2) Compiler-specific changes to support this:
>> 
>> *Windows cl*:
>> * Add the share/precompiled/ include directory when generating the PCH file.
>> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
>> 
>> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
>> 
>> *gcc*:
>> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
>> 
>> *clang*:
>> * No changes needed, the -include-pch line is all that we need.
>> 
>> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
>> 
>> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
>> 
>> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
>> 
>> Tested by letting GHA build and running tier1-2 in our CI pipeline.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
>  - Update events.cpp
>  - Update dictionary.cpp
>  - Copyright
>  - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Remove precompiled.hpp include from source files

Marked as reviewed by lkorinth (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23146#pullrequestreview-2563987316

From mdoerr at openjdk.org  Tue Jan 21 09:49:35 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 21 Jan 2025 09:49:35 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
In-Reply-To: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
Message-ID: <IfPZgU0FOhYJQjU1ZzoI30E1kbO4DQ_9d2046lYnW4c=.5b50a4c6-b4c0-411b-889b-330e6449196a@github.com>

On Mon, 20 Jan 2025 11:24:39 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Fixes `foreign/normalize/TestNormalize.java` failure on s390x.

Does this work? This would be equivalent to the PPC64 solution:

diff --git a/src/hotspot/cpu/s390/abstractInterpreter_s390.cpp b/src/hotspot/cpu/s390/abstractInterpreter_s390.cpp
index c24c2b56bf7..ad3721918cc 100644
--- a/src/hotspot/cpu/s390/abstractInterpreter_s390.cpp
+++ b/src/hotspot/cpu/s390/abstractInterpreter_s390.cpp
@@ -191,7 +191,7 @@ void AbstractInterpreter::layout_activation(Method* method,
     assert(is_bottom_frame && (sender_sp == caller->unextended_sp()),
            "must initialize sender_sp of bottom skeleton frame when pushing it");
   } else {
-    assert(caller->is_entry_frame(), "is there a new frame type??");
+    assert(caller->is_entry_frame() || caller->is_upcall_stub_frame(), "is there a new frame type??");
     sender_sp = caller->sp(); // Call_stub only uses it's fp.
   }
 
@@ -201,6 +201,8 @@ void AbstractInterpreter::layout_activation(Method* method,
   interpreter_frame->interpreter_frame_set_monitor_end((BasicObjectLock *)monitor);
   *interpreter_frame->interpreter_frame_cache_addr() = method->constants()->cache();
   interpreter_frame->interpreter_frame_set_tos_address(tos);
-  interpreter_frame->interpreter_frame_set_sender_sp(sender_sp);
+  if (!is_bottom_frame) {
+    interpreter_frame->interpreter_frame_set_sender_sp(sender_sp);
+  }
   interpreter_frame->interpreter_frame_set_top_frame_sp(top_frame_sp);
 }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23197#issuecomment-2604194372

From duke at openjdk.org  Tue Jan 21 09:53:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 21 Jan 2025 09:53:47 GMT
Subject: Withdrawn: 8337199: Add jcmd Thread.vthread_summary diagnostic command
In-Reply-To: <OZJen5GKkXSW4Blf0vN3WQLTd087jsVb1cCE8MNGAFU=.69395f86-1a1b-4ee7-9b0b-3464b3bd323d@github.com>
References: <OZJen5GKkXSW4Blf0vN3WQLTd087jsVb1cCE8MNGAFU=.69395f86-1a1b-4ee7-9b0b-3464b3bd323d@github.com>
Message-ID: <KxCUVhXjWHvVeePHqWr6R6j8QBluZlu59xbiTezDO2o=.51c660cb-2bfd-4088-9100-41e99a1ab5c3@github.com>

On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable <duke at openjdk.org> wrote:

> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420)
> 
> Summary
> -------
> 
> Add `jcmd <pid> Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads.
> 
> 
> Problem
> -------
> 
> The JDK is lacking tooling to diagnose issues with virtual threads.
> 
> 
> Solution
> --------
> 
> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings.
> 
> Here is sample output. The output is intended for experts and is not intended for automated parsing.
> 
> 
> Virtual thread scheduler:
> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0]
> 
> Timeout schedulers:
> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0]
> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> 
> Read I/O pollers:
> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1]
> 
> Write I/O pollers:
> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0]
> 
> Thread groupings:
> <root> [platform threads = 11, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0]
> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2]
> ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0]
> java.util.concurrent.Scheduled...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22121

From fyang at openjdk.org  Tue Jan 21 09:55:41 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 21 Jan 2025 09:55:41 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <Qy-WZ4eKz_YB4YaScL653RsYmHyxvGPs2gT0DefGieA=.539791b0-4144-4f9d-8ea9-fc66e8f8c7f7@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <yI5YtZKwsMUtmnfkfieMLGxeGA0l0lBvVrP6_CeFvnI=.c6af5027-6154-43d8-b3ae-6b3241cc55fa@github.com>
 <ZXlJqtmjHbMgonfdHwckVk6GQFSEMOrKOOFpK08WViE=.45d985f5-999c-4ea6-b77c-859b051bc7cf@github.com>
 <Qy-WZ4eKz_YB4YaScL653RsYmHyxvGPs2gT0DefGieA=.539791b0-4144-4f9d-8ea9-fc66e8f8c7f7@github.com>
Message-ID: <LkrzacMIHzdUSGdFxVzSOgi4ruQ56bDXs5mfveKRDAI=.9f00f850-1dca-4123-9483-2e24e869ffbe@github.com>

On Tue, 21 Jan 2025 02:36:32 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Same, my bad. (guarantee in zli_s on that Rs is uimm5.)
>> 
>> As we already an guarantee, maybe assert(can_zfa..) ?
>
> How about we do this directly on the callsite?
> 
>   int Rs = -1;
>   if (can_zfa_zli_float(imm, &Rs)) {
>     _fli_s(Rd, Rs);
>   }

Or can we use `zfa_zli_lookup_float/double` instead here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1923401155

From mli at openjdk.org  Tue Jan 21 10:02:41 2025
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 21 Jan 2025 10:02:41 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v5]
In-Reply-To: <X-LkQru8kli9XmuwNpPiH6o-9ZFz8o3RuwqWUBl2yng=.935afded-7cbc-47b4-8661-28c9f2928d6a@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <X-LkQru8kli9XmuwNpPiH6o-9ZFz8o3RuwqWUBl2yng=.935afded-7cbc-47b4-8661-28c9f2928d6a@github.com>
Message-ID: <roWoqKVWgqHtP2EmNo8oqgYJrSWp6tBXx9EcuHBammg=.7b87d1d1-e6a1-4d17-89d6-e85f1793cea8@github.com>

On Tue, 21 Jan 2025 08:28:22 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hey, please consider.
>> 
>> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
>> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
>> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
>> We also had this same format repeated many times.
>> 
>> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
>> fadd_s is thus described in code as:
>> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
>> Instead of:
>> `INSN(fadd_s,   0b1010011, 0b0000000);`
>> 
>> It then moves zfh/zfhmin to a sepererate section and assert checks them.
>> 
>> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
>> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
>> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
>> 
>> Tested:
>> jdk/java/lang/Math
>> jdk/java/util/Formatter/
>> jdk/java/lang/Float/
>> jdk/java/lang/Double/
>> hotspot/jtreg/compiler/floatingpoint/
>> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> hotspot/jtreg/compiler/eliminateAutobox/
>> hotspot/jtreg/vmTestbase/jit/
>> 
>> And tier1 twice, no FP issues. (Using UseZfh/min)
>> 
>> Thanks, Robbin
>
> Robbin Ehn 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:
> 
>  - Fixed type Rs2
>  - Merge branch 'master' into zfhmin
>  - Fix nit
>  - Merge branch 'master' into zfhmin
>  - FClassBits
>  - Merge branch 'master' into zfhmin
>  - Baseline

Looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23130#pullrequestreview-2564068948

From stefank at openjdk.org  Tue Jan 21 10:20:42 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jan 2025 10:20:42 GMT
Subject: RFR: 8347909: Automatic precompiled.hpp inclusion [v6]
In-Reply-To: <gOgUOQQUee9Ogkmd_50tX_oQiM-22OWjPVRPSsIw_hw=.6d86fca0-7a5d-429a-8544-7f5300ff6962@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
 <gOgUOQQUee9Ogkmd_50tX_oQiM-22OWjPVRPSsIw_hw=.6d86fca0-7a5d-429a-8544-7f5300ff6962@github.com>
Message-ID: <GruyBhqRnGnaK7HZRh3gIw2vngPc7pXLXemxY7FKXQk=.66e968a1-bcdf-4e0e-8b82-872da6a9eeaf@github.com>

On Tue, 21 Jan 2025 09:26:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
>> 
>> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
>> 
>> The make files changes to support this are:
>> 1) Remove share/precompiled/ from the list of include directories,
>> 2) Compiler-specific changes to support this:
>> 
>> *Windows cl*:
>> * Add the share/precompiled/ include directory when generating the PCH file.
>> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
>> 
>> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
>> 
>> *gcc*:
>> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
>> 
>> *clang*:
>> * No changes needed, the -include-pch line is all that we need.
>> 
>> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
>> 
>> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
>> 
>> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
>> 
>> Tested by letting GHA build and running tier1-2 in our CI pipeline.
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
>  - Update events.cpp
>  - Update dictionary.cpp
>  - Copyright
>  - Merge remote-tracking branch 'upstream/master' into 8347909_remove_precompiled_from_src
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update make/common/native/CompileFile.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Remove precompiled.hpp include from source files

I've fixed the nits that Leo found, merged with upstream, and run the build tasks of tier1-2. Thanks all for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23146#issuecomment-2604285701

From stefank at openjdk.org  Tue Jan 21 10:24:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jan 2025 10:24:46 GMT
Subject: Integrated: 8347909: Automatic precompiled.hpp inclusion
In-Reply-To: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
References: <vWO0ciCBjSmN2hxueCZq0cDaC_eAo8qlV09jLT2Z1GM=.1e588920-36f1-4c4c-912b-4c7f31d5c907@github.com>
Message-ID: <5-Sts6XoAO6VTCymGhrmb_RQyvawyJDpisbljuzz6TM=.c8b6797d-b880-462f-be4c-4acbb2b8c7bc@github.com>

On Thu, 16 Jan 2025 11:28:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> HotSpot uses precompiled headers to speed up non-incremental builds. The current mechanism requires all .cpp files to include precompiled.hpp as the first non-comment line. This requires HotSpot devs to think about precompiled headers when they create new files and when they need to update/manage the include sections.
> 
> All the compilers that we use support using precompiled headers without explicitly including the associated header in the source code. I propose that we use that capability instead. 
> 
> The make files changes to support this are:
> 1) Remove share/precompiled/ from the list of include directories,
> 2) Compiler-specific changes to support this:
> 
> *Windows cl*:
> * Add the share/precompiled/ include directory when generating the PCH file.
> * Use /FI to indicate that we should include precompiled.hpp. /Yu says that it should use a PCH for precompiled.hpp. /Fp tells the compiler that it should pick up the named precompiled header.
> 
> From experiments it seems like it doesn't matter what name I pass in to /FI and /Yu, they just have to be the same and the specified file doesn't even have to exist, as long as we also pass in the /Fp flag we get the benefits of the precompiled header.
> 
> *gcc*:
> * Use -include to include the precompiled.hpp file. Note that the compilation command line will not have share/precompiled in the include path and that the precompiled header will still be picked up correctly.
> 
> *clang*:
> * No changes needed, the -include-pch line is all that we need.
> 
> I've verified that these changes give the expected compilation time reductions both by comparing compilation times in our CI but also by running individual compilations of .cpp files on Linux, Mac, and Windows.
> 
> Note that the compiler will complain if someone now tries to include precompiled.hpp explicitly.
> 
> Note also that we have a section about precompiled.hpp in the HotSpot style guide. If this proposal is accepted I would like to update the style guide as a separate RFE.
> 
> Tested by letting GHA build and running tier1-2 in our CI pipeline.

This pull request has now been integrated.

Changeset: c33c1cfe
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c33c1cfe7349ac657cd7bf54861227709d3c8f1b
Stats:     3160 lines in 1757 files changed: 7 ins; 1837 del; 1316 mod

8347909: Automatic precompiled.hpp inclusion

Reviewed-by: lkorinth, erikj, dholmes, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/23146

From amitkumar at openjdk.org  Tue Jan 21 10:35:34 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 21 Jan 2025 10:35:34 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
In-Reply-To: <IfPZgU0FOhYJQjU1ZzoI30E1kbO4DQ_9d2046lYnW4c=.5b50a4c6-b4c0-411b-889b-330e6449196a@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
 <IfPZgU0FOhYJQjU1ZzoI30E1kbO4DQ_9d2046lYnW4c=.5b50a4c6-b4c0-411b-889b-330e6449196a@github.com>
Message-ID: <Ct3MZXGd91T0lJts6UiLO90SarX4N9zds07Eq0_rtFY=.a33d149b-de97-4869-a351-28fbabdd947f@github.com>

On Tue, 21 Jan 2025 09:47:16 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Does this work? 

Yes, it works. I want to understand if `caller->is_upcall_stub_frame() && (!is_bottom_frame)` is a valid condition ? 

I added this code and it seems no test is failing from `test/jdk/java/foreign` directory: 

+  if (caller->is_upcall_stub_frame() && (!is_bottom_frame)) {
+    assert(false, "just testing");
+  }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23197#issuecomment-2604334513

From mdoerr at openjdk.org  Tue Jan 21 10:41:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 21 Jan 2025 10:41:38 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
In-Reply-To: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
Message-ID: <MbvF1I34M2hux3ipJ2BzPMCaT0sgCBehDAexAOZrQK0=.0361ec61-06b1-4bdf-afbb-aa9f3e625394@github.com>

On Mon, 20 Jan 2025 11:24:39 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Fixes `foreign/normalize/TestNormalize.java` failure on s390x.

Upcall stub frames and entry frames are always below the bottom frame.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23197#issuecomment-2604349296

From rehn at openjdk.org  Tue Jan 21 10:48:37 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Jan 2025 10:48:37 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v5]
In-Reply-To: <YfV2URC7i6ChbE21i5ZCt20yqfLuZZ6YDXuN4-mtIRg=.f5dafc46-17e9-4550-870d-33d032cf87c9@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <03CcZJ0q9C9SXLJ0Ie0UatsB-Br1VxG2chTwNDPRFWs=.cbfe2100-3ccd-42e2-a45f-5bc33f07c053@github.com>
 <1t4xQC7fgk7qfYH_3WTaTdxcuX2Yq8KXXpUJCJXfDxw=.b373802a-0f75-4401-a040-787091b51e27@github.com>
 <YfV2URC7i6ChbE21i5ZCt20yqfLuZZ6YDXuN4-mtIRg=.f5dafc46-17e9-4550-870d-33d032cf87c9@github.com>
Message-ID: <oXUZnOTFfVxoj7-hYBz6swpB72fHLezs143GuJAk6jU=.87a100e8-1e50-4b23-a748-bc9a8f2c47f3@github.com>

On Mon, 20 Jan 2025 13:45:31 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Looks good.

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23130#issuecomment-2604368604

From coleenp at openjdk.org  Tue Jan 21 12:24:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jan 2025 12:24:35 GMT
Subject: RFR: 8348117: The two-argument overload of
 SignatureHandlerLibrary::add is not used
In-Reply-To: <vW88xKa_FXz0vVgGDhxMTVLTLu_MgkFbcGhf2xcSKJs=.a7692e6c-ac3c-4035-ac7e-141952c7a457@github.com>
References: <vW88xKa_FXz0vVgGDhxMTVLTLu_MgkFbcGhf2xcSKJs=.a7692e6c-ac3c-4035-ac7e-141952c7a457@github.com>
Message-ID: <FpV9n5RaLCCaqQ05YxURkv3s6Bz53z5lVzLRsLzO7iQ=.ea859db9-7b50-4bac-a6bd-741e64b8051e@github.com>

On Tue, 21 Jan 2025 08:44:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The  `SignatureHandlerLibrary::add` two-arg API was added to support closed code under [JDK-8087333](https://bugs.openjdk.org/browse/JDK-8087333) in JDK 9. That closed code was removed again, still in JDK 9, as part of JEP 297 ([JDK-8168503](https://bugs.openjdk.org/browse/JDK-8168503)) which unified the closed and open ARM ports - leaving the API unused.
> 
> There were other leftovers from the same set of changes so they are cleaned up as well - nothing significant, just unnecessary friend declarations, comments, and one other method.
> 
> Testing:
>  - all builds in tiers 1-5
> 
> Thanks.

Looks good!

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23207#pullrequestreview-2564461281

From stefank at openjdk.org  Tue Jan 21 12:35:26 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jan 2025 12:35:26 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from the
 HotSpot Style Guide
Message-ID: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>

[JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need for HotSpot devs to include the precompiled.hpp. This is the PR to reflect that.

I know that there is some process around updating the style guide, but I can't find it, so I'm starting with a plain PR.

-------------

Commit messages:
 - 8348180: Remove mention of include of precompiled.hpp from the HotSpot Style Guide

Changes: https://git.openjdk.org/jdk/pull/23210/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23210&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348180
  Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23210.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23210/head:pull/23210

PR: https://git.openjdk.org/jdk/pull/23210

From eosterlund at openjdk.org  Tue Jan 21 12:49:35 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Jan 2025 12:49:35 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide
In-Reply-To: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
Message-ID: <-dDdDa537-OaD3AYtavACAzTnZ120AwlMBR_olRn27I=.dec6eaff-5f2f-4cc9-887f-6c9c0512deeb@github.com>

On Tue, 21 Jan 2025 12:29:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need for HotSpot devs to include the precompiled.hpp. This is the PR to reflect that.
> 
> I know that there is some process around updating the style guide, but I can't find it, so I'm starting with a plain PR.

Seems reasonable.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23210#pullrequestreview-2564522660

From szaldana at openjdk.org  Tue Jan 21 13:06:43 2025
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 21 Jan 2025 13:06:43 GMT
Subject: RFR: 8348029: Make gtest death tests work with real crash signals
In-Reply-To: <3Ff8PvDpBAlZgaib29g7jHf6lBzKqIyhP766MH0GWjA=.498e7384-720e-426c-89db-18f874656256@github.com>
References: <3Ff8PvDpBAlZgaib29g7jHf6lBzKqIyhP766MH0GWjA=.498e7384-720e-426c-89db-18f874656256@github.com>
Message-ID: <p-tCDVQRvZ8RP12PVubsFheya6tatWnAonzxZ004UmY=.df1286b3-f7c9-4e97-ab48-8769274fa54f@github.com>

On Sat, 18 Jan 2025 17:05:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small change adds a new macro to the gtest TEST macro zoo: `TEST_VM_CRASH_SIGNAL`. This one is a companion to `TEST_VM_FATAL_ERROR_MSG` and `TEST_VM_ASSERT_MSG` and allows to write gtest that test expected crashes to happen. I will need that for a regression test for https://bugs.openjdk.org/browse/JDK-8330174 , among other things.
> 
> You use it like this:
> 
> 
> TEST_VM_CRASH_SIGNAL(Testtest, test, "SIGSEGV") {
>   ... do something that you expect should result in a specific crash ...
> }
> 
> Note that the string provided is platform dependent (signal names on Posix, SEH names on Windows).

I am not a Reviewer but this looks good to me. Also very useful! Thanks @tstuefe.

-------------

Marked as reviewed by szaldana (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23191#pullrequestreview-2564570995

From kbarrett at openjdk.org  Tue Jan 21 13:07:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 21 Jan 2025 13:07:35 GMT
Subject: RFR: 8347990: Remove SIZE_FORMAT macros and replace remaining uses
In-Reply-To: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>
References: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>
Message-ID: <aIzivEvuU6-8dlt4lWeAwY6r091k5BNsD3JFOSlu8oI=.dd73feef-8acc-48bc-9ce8-de711c424813@github.com>

On Fri, 17 Jan 2025 18:46:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this patch that removes the SIZE_FORMAT macros and the remaining uses I missed in metaspace and the gtests.
> Tested with tier1-4, and cross-compiled other platforms (except they fail for other reasons).

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23180#pullrequestreview-2564572923

From coleenp at openjdk.org  Tue Jan 21 13:21:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jan 2025 13:21:38 GMT
Subject: RFR: 8347990: Remove SIZE_FORMAT macros and replace remaining uses
In-Reply-To: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>
References: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>
Message-ID: <EueoTo68jd7HfBb6GmweKwrNXQhzzvplbIs0JlMfeec=.914cd174-1104-48c8-b69d-a65338e3b869@github.com>

On Fri, 17 Jan 2025 18:46:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this patch that removes the SIZE_FORMAT macros and the remaining uses I missed in metaspace and the gtests.
> Tested with tier1-4, and cross-compiled other platforms (except they fail for other reasons).

Thanks for reviewing David and Kim.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23180#issuecomment-2604712720

From coleenp at openjdk.org  Tue Jan 21 13:21:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jan 2025 13:21:39 GMT
Subject: Integrated: 8347990: Remove SIZE_FORMAT macros and replace remaining
 uses
In-Reply-To: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>
References: <w01Wav95F6BnV1daRis4vEGKHc6mVmE7UkFa8boULmk=.f00652da-b019-4343-b58d-813151c4dbcf@github.com>
Message-ID: <o-e-Wy_6TqfeikVpshBACvAwbYZnRogMjPYxRKsU7x8=.8959ff34-b335-47ae-ac3a-b40f15eb9f9c@github.com>

On Fri, 17 Jan 2025 18:46:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this patch that removes the SIZE_FORMAT macros and the remaining uses I missed in metaspace and the gtests.
> Tested with tier1-4, and cross-compiled other platforms (except they fail for other reasons).

This pull request has now been integrated.

Changeset: 4a9fba61
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a9fba615da0dfa6646ecb9fd9d929f74fe6875e
Stats:     65 lines in 25 files changed: 2 ins; 8 del; 55 mod

8347990: Remove SIZE_FORMAT macros and replace remaining uses

Reviewed-by: dholmes, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/23180

From aph at openjdk.org  Tue Jan 21 13:33:48 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 21 Jan 2025 13:33:48 GMT
Subject: RFR: 8330008: [s390x] Test bit "in-memory" in case of
 DiagnoseSyncOnValueBasedClasses [v2]
In-Reply-To: <0kp8UR95O3_KwxqbD7vYBIx0jh38fwb8erA6Mb12wp0=.ff52bc8f-25c5-4c93-9978-a31fdd8acb88@github.com>
References: <ScqavxAaWh9ZpLVAD2pVSTg3j72NQF4kquGE0Q_RSvU=.1bc6b6bc-f09f-4ce5-ac77-337531f588c5@github.com>
 <0kp8UR95O3_KwxqbD7vYBIx0jh38fwb8erA6Mb12wp0=.ff52bc8f-25c5-4c93-9978-a31fdd8acb88@github.com>
Message-ID: <iqzSxNtNQidRIhaUESYHX-wTXkSHhUkHJhS9kMjCQCM=.74cf3004-d9e3-4cc2-a4dc-5e5446095a9a@github.com>

On Fri, 19 Apr 2024 14:02:21 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> It's trivial update to use `testbit` method to test the bit "in-memory"
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates comment in sharedRuntime_s390.cpp file

> > Should I integrate this one ?
> 
> Go! The observed crash is obviously unrelated to your change.

It's not a crash, it's a diagnostic for synchronizing on a value-based class, as requested. Given that the test case actually is synchronizing on a value-based class, this is a correct diagnostic message.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18709#issuecomment-2604745435

From erikj at openjdk.org  Tue Jan 21 14:03:36 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 21 Jan 2025 14:03:36 GMT
Subject: RFR: 8348182: Remove DONT_USE_PRECOMPILED_HEADER
In-Reply-To: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
References: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
Message-ID: <UniSEAXzzR6omeaTSROMG2JqE3cOZSKlPYjgSAfYGhg=.e6106de4-8cf4-451e-b1a1-60cb0bb35626@github.com>

On Tue, 21 Jan 2025 12:41:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Before [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we had to remove the include lines in precompiled.hpp when precompiled headers were turned off. This was done by defining DONT_USE_PRECOMPILED_HEADER.
> 
> After [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we simply don't include precompiled.hpp if precompiled headers are turn off and therefore we don't need to removed the include lines.
> 
> I propose that we get rid of DONT_USE_PRECOMPILED_HEADER.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23211#pullrequestreview-2564721991

From rrich at openjdk.org  Tue Jan 21 14:35:38 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Jan 2025 14:35:38 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <xJ6McgRAGAME1e7jGmE-Rg3-hzkqTKraxAh5-vgSPz4=.be7dd78d-8902-4fb3-9199-cd915fee645f@github.com>

On Wed, 25 Dec 2024 15:40:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp line 607:

> 605:                        super_klass = R4,
> 606:                        temp1_reg = R6;
> 607:         __ check_klass_subtype_slow_path(sub_klass, super_klass, temp1_reg, noreg); // may return with CR0.eq if successful

The comment is unclear to me. Where is the result of the subtype check? Can it also return with CR0.ne if successful?
I noticed you added the `crandc` to `check_klass_subtype_slow_path_linear()` but if we reach there calling from this location then the `crandc` is not emitted because `L_success == nullptr`. Is this ok?
I'd appreciate comments on the masm methods explaining how the result of the subtype check is conveyed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1923838785

From stuefe at openjdk.org  Tue Jan 21 14:48:41 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 21 Jan 2025 14:48:41 GMT
Subject: RFR: 8348029: Make gtest death tests work with real crash signals
In-Reply-To: <LBnNsGRaASJvyJpZeMiPCio1hnGj_A_QEocGHqsEmUo=.2445052d-71b6-4c94-b998-44f0b6bca565@github.com>
References: <3Ff8PvDpBAlZgaib29g7jHf6lBzKqIyhP766MH0GWjA=.498e7384-720e-426c-89db-18f874656256@github.com>
 <LBnNsGRaASJvyJpZeMiPCio1hnGj_A_QEocGHqsEmUo=.2445052d-71b6-4c94-b998-44f0b6bca565@github.com>
Message-ID: <2hJ-eXuuwnPEiMbdKHkfR2_UKZFsDCt55Var7n8JDzc=.120cefd9-be31-41da-940d-1b305affe89a@github.com>

On Tue, 21 Jan 2025 08:11:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Small change adds a new macro to the gtest TEST macro zoo: `TEST_VM_CRASH_SIGNAL`. This one is a companion to `TEST_VM_FATAL_ERROR_MSG` and `TEST_VM_ASSERT_MSG` and allows to write gtest that test expected crashes to happen. I will need that for a regression test for https://bugs.openjdk.org/browse/JDK-8330174 , among other things.
>> 
>> You use it like this:
>> 
>> 
>> TEST_VM_CRASH_SIGNAL(Testtest, test, "SIGSEGV") {
>>   ... do something that you expect should result in a specific crash ...
>> }
>> 
>> Note that the string provided is platform dependent (signal names on Posix, SEH names on Windows).
>
> Marked as reviewed by mbaesken (Reviewer).

Thanks @MBaesken and @SoniaZaldana

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23191#issuecomment-2604932638

From stuefe at openjdk.org  Tue Jan 21 14:48:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 21 Jan 2025 14:48:43 GMT
Subject: Integrated: 8348029: Make gtest death tests work with real crash
 signals
In-Reply-To: <3Ff8PvDpBAlZgaib29g7jHf6lBzKqIyhP766MH0GWjA=.498e7384-720e-426c-89db-18f874656256@github.com>
References: <3Ff8PvDpBAlZgaib29g7jHf6lBzKqIyhP766MH0GWjA=.498e7384-720e-426c-89db-18f874656256@github.com>
Message-ID: <JNlL9XNhnrJvlUj55F4Z80tXc5kyu9lv-QU4D8JFclo=.f5bb4d3b-cee5-4ee8-a62f-11562fbe8011@github.com>

On Sat, 18 Jan 2025 17:05:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Small change adds a new macro to the gtest TEST macro zoo: `TEST_VM_CRASH_SIGNAL`. This one is a companion to `TEST_VM_FATAL_ERROR_MSG` and `TEST_VM_ASSERT_MSG` and allows to write gtest that test expected crashes to happen. I will need that for a regression test for https://bugs.openjdk.org/browse/JDK-8330174 , among other things.
> 
> You use it like this:
> 
> 
> TEST_VM_CRASH_SIGNAL(Testtest, test, "SIGSEGV") {
>   ... do something that you expect should result in a specific crash ...
> }
> 
> Note that the string provided is platform dependent (signal names on Posix, SEH names on Windows).

This pull request has now been integrated.

Changeset: 48c75976
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48c75976b13d891b30ba936ea27fa1f034fd5356
Stats:     26 lines in 2 files changed: 24 ins; 0 del; 2 mod

8348029: Make gtest death tests work with real crash signals

Reviewed-by: mbaesken, szaldana

-------------

PR: https://git.openjdk.org/jdk/pull/23191

From shade at openjdk.org  Tue Jan 21 15:06:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 21 Jan 2025 15:06:41 GMT
Subject: RFR: 8348182: Remove DONT_USE_PRECOMPILED_HEADER
In-Reply-To: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
References: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
Message-ID: <U1Dbc3ydGNpjZ_eagg5b5shwn_JwYZ0K_X-T58I3lfc=.a1023225-a89e-4faf-8e59-4e374f869a8a@github.com>

On Tue, 21 Jan 2025 12:41:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Before [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we had to remove the include lines in precompiled.hpp when precompiled headers were turned off. This was done by defining DONT_USE_PRECOMPILED_HEADER.
> 
> After [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we simply don't include precompiled.hpp if precompiled headers are turned off and therefore we don't need to removed the include lines.
> 
> I propose that we get rid of DONT_USE_PRECOMPILED_HEADER.

I can see more `DONT_USE_PRECOMPILED_HEADER` uses in `test/hotspot/gtest`, take a look at those?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23211#pullrequestreview-2564906400

From shade at openjdk.org  Tue Jan 21 15:11:37 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 21 Jan 2025 15:11:37 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide
In-Reply-To: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
Message-ID: <EIoK95xMATbpvNRSU_kxmXs-A27Lw3QdjKQFziBQHO0=.d39ad7f1-bda4-4c8e-8bec-6dada0bacc35@github.com>

On Tue, 21 Jan 2025 12:29:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need for HotSpot devs to include the precompiled.hpp. This is the PR to reflect that.
> 
> I know that there is some process around updating the style guide, but I can't find it, so I'm starting with a plain PR.

This part looks dangling now:


 * precompiled.hpp is just a build time optimization, so don't rely on
it to resolve include problems.


Maybe move the line at the end of the list and phrase it as:

"* Consider adding the frequently used header includes to precompiled.hpp. This can improve build times, but the improvement needs to be validated. precompiled.hpp is just a build time optimization, so don't rely on it to resolve include problems."

-------------

PR Review: https://git.openjdk.org/jdk/pull/23210#pullrequestreview-2564920258

From shade at openjdk.org  Tue Jan 21 15:13:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 21 Jan 2025 15:13:36 GMT
Subject: RFR: 8348117: The two-argument overload of
 SignatureHandlerLibrary::add is not used
In-Reply-To: <vW88xKa_FXz0vVgGDhxMTVLTLu_MgkFbcGhf2xcSKJs=.a7692e6c-ac3c-4035-ac7e-141952c7a457@github.com>
References: <vW88xKa_FXz0vVgGDhxMTVLTLu_MgkFbcGhf2xcSKJs=.a7692e6c-ac3c-4035-ac7e-141952c7a457@github.com>
Message-ID: <zFGdP5cufFioZoR0hT-vQfgEx-90XT3_BhLP3E8lbsU=.85498e1d-05ce-4ceb-9363-de5561b51a01@github.com>

On Tue, 21 Jan 2025 08:44:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The  `SignatureHandlerLibrary::add` two-arg API was added to support closed code under [JDK-8087333](https://bugs.openjdk.org/browse/JDK-8087333) in JDK 9. That closed code was removed again, still in JDK 9, as part of JEP 297 ([JDK-8168503](https://bugs.openjdk.org/browse/JDK-8168503)) which unified the closed and open ARM ports - leaving the API unused.
> 
> There were other leftovers from the same set of changes so they are cleaned up as well - nothing significant, just unnecessary friend declarations, comments, and one other method.
> 
> Testing:
>  - all builds in tiers 1-5
> 
> Thanks.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23207#pullrequestreview-2564926201

From stefank at openjdk.org  Tue Jan 21 15:51:35 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jan 2025 15:51:35 GMT
Subject: RFR: 8348182: Remove DONT_USE_PRECOMPILED_HEADER
In-Reply-To: <U1Dbc3ydGNpjZ_eagg5b5shwn_JwYZ0K_X-T58I3lfc=.a1023225-a89e-4faf-8e59-4e374f869a8a@github.com>
References: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
 <U1Dbc3ydGNpjZ_eagg5b5shwn_JwYZ0K_X-T58I3lfc=.a1023225-a89e-4faf-8e59-4e374f869a8a@github.com>
Message-ID: <L07YlEJ9p2-Qw87ta1fw7zcLGu6Qv9K6bqsFXrELPDo=.eb789452-1204-4988-86eb-a589eedf203b@github.com>

On Tue, 21 Jan 2025 15:03:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I can see more `DONT_USE_PRECOMPILED_HEADER` uses in `test/hotspot/gtest`, take a look at those?

There shouldn't be. Are you looking at the latest sources? I removed some of those in an earlier PR today.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23211#issuecomment-2605098209

From shade at openjdk.org  Tue Jan 21 15:54:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 21 Jan 2025 15:54:08 GMT
Subject: RFR: 8348195: More u2 conversion warnings after JDK-8347147
Message-ID: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>

After [JDK-8347147](https://bugs.openjdk.org/browse/JDK-8347147), SonarCloud reports a few risky conversions from int to u2. It would be good to cover them with either checked_cast or changing the underlying type.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/23217/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23217&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348195
  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23217.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23217/head:pull/23217

PR: https://git.openjdk.org/jdk/pull/23217

From stefank at openjdk.org  Tue Jan 21 15:56:36 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jan 2025 15:56:36 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide
In-Reply-To: <EIoK95xMATbpvNRSU_kxmXs-A27Lw3QdjKQFziBQHO0=.d39ad7f1-bda4-4c8e-8bec-6dada0bacc35@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
 <EIoK95xMATbpvNRSU_kxmXs-A27Lw3QdjKQFziBQHO0=.d39ad7f1-bda4-4c8e-8bec-6dada0bacc35@github.com>
Message-ID: <uo5b6DMBqZSCB4cSAljKq0Hz5DYStw3OLdD8guQMWVg=.1d729085-640f-420a-a190-250209075230@github.com>

On Tue, 21 Jan 2025 15:08:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This part looks dangling now:
> 
> ```
>  * precompiled.hpp is just a build time optimization, so don't rely on
> it to resolve include problems.
> ```
> 
> Maybe move the line at the end of the list and phrase it as:
> 
> "* Consider adding the frequently used header includes to precompiled.hpp. This can improve build times, but the improvement needs to be validated. precompiled.hpp is just a build time optimization, so don't rely on it to resolve include problems."

Right. I thought that the statement was still valid but I agree that it can be odd without more context. I'm don't want to encourage people to add stuff to the precompiled.hpp. Maybe something like this:

* Some build configurations uses precompiled headers to speed up the build times. The compiled headers are included in the precompiled.hpp file. Note that precompiled.hpp is just a build time optimization, so don't rely on it to resolve include problems.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23210#issuecomment-2605111660

From shade at openjdk.org  Tue Jan 21 16:03:37 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 21 Jan 2025 16:03:37 GMT
Subject: RFR: 8348182: Remove DONT_USE_PRECOMPILED_HEADER
In-Reply-To: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
References: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
Message-ID: <tkDu0zIKvRlgPQ0zJxI5-BIYzcT4Y-S-ruF3j2yFmTQ=.ef3ba1bd-2584-49ce-8030-48d4d12e2881@github.com>

On Tue, 21 Jan 2025 12:41:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Before [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we had to remove the include lines in precompiled.hpp when precompiled headers were turned off. This was done by defining DONT_USE_PRECOMPILED_HEADER.
> 
> After [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we simply don't include precompiled.hpp if precompiled headers are turned off and therefore we don't need to removed the include lines.
> 
> I propose that we get rid of DONT_USE_PRECOMPILED_HEADER.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23211#pullrequestreview-2565071774

From shade at openjdk.org  Tue Jan 21 16:03:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 21 Jan 2025 16:03:38 GMT
Subject: RFR: 8348182: Remove DONT_USE_PRECOMPILED_HEADER
In-Reply-To: <L07YlEJ9p2-Qw87ta1fw7zcLGu6Qv9K6bqsFXrELPDo=.eb789452-1204-4988-86eb-a589eedf203b@github.com>
References: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
 <U1Dbc3ydGNpjZ_eagg5b5shwn_JwYZ0K_X-T58I3lfc=.a1023225-a89e-4faf-8e59-4e374f869a8a@github.com>
 <L07YlEJ9p2-Qw87ta1fw7zcLGu6Qv9K6bqsFXrELPDo=.eb789452-1204-4988-86eb-a589eedf203b@github.com>
Message-ID: <aBuKYj5kY1Gufe_wbGa16h2rw18aFv9dNi_eeJ7qJP0=.cb9318f7-7b63-41f9-9763-f37422c8e279@github.com>

On Tue, 21 Jan 2025 15:49:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > I can see more `DONT_USE_PRECOMPILED_HEADER` uses in `test/hotspot/gtest`, take a look at those?
> 
> There shouldn't be. Are you looking at the latest sources? I removed some of those in an earlier PR today.

Ah. Yes, I was looking at older repo. Looks fine then!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23211#issuecomment-2605128529

From rriggs at openjdk.org  Tue Jan 21 16:36:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 21 Jan 2025 16:36:38 GMT
Subject: RFR: 8338428: Add logging of final VM flags while setting
 properties [v6]
In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
Message-ID: <DqNZoC-w61wk92gs2TNbvtlZjpqtjR8K3tqJZDPJyRk=.e3717304-fbb3-4e8d-a4fb-9962bb3f6bb1@github.com>

On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated flags

lgtm

Got it, I've resolved my mis-understanding of the properties being changed to the narrow use of invoking the initial VMProps to determine the supported properties of the VM under test.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23054#pullrequestreview-2565158818
PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2605213324

From coleenp at openjdk.org  Tue Jan 21 16:59:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jan 2025 16:59:42 GMT
Subject: RFR: 8348195: More u2 conversion warnings after JDK-8347147
In-Reply-To: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>
References: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>
Message-ID: <R2uKRFkICsvQWjyFiFe7wHEWBBWTRYjggqnDaSBxhKo=.f46e3170-d653-4b57-b17a-4ce7f4bf613f@github.com>

On Tue, 21 Jan 2025 15:49:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8347147](https://bugs.openjdk.org/browse/JDK-8347147), SonarCloud reports a few risky conversions from int to u2. It would be good to cover them with either checked_cast or changing the underlying type.

This looks good. Thank you for fixing this and I'm glad it's not worse. I've been a bit afraid to try -Wconversion again on these files.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23217#pullrequestreview-2565216047

From shade at openjdk.org  Tue Jan 21 17:01:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 21 Jan 2025 17:01:52 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide
In-Reply-To: <uo5b6DMBqZSCB4cSAljKq0Hz5DYStw3OLdD8guQMWVg=.1d729085-640f-420a-a190-250209075230@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
 <EIoK95xMATbpvNRSU_kxmXs-A27Lw3QdjKQFziBQHO0=.d39ad7f1-bda4-4c8e-8bec-6dada0bacc35@github.com>
 <uo5b6DMBqZSCB4cSAljKq0Hz5DYStw3OLdD8guQMWVg=.1d729085-640f-420a-a190-250209075230@github.com>
Message-ID: <tc7zeTDuegNHpBOpXIhgnQ9bwwAocU_N405on38Yb6I=.89fab1d5-a34b-421e-8408-42d307e38973@github.com>

On Tue, 21 Jan 2025 15:54:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Maybe something like this:
> 
>     * Some build configurations uses precompiled headers to speed up the build times. The compiled headers are included in the precompiled.hpp file. Note that precompiled.hpp is just a build time optimization, so don't rely on it to resolve include problems.

This works for me, thanks! Nit: "uses" -> "use".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23210#issuecomment-2605268938

From mdoerr at openjdk.org  Tue Jan 21 17:22:42 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 21 Jan 2025 17:22:42 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <xJ6McgRAGAME1e7jGmE-Rg3-hzkqTKraxAh5-vgSPz4=.be7dd78d-8902-4fb3-9199-cd915fee645f@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <xJ6McgRAGAME1e7jGmE-Rg3-hzkqTKraxAh5-vgSPz4=.be7dd78d-8902-4fb3-9199-cd915fee645f@github.com>
Message-ID: <pAErLf6MXbz_0xFLKjf3IfzGaRJ1U1k6rf3duhELl_o=.1769911b-aea0-4049-85b9-0b86cbe7ca91@github.com>

On Tue, 21 Jan 2025 14:33:15 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
>> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
>> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
>> 
>> Performance difference can be observed when C2 is disabled (measured on Power10):
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
>> 
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
>> 
>> 
>> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).
>
> src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp line 607:
> 
>> 605:                        super_klass = R4,
>> 606:                        temp1_reg = R6;
>> 607:         __ check_klass_subtype_slow_path(sub_klass, super_klass, temp1_reg, noreg); // may return with CR0.eq if successful
> 
> The comment is unclear to me. Where is the result of the subtype check? Can it also return with CR0.ne if successful?
> I noticed you added the `crandc` to `check_klass_subtype_slow_path_linear()` but if we reach there calling from this location then the `crandc` is not emitted because `L_success == nullptr`. Is this ok?
> I'd appreciate comments on the masm methods explaining how the result of the subtype check is conveyed.

The correct result is always in CR0 with this PR.
"return" means "blr", here. That can optionally be used in case of success. In this case, CR0 is always "eq".
I've moved the `crandc` instruction into `check_klass_subtype_slow_path_linear` which contains such a "blr" for a success case. This way, the linear version works exactly as before.
The new code `check_klass_subtype_slow_path_table` doesn't use "blr". That's why I added "may" to the comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1924113575

From dlong at openjdk.org  Tue Jan 21 17:44:37 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 21 Jan 2025 17:44:37 GMT
Subject: [jdk24] RFR: 8343978: Update the default value of
 CodeEntryAlignment for Ampere-1A and 1B
In-Reply-To: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
References: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
Message-ID: <F7knmyCED6KI1Tx1Ka6V7_dZ5Get80JWVLwhlifuQZE=.47606c38-25fe-4d0b-b8b4-4ed311691f8f@github.com>

On Fri, 10 Jan 2025 07:42:33 GMT, Liming Liu <lliu at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 89ee1a55 from the openjdk/jdk repository.
> 
> The commit being backported was authored by Liming Liu on 9 Jan 2025 and was reviewed by Dean Long and Vladimir Kozlov.
> 
> Thanks!

Marked as reviewed by dlong (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23027#pullrequestreview-2565320148

From dlong at openjdk.org  Tue Jan 21 17:51:37 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 21 Jan 2025 17:51:37 GMT
Subject: [jdk24] RFR: 8343978: Update the default value of
 CodeEntryAlignment for Ampere-1A and 1B
In-Reply-To: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
References: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
Message-ID: <1bW5YUw21IsnOwoQSKsNGfActZ4sOt_26gpVf4su90M=.3b24f705-c664-40c0-898d-bad4de470921@github.com>

On Fri, 10 Jan 2025 07:42:33 GMT, Liming Liu <lliu at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 89ee1a55 from the openjdk/jdk repository.
> 
> The commit being backported was authored by Liming Liu on 9 Jan 2025 and was reviewed by Dean Long and Vladimir Kozlov.
> 
> Thanks!

Are we allowed to push a P4 RFE during Rampdown Phase Two, even if it is a backport?

-------------

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23027#pullrequestreview-2565335121

From wkemper at openjdk.org  Tue Jan 21 18:38:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 18:38:50 GMT
Subject: Integrated: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <w52MQ3D9h1dDH78nZbCGLtxNRPvyPdqKH8sIkf33L_Q=.d4309bf1-4934-4465-a976-70f904f968fb@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.
> 
> ## Testing
> 
> Shenandoh's jtreg test: `gc/shenandoah/TestJcmdHeapDump.java` simply takes a heap dump of itself. Before this change I observed a failure rate of approximately 1/6000 executions. The assertion is violated when the VM thread attempts to run a collection which is not coordinated by Shenandoah's control thread. This specific assertion happens because the default implementation of `collect_as_vm_thread` modifies the `_gc_cause` field in ways that Shenandoah does not expect. Without this assertion, one can only imagine the chaos that would ensue.

This pull request has now been integrated.

Changeset: 6a29a811
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a29a8110ec38b4adc8163ba8651cbc935353f1d
Stats:     23 lines in 4 files changed: 15 ins; 1 del; 7 mod

8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/23186

From wkemper at openjdk.org  Tue Jan 21 18:52:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 18:52:48 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
Message-ID: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>

This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

-------------

Commit messages:
 - Backport 6a29a8110ec38b4adc8163ba8651cbc935353f1d

Changes: https://git.openjdk.org/jdk/pull/23221/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23221&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345750
  Stats: 23 lines in 4 files changed: 15 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23221.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23221/head:pull/23221

PR: https://git.openjdk.org/jdk/pull/23221

From gziemski at openjdk.org  Tue Jan 21 20:10:42 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 21 Jan 2025 20:10:42 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v14]
In-Reply-To: <7uETGf-b8UH8j4OEow-u89ec_08pC-HEvtisfPJr258=.9aac817c-f33c-4619-9b76-069d9219367d@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <7uETGf-b8UH8j4OEow-u89ec_08pC-HEvtisfPJr258=.9aac817c-f33c-4619-9b76-069d9219367d@github.com>
Message-ID: <QGwPIb_lqE8ME2QIAHBBii4lmQdNsSOzFQES2pFYQFc=.a16bf73b-1539-43db-a5fb-1b7fb184ce62@github.com>

On Mon, 20 Jan 2025 15:03:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   const functions

Nitpick: everywhere else in our code we refer to the tag parameter as `mem_tag`, not `mt`. I'm not 100% sure whether this needs to be pointed out, but I think I'd prefer if we remained consistent and used `mem_tag`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2565595412

From gziemski at openjdk.org  Tue Jan 21 20:15:41 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 21 Jan 2025 20:15:41 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v14]
In-Reply-To: <7uETGf-b8UH8j4OEow-u89ec_08pC-HEvtisfPJr258=.9aac817c-f33c-4619-9b76-069d9219367d@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <7uETGf-b8UH8j4OEow-u89ec_08pC-HEvtisfPJr258=.9aac817c-f33c-4619-9b76-069d9219367d@github.com>
Message-ID: <PH9gkD1VFyR-24gDYZSEl3V7OuD7gItLu5dEz8sQoM4=.a34d8e59-e395-49c7-b41f-99036a01b6cc@github.com>

On Mon, 20 Jan 2025 15:03:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   const functions

I remember Lois asked, during your presentation at the staff meeting, how to change our existing code to start using your RBTree and your answer was a single line change. Could you please remind me what that line was? I'd like to benchmark the new RBTree using my NMT benchmark to see whether there is any performance difference from Treap.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2605644275

From dholmes at openjdk.org  Tue Jan 21 21:07:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Jan 2025 21:07:38 GMT
Subject: RFR: 8338428: Add logging of final VM flags while setting
 properties [v6]
In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
 <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com>
Message-ID: <aRL6arKuvSCugmiJS6SWipMS4GJR7ptFZtXPim7Dzjw=.2962ac3f-6cba-4f61-820e-ec72b804e724@github.com>

On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
>> 
>> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
>> 
>> Update:
>> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated flags

Still good.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23054#pullrequestreview-2565690364

From lmesnik at openjdk.org  Tue Jan 21 21:13:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 21 Jan 2025 21:13:41 GMT
Subject: Integrated: 8338428: Add logging of final VM flags while setting
 properties
In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com>
Message-ID: <GQhEg95KpTEzI13QI4EB9v4JrMUDw1PJiqTH-1XmQZI=.fc32c3f2-fd7b-4823-91b2-f54136fa7861@github.com>

On Sun, 12 Jan 2025 06:08:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures.
> 
> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal".
> 
> Update:
> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them.

This pull request has now been integrated.

Changeset: bbd88077
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bbd880775f73ac11dc2c86ec5b598bdb4305e699
Stats:     14 lines in 2 files changed: 10 ins; 0 del; 4 mod

8338428: Add logging of final VM flags while setting properties

Reviewed-by: dholmes, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/23054

From coleenp at openjdk.org  Tue Jan 21 21:24:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jan 2025 21:24:10 GMT
Subject: RFR: 8337458: Remove debugging code print_cpool_bytes
Message-ID: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>

Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
Tested with tier1 locally.

-------------

Commit messages:
 - 8337458: Remove debugging code print_cpool_bytes

Changes: https://git.openjdk.org/jdk/pull/23222/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23222&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337458
  Stats: 153 lines in 1 file changed: 0 ins; 153 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23222/head:pull/23222

PR: https://git.openjdk.org/jdk/pull/23222

From dholmes at openjdk.org  Tue Jan 21 21:49:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Jan 2025 21:49:38 GMT
Subject: RFR: 8348117: The two-argument overload of
 SignatureHandlerLibrary::add is not used
In-Reply-To: <FpV9n5RaLCCaqQ05YxURkv3s6Bz53z5lVzLRsLzO7iQ=.ea859db9-7b50-4bac-a6bd-741e64b8051e@github.com>
References: <vW88xKa_FXz0vVgGDhxMTVLTLu_MgkFbcGhf2xcSKJs=.a7692e6c-ac3c-4035-ac7e-141952c7a457@github.com>
 <FpV9n5RaLCCaqQ05YxURkv3s6Bz53z5lVzLRsLzO7iQ=.ea859db9-7b50-4bac-a6bd-741e64b8051e@github.com>
Message-ID: <vuHDxVPNxv6X-1Ep-3_NdTo7ELCZ5zUIl0GO8MZiWEg=.01203d4e-b923-44e0-b1fd-36ca2abdb576@github.com>

On Tue, 21 Jan 2025 12:22:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The  `SignatureHandlerLibrary::add` two-arg API was added to support closed code under [JDK-8087333](https://bugs.openjdk.org/browse/JDK-8087333) in JDK 9. That closed code was removed again, still in JDK 9, as part of JEP 297 ([JDK-8168503](https://bugs.openjdk.org/browse/JDK-8168503)) which unified the closed and open ARM ports - leaving the API unused.
>> 
>> There were other leftovers from the same set of changes so they are cleaned up as well - nothing significant, just unnecessary friend declarations, comments, and one other method.
>> 
>> Testing:
>>  - all builds in tiers 1-5
>> 
>> Thanks.
>
> Looks good!

Thanks for the reviews @coleenp and @shipilev !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23207#issuecomment-2605805194

From karianna at openjdk.org  Tue Jan 21 22:18:42 2025
From: karianna at openjdk.org (Martijn Verburg)
Date: Tue, 21 Jan 2025 22:18:42 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v15]
In-Reply-To: <cwusoKYlA-PQJKzcr5qF09YpVfTfNPI9GHu08jTyGCY=.00023f5f-b115-427a-9862-fe0a77a84388@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <V6_HK5nJ3toWNn4G3tC0vbnuGSh-3H9GvJmbsNNcW58=.fc7dc3ce-dd04-4e2f-8750-f17e00864764@github.com>
 <cwusoKYlA-PQJKzcr5qF09YpVfTfNPI9GHu08jTyGCY=.00023f5f-b115-427a-9862-fe0a77a84388@github.com>
Message-ID: <Yx6dJdhw-O5pVIgMNIfARW60sbBOks_5X2mA02qnPls=.af856f53-6fd3-4217-840c-7061782b8765@github.com>

On Tue, 7 Jan 2025 09:31:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into hotspot
>>  - _WINDOWS && AARCH64 in sharedRuntime.hpp
>>  - AARCH64 in sharedRuntimeRem.cpp
>>  - Refactor sharedRuntime.cpp
>>  - CAST_FROM_FN_PTR in os_windows.cpp
>>  - Merge branch 'openjdk:master' into hotspot
>>  - fmod_winarm64 in sharedRuntime.cpp
>>  - fmod_winarm64 in sharedRuntimeRem.cpp
>>  - fmod_winarm64 in sharedRuntime.hpp
>>  - Typo in sharedRuntimeRem.cpp
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/8d56007c...ff1c4664
>
> Keep open please

@TheShermanTanker - Are you needing further reviews?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2605851336

From ysr at openjdk.org  Tue Jan 21 22:45:37 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 21 Jan 2025 22:45:37 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <G4TSKokMyIFKnDnZlYitEgSNHtuRhoZfynStRztcDIk=.dbe42d6a-0b0d-4ae3-b267-9ca3c8d1a53b@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

?

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23221#pullrequestreview-2565838091

From wkemper at openjdk.org  Tue Jan 21 23:12:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 23:12:40 GMT
Subject: [jdk24] Integrated: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <TGmKVQYKJrZ4FVBdpfAWh0MXoKYvucAKm3jYRSqZUXs=.4d77266b-d2a3-4254-94b0-5e3cfdee9439@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

This pull request has now been integrated.

Changeset: febcfd69
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/febcfd69ffe88e8a9d3cdf267bc062816577f868
Stats:     23 lines in 4 files changed: 15 ins; 1 del; 7 mod

8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause

Reviewed-by: ysr
Backport-of: 6a29a8110ec38b4adc8163ba8651cbc935353f1d

-------------

PR: https://git.openjdk.org/jdk/pull/23221

From ysr at openjdk.org  Tue Jan 21 23:28:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 21 Jan 2025 23:28:35 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
Message-ID: <tI-a6z8mlKxmghtBp4SW71IC_DZbd9P6QvhEzUNZTuY=.80947a0d-95e9-4463-8e27-3dc21d87a370@github.com>

On Fri, 17 Jan 2025 21:16:00 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 228:
> 
>> 226: // This avoids the need to synchronize reads of the table by the GC workers doing
>> 227: // remset scanning, on the one hand, with the dirtying of the table by mutators
>> 228: // and by the GC workers doing remset scans, on the other.
> 
> Remove "and by the the GC workers doing remset scans" from this comment, so it reads:
> "This avoids the need to synchronize reads of the table by the GC workers doing
> remset scanning, on the one hand, with the dirtying of the table by mutators on the other.

@kdnilsen , when are the existing intergenerational pointers (represented by (a subset of) the dirty cards in the read table) transferred to the write table?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1924486803

From gziemski at openjdk.org  Wed Jan 22 00:05:54 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 22 Jan 2025 00:05:54 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v5]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <99jk1essfBOphasdm4w-77ttim0GX9ELjEI8-tEgKIY=.3aefa557-f144-439f-a070-e6d639f9af63@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
> 
> VM interacts with these through these APIs:
> 
>   ```
>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>   NMT_LogRecorder::logThreadName(name);
>   NMT_LogRecorder::finish();
> 
> 
> For controlling their liveness and through their "log" APIs for the actual logging.
> 
> For memory logger those are:
> 
> 
>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
> 
> 
> and for virtual memory logger, those are:
> 
> 
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
> 
> 
> That's the entirety of the surface area of the new code.
> 
> The actual implementation extends one existing VM API:
> 
> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
> `
> 
> and adds a few APIs to permit_forbidden_function.hpp:
> 
> 
>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
> 
>  #if defined(LINUX)
>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>  #elif defined(WINDOWS)
>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>  #elif defined(__APPLE__)
>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>  #endif
> 
> 
> Those are need if we want to calculate the memory overhead
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/...

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  push the calculation of overhead into native summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/6c8c054f..bf22bd7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=03-04

  Stats: 71 lines in 2 files changed: 40 ins; 14 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From dholmes at openjdk.org  Wed Jan 22 00:17:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 00:17:38 GMT
Subject: RFR: 8348195: More u2 conversion warnings after JDK-8347147
In-Reply-To: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>
References: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>
Message-ID: <Xv7O69QHEftLSzWv4VTV7pFhZRPRii2MUX6p13bBUFc=.20f72e34-c7f0-4b25-9300-6f597391b692@github.com>

On Tue, 21 Jan 2025 15:49:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8347147](https://bugs.openjdk.org/browse/JDK-8347147), SonarCloud reports a few risky conversions from int to u2. It would be good to cover them with either checked_cast or changing the underlying type.

Looks good.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23217#pullrequestreview-2565934701

From cslucas at openjdk.org  Wed Jan 22 01:53:38 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 22 Jan 2025 01:53:38 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
Message-ID: <aQPrGOirvNOjdAwZsSGMxaiwnicOdaH1xNkjYsjhdgU=.354f17d5-df27-4165-a896-34583a6550d7@github.com>

On Fri, 17 Jan 2025 21:19:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 121:
> 
>> 119:   CardValue* bp = &(read_table)[0];
>> 120:   CardValue* end_bp = &(read_table)[_card_table->last_valid_index()];
>> 121: 
> 
> Looks like there may be an off-by-one error here, or a bad name for "last_valid_index()".  The following loop should continue while bp <= end_bp.

Good catch, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1924583163

From cslucas at openjdk.org  Wed Jan 22 01:53:37 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 22 Jan 2025 01:53:37 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <Xo6j7jhnwGy6HmYI8cCz8ZwzrELhpkINTIxZi2dDB8E=.364b3488-d140-4183-876b-763fabe4498e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <Xo6j7jhnwGy6HmYI8cCz8ZwzrELhpkINTIxZi2dDB8E=.364b3488-d140-4183-876b-763fabe4498e@github.com>
Message-ID: <jjpV9jJCY6UUY_hf-UFwDu3hh6Ug8qg_kSKvganUFMQ=.377c98a6-a202-4509-9142-2f98977bf006@github.com>

On Fri, 17 Jan 2025 23:35:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp line 44:
> 
>> 42: #define BIND(label) bind(label); BLOCK_COMMENT(#label ":")
>> 43: 
>> 44: void CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators,
> 
> Is it necessary to modify the `cardTableBarrierSetAssembler*` classes? I believe Shenandoah just uses the `shenandoahBarrierSetAssembler*` classes.

Of course you're right! I'm reverting this change. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1924583691

From lliu at openjdk.org  Wed Jan 22 03:11:37 2025
From: lliu at openjdk.org (Liming Liu)
Date: Wed, 22 Jan 2025 03:11:37 GMT
Subject: [jdk24] RFR: 8343978: Update the default value of
 CodeEntryAlignment for Ampere-1A and 1B
In-Reply-To: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
References: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
Message-ID: <Q2DyEyVRb9J2_izU0NignmRL5HuB8IPRh3xO9o99yVw=.30ea154e-ddf3-4125-8dd8-88c381e31ea0@github.com>

On Fri, 10 Jan 2025 07:42:33 GMT, Liming Liu <lliu at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 89ee1a55 from the openjdk/jdk repository.
> 
> The commit being backported was authored by Liming Liu on 9 Jan 2025 and was reviewed by Dean Long and Vladimir Kozlov.
> 
> Thanks!

Hi @dean-long, I think it is allowed according to the following page:
https://openjdk.org/jeps/3#rdp-2

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23027#issuecomment-2606191450

From fyang at openjdk.org  Wed Jan 22 03:33:37 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 22 Jan 2025 03:33:37 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <2qE27an84fZ1Z8t4iXvd70KZOrh6ZZpRVO4_ybOmQ7U=.170e34bd-a38d-4296-afd6-31c3c3cce99f@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <jit0wEWz-BVEVN1-x2Rlf9vldHLzrXRqcYzqZcCkZuU=.970de563-05c7-41ca-836e-bb6c097a741a@github.com>
 <BmxErHoAoZgIZPFWkoJTi1pSZ2jqCLukHo7Qo6-fd8M=.341eb67f-9936-4cdf-b05d-1f3c5711d997@github.com>
 <2qE27an84fZ1Z8t4iXvd70KZOrh6ZZpRVO4_ybOmQ7U=.170e34bd-a38d-4296-afd6-31c3c3cce99f@github.com>
Message-ID: <PH4PCBn-3-mR0VUnJ9Kj2S7EptUklc9YE6qQtmJFVN0=.6cef26f7-4bb7-45ad-9855-5c8aa6700dde@github.com>

On Tue, 21 Jan 2025 08:25:25 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/globals_riscv.hpp line 106:
>> 
>>> 104:   product(bool, UseZbb, false, DIAGNOSTIC, "Use Zbb instructions")               \
>>> 105:   product(bool, UseZbs, false, DIAGNOSTIC, "Use Zbs instructions")               \
>>> 106:   product(bool, UseZfa, false, DIAGNOSTIC, "Use Zfa instructions")               \
>> 
>> Is there any hardware available for testing?
>
> I don't have such hardware anyways. Make exprimental?

Yeah, I would suggest make it experimental without the hardware. That's what we always do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1924644333

From iklam at openjdk.org  Wed Jan 22 03:32:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Jan 2025 03:32:57 GMT
Subject: RFR: 8348240: Remove
 SystemDictionaryShared::lookup_super_for_unregistered_class()
Message-ID: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>

I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there.

The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java.

### How this works:

For example, let's assume you have the following classfiles in foo.jar:


interface MyInterface1 {}
interface MyInterface2 {}
class MyClass extends Object implements MyInterface1, MyInterface2 {}


The CDS classlist file can look like this:


java/lang/Object id: 1
MyInterface1: id: 2 super: 1 source: foo.jar
MyInterface2: id: 3 super: 1 source: foo.jar
MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar


When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters:

- `name` = "MyClass"
- `superClass` = java.lang.Object
- `interfaces` = {MyInterface1, MyInterface2} 

`CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`.

-------------

Commit messages:
 - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class()

Changes: https://git.openjdk.org/jdk/pull/23226/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23226&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348240
  Stats: 342 lines in 9 files changed: 193 ins; 113 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/23226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23226/head:pull/23226

PR: https://git.openjdk.org/jdk/pull/23226

From amitkumar at openjdk.org  Wed Jan 22 03:37:10 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 22 Jan 2025 03:37:10 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2 [v2]
In-Reply-To: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
Message-ID: <5mzVC2Orm-UK6GVDMIaL94k6ne7ojjE5PBRKIOE7-UQ=.4cc7aa73-e265-4a92-b646-8d17e8c147e3@github.com>

> Fixes `foreign/normalize/TestNormalize.java` failure on s390x.

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  take ppc route

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23197/files
  - new: https://git.openjdk.org/jdk/pull/23197/files/a42e63d4..e1185927

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23197&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23197&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23197/head:pull/23197

PR: https://git.openjdk.org/jdk/pull/23197

From jwaters at openjdk.org  Wed Jan 22 04:13:49 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Jan 2025 04:13:49 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v15]
In-Reply-To: <cwusoKYlA-PQJKzcr5qF09YpVfTfNPI9GHu08jTyGCY=.00023f5f-b115-427a-9862-fe0a77a84388@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <V6_HK5nJ3toWNn4G3tC0vbnuGSh-3H9GvJmbsNNcW58=.fc7dc3ce-dd04-4e2f-8750-f17e00864764@github.com>
 <cwusoKYlA-PQJKzcr5qF09YpVfTfNPI9GHu08jTyGCY=.00023f5f-b115-427a-9862-fe0a77a84388@github.com>
Message-ID: <PZZiJNc2DtSCoGs2ua_Mf2q1wZe_o2ak1iGMTQKs5vs=.59e026d3-bde5-41be-8f03-69a9f8b9e1f1@github.com>

On Tue, 7 Jan 2025 09:31:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into hotspot
>>  - _WINDOWS && AARCH64 in sharedRuntime.hpp
>>  - AARCH64 in sharedRuntimeRem.cpp
>>  - Refactor sharedRuntime.cpp
>>  - CAST_FROM_FN_PTR in os_windows.cpp
>>  - Merge branch 'openjdk:master' into hotspot
>>  - fmod_winarm64 in sharedRuntime.cpp
>>  - fmod_winarm64 in sharedRuntimeRem.cpp
>>  - fmod_winarm64 in sharedRuntime.hpp
>>  - Typo in sharedRuntimeRem.cpp
>>  - ... and 17 more: https://git.openjdk.org/jdk/compare/b459ad94...ff1c4664
>
> Keep open please

> @TheShermanTanker - Are you needing further reviews?

I think this doesn't need further review, but I'm waiting for all the corresponding unused variable Pull Requests for the other areas of the JDK to get the green light before I integrate them all at once

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2606247995

From cslucas at openjdk.org  Wed Jan 22 04:23:37 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 22 Jan 2025 04:23:37 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>
Message-ID: <soLuE9bJ60nFyb_OSeyq-OBqq3uJLnTtKAHfUawfMY0=.778259ab-684a-4571-b1ef-91f9b3a1b643@github.com>

On Fri, 17 Jan 2025 08:44:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.

@shipilev - are you suggesting to patch all `shenandoahBarrierSetAssembler_*` backend specific files to not use `load_byte_map`? It looks like we would end up in a similar situation if I go with the approach that you're suggesting - if I'm understanding it correctly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2606259667

From dholmes at openjdk.org  Wed Jan 22 05:25:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 05:25:34 GMT
Subject: RFR: 8337458: Remove debugging code print_cpool_bytes
In-Reply-To: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
References: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
Message-ID: <K6At2J1BtJH2LXNQMRvntT_apJaOHYXhoGgIBqUaOiQ=.d9120764-6729-45b8-8841-174edb9a64d0@github.com>

On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
> Tested with tier1 locally.

Looks fine. Thanks for cleaning it up.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23222#pullrequestreview-2566215728

From dholmes at openjdk.org  Wed Jan 22 06:13:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 06:13:38 GMT
Subject: Integrated: 8348117: The two-argument overload of
 SignatureHandlerLibrary::add is not used
In-Reply-To: <vW88xKa_FXz0vVgGDhxMTVLTLu_MgkFbcGhf2xcSKJs=.a7692e6c-ac3c-4035-ac7e-141952c7a457@github.com>
References: <vW88xKa_FXz0vVgGDhxMTVLTLu_MgkFbcGhf2xcSKJs=.a7692e6c-ac3c-4035-ac7e-141952c7a457@github.com>
Message-ID: <hJrTuVAv68q0K3j0ArIs662TYMXv71IHOxU9gTRO_GY=.693c7b49-4eca-469b-8053-8efba4c4bf81@github.com>

On Tue, 21 Jan 2025 08:44:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The  `SignatureHandlerLibrary::add` two-arg API was added to support closed code under [JDK-8087333](https://bugs.openjdk.org/browse/JDK-8087333) in JDK 9. That closed code was removed again, still in JDK 9, as part of JEP 297 ([JDK-8168503](https://bugs.openjdk.org/browse/JDK-8168503)) which unified the closed and open ARM ports - leaving the API unused.
> 
> There were other leftovers from the same set of changes so they are cleaned up as well - nothing significant, just unnecessary friend declarations, comments, and one other method.
> 
> Testing:
>  - all builds in tiers 1-5
> 
> Thanks.

This pull request has now been integrated.

Changeset: 3c2a1d87
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c2a1d87d577ee953069e731be140a66a9e7ec1d
Stats:     40 lines in 9 files changed: 0 ins; 40 del; 0 mod

8348117: The two-argument overload of SignatureHandlerLibrary::add is not used

Reviewed-by: coleenp, shade

-------------

PR: https://git.openjdk.org/jdk/pull/23207

From dholmes at openjdk.org  Wed Jan 22 06:27:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 06:27:40 GMT
Subject: RFR: 8348182: Remove DONT_USE_PRECOMPILED_HEADER
In-Reply-To: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
References: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
Message-ID: <3BH3qoBL4W99lj1AmUiIjTNjA740XP5fxKINj_mPhMw=.787178fb-686b-46dc-850e-c29df38e8f1b@github.com>

On Tue, 21 Jan 2025 12:41:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Before [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we had to remove the include lines in precompiled.hpp when precompiled headers were turned off. This was done by defining DONT_USE_PRECOMPILED_HEADER.
> 
> After [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we simply don't include precompiled.hpp if precompiled headers are turned off and therefore we don't need to removed the include lines.
> 
> I propose that we get rid of DONT_USE_PRECOMPILED_HEADER.

LGTM2. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23211#pullrequestreview-2566288315

From sroy at openjdk.org  Wed Jan 22 08:14:52 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 22 Jan 2025 08:14:52 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v7]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <J5kGDPQ9jHdTk1N3MCJh4jRll9oQ-UK-4TSjGL6UVB0=.471e75cc-0c9e-49a9-9fda-a7bab8931b27@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 - update references
 - Comments and vsx check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/6fc23197..b0917bdb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=05-06

  Stats: 40 lines in 2 files changed: 32 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From epeter at openjdk.org  Wed Jan 22 08:17:43 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 22 Jan 2025 08:17:43 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>
 <H_eWDODWEakhmBpbiL2apPxV9iJeeoTFBjSBsagytNI=.0efc7881-efbc-4609-8982-17eb13f3c56a@github.com>
 <xCmBgJGY_IQMTbqFxlT3WKxI4ZQ9x4kgryTmUX8w3xU=.acbcba77-a4d3-4feb-87f2-2e12ea2477bc@github.com>
 <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>
Message-ID: <BHXNnvzIS7DJ4D1hsLvohSsg3hTIaHY4NlXTTspDKGg=.d2344f73-e9cd-4ee5-985f-43a1e0512e9c@github.com>

On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > Can you quickly summarize what tests you have, and what they test?
>>> 
>>> Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
>> 
>> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.
>
>> > > Can you quickly summarize what tests you have, and what they test?
>> > 
>> > 
>> > Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
>> 
>> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.
> 
> 
> Validations details:-
> 
> A) x86 backend changes
>    - new assembler instruction
>    - macro assembly routines. 
>     Test point:-  test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java
>          - This test is based on a testng framework and includes new DataProviders to generate test vectors.
>          -  Test vectors cover the entire float16 value range and also special floating point values (NaN, +Int, -Inf, 0.0 and -0.0) 
> B) GVN transformations:-
>      -  Value Transforms
>         Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>               -  Covers all the constant folding scenarios for add, sub, mul, div, sqrt, fma, min, and max operations addressed by this patch.
>               -  It also tests special case scenarios for each operation as specified by Java language specification.
>     -   identity Transforms
>         Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>                -  Covers identity transformation for  ReinterpretS2HFNode,  DivHFNode
>     -  idealization Transforms
>         Test points:-  test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java
>                                 :-   test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>             - Contains test point for the following transform 
>                          MulHF idealization i.e. MulHF * 2 => AddHF  
>            -  Contains test point for the following transform
>                          DivHF SRC ,  PoT(constant) =>  MulHF SRC * reciprocal (constant) 
>             - Contains idealization test points for the following transform 
>                    ConvF2HF(FP32BinOp(ConvHF2F(x), ConvHF2F(y))) =>
>                            ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y)))

@jatin-bhateja just ping me again whenever this is ready for a re-review :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2606558812

From xtex at envs.net  Wed Jan 22 08:19:56 2025
From: xtex at envs.net (Bingwu Zhang)
Date: Wed, 22 Jan 2025 16:19:56 +0800
Subject: Clang toolchain type should not be bound with LLD
Message-ID: <3505922.aeNJFYEL58@xtex1>

Hi!

Currently, when --with-toolchain-type=clang is set, the OpenJDK build system 
will force the C++ compiler to use LLD as linker [1].

However, Clang works with other linkers and other linkers work with Clang. LLD 
should not be the only possible linker.

Thus I propose a patch [2], which makes configure script accept a LLD variable 
pointing to the path of linker to use. I have verified that specifying LLD=mold 
can compile OpenJDK 24+32 with mold.

I wonder if anyone supports this idea and want to make it my first contribution 
to the (upstream) OpenJDK. So per the developer guide [3], I am writing this 
message to socialize my change and make some friends.
I have signed off an individual agreement of Oracle Contributor Agreement 
yesterday, but it is still "Under Review".
If someone agrees with my patch, it will be cherry-picked from my development 
tree, rebasing onto the main branch, and sent to openjdk/jdk as a PR later.

Thanks for your reading!

[1] https://github.com/openjdk/jdk/blob/
15d6469e8da635364c0ba83e425fd149c2d69495/make/autoconf/flags-ldflags.m4#L74
[2] https://github.com/AOSC-Tracking/jdk/commit/
507b5d77bc3a52f9b9a1a4f0019d423263c99a18
[3] https://openjdk.org/guide/

-- 
Bingwu Zhang <xtex at aosc.io>
xtex @ Wed, 22 Jan 2025 07:17:03 +0000
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20250122/bcf72b71/signature.asc>

From sroy at openjdk.org  Wed Jan 22 08:21:12 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 22 Jan 2025 08:21:12 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v8]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <6J3HmkpfsgiIRVa-dqfvxOKvdl6bGVbCP55pwEtFHEk=.4ac55aa4-6048-48fe-ac1a-e6fb25e8ccb6@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  spaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/b0917bdb..94f2c361

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=06-07

  Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From sroy at openjdk.org  Wed Jan 22 08:27:13 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 22 Jan 2025 08:27:13 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v9]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <SZM-JCrTK8KfbZU5S2DKIa8XvtQQWV6DePUlFJqRgAo=.85227d0f-fbba-494e-aae0-20e44b16161e@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - spaces
 - Merge branch 'master' into ghash_processblocks
 - spaces
 - update references
 - Comments and vsx check
 - restore
 -  assertion for blocks
 -  assertion for blocks
 -  clearing bits
 -  clearing bits
 - ... and 27 more: https://git.openjdk.org/jdk/compare/d777218f...b04b6924

-------------

Changes: https://git.openjdk.org/jdk/pull/20235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=08
  Stats: 162 lines in 2 files changed: 159 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From cnorrbin at openjdk.org  Wed Jan 22 09:12:57 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 22 Jan 2025 09:12:57 GMT
Subject: RFR: 8337997: MallocHeader description refers to non-existent NMT
 state "minimal"
In-Reply-To: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
References: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
Message-ID: <ImxTeaf-1xHjUUkXX2AR_qoocmieBTtJFYPAI3_RIy0=.bf9f45c3-b26b-435b-99bc-7f89e1269646@github.com>

On Mon, 20 Jan 2025 15:16:10 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Small fix to a comment in `mallocHeader.hpp`, which referenced a non-existant NMT state. This has been changed to the correct (existing) state.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23199#issuecomment-2606667781

From duke at openjdk.org  Wed Jan 22 09:12:57 2025
From: duke at openjdk.org (duke)
Date: Wed, 22 Jan 2025 09:12:57 GMT
Subject: RFR: 8337997: MallocHeader description refers to non-existent NMT
 state "minimal"
In-Reply-To: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
References: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
Message-ID: <81hbqYFCUpCmfeCW1dLylRGb4Oai1mqlaOaDEUEtKes=.e5f863f2-8f8d-456a-8551-3938020a156a@github.com>

On Mon, 20 Jan 2025 15:16:10 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Small fix to a comment in `mallocHeader.hpp`, which referenced a non-existant NMT state. This has been changed to the correct (existing) state.

@caspernorrbin 
Your change (at version 1af4e8f71f48bb646e46f49db42e82d451f5462c) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23199#issuecomment-2606670348

From stefank at openjdk.org  Wed Jan 22 09:28:42 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jan 2025 09:28:42 GMT
Subject: RFR: 8348182: Remove DONT_USE_PRECOMPILED_HEADER
In-Reply-To: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
References: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
Message-ID: <NZ6JJVQM2NKNkyND37s_R-5WTWazqfBvVqbEJamCJ-M=.27bccc99-6a4c-416a-9707-966f99a333d4@github.com>

On Tue, 21 Jan 2025 12:41:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Before [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we had to remove the include lines in precompiled.hpp when precompiled headers were turned off. This was done by defining DONT_USE_PRECOMPILED_HEADER.
> 
> After [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we simply don't include precompiled.hpp if precompiled headers are turned off and therefore we don't need to removed the include lines.
> 
> I propose that we get rid of DONT_USE_PRECOMPILED_HEADER.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23211#issuecomment-2606703315

From stefank at openjdk.org  Wed Jan 22 09:28:43 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jan 2025 09:28:43 GMT
Subject: Integrated: 8348182: Remove DONT_USE_PRECOMPILED_HEADER
In-Reply-To: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
References: <B5wXozQ8qKlaSss8r4CSvEMxLqr_xYCO7FvarHxaTLI=.e209d812-5f23-48af-9a42-2dc3159b9dd9@github.com>
Message-ID: <yppdAE4jvrhHCrrQye0eqDDI0q_FGFYNKjdOTyVSJV8=.0461545e-b62c-416f-8228-b1340e68025e@github.com>

On Tue, 21 Jan 2025 12:41:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Before [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we had to remove the include lines in precompiled.hpp when precompiled headers were turned off. This was done by defining DONT_USE_PRECOMPILED_HEADER.
> 
> After [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) we simply don't include precompiled.hpp if precompiled headers are turned off and therefore we don't need to removed the include lines.
> 
> I propose that we get rid of DONT_USE_PRECOMPILED_HEADER.

This pull request has now been integrated.

Changeset: 9b98cc0b
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b98cc0ba7b626141c5f82df6ae34b0e2015b2ae
Stats:     10 lines in 2 files changed: 0 ins; 9 del; 1 mod

8348182: Remove DONT_USE_PRECOMPILED_HEADER

Reviewed-by: erikj, shade, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/23211

From stefank at openjdk.org  Wed Jan 22 09:29:36 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jan 2025 09:29:36 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide
In-Reply-To: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
Message-ID: <W4pG-R2Yh3vQmRvlWvZ43fXsPFTOhQIeWz23bYSUH4o=.c0377f5f-cf32-4387-879e-cb3acfee5caa@github.com>

On Tue, 21 Jan 2025 12:29:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need for HotSpot devs to include the precompiled.hpp. This is the PR to reflect that.
> 
> I know that there is some process around updating the style guide, but I can't find it, so I'm starting with a plain PR.

OK. Thanks. I'll update the text and will see what other reviewers say.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23210#issuecomment-2606709125

From shade at openjdk.org  Wed Jan 22 09:31:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jan 2025 09:31:36 GMT
Subject: RFR: 8337458: Remove debugging code print_cpool_bytes
In-Reply-To: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
References: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
Message-ID: <K718EqA2vrV3XUH5mJ5d8QNNzAUiBnvkxffIl1tU-SQ=.06beb7ca-bca1-4824-a547-2bbe8b2585b4@github.com>

On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
> Tested with tier1 locally.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23222#pullrequestreview-2566657064

From stefank at openjdk.org  Wed Jan 22 09:34:18 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jan 2025 09:34:18 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide [v2]
In-Reply-To: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
Message-ID: <JChUJHsXOxUFNs-FMGcSM2MsbsGjGqg31cNWsLWQqnA=.9a999154-b540-41a9-9fb7-6fb428cc9a5c@github.com>

> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need for HotSpot devs to include the precompiled.hpp. This is the PR to reflect that.
> 
> I know that there is some process around updating the style guide, but I can't find it, so I'm starting with a plain PR.

Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:

 - Update hotspot-style.md
 - Update hotspot-style.html

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23210/files
  - new: https://git.openjdk.org/jdk/pull/23210/files/09c88c4f..9cfbc1dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23210&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23210&range=00-01

  Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23210.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23210/head:pull/23210

PR: https://git.openjdk.org/jdk/pull/23210

From aph at openjdk.org  Wed Jan 22 09:48:35 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 22 Jan 2025 09:48:35 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
In-Reply-To: <MbvF1I34M2hux3ipJ2BzPMCaT0sgCBehDAexAOZrQK0=.0361ec61-06b1-4bdf-afbb-aa9f3e625394@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
 <MbvF1I34M2hux3ipJ2BzPMCaT0sgCBehDAexAOZrQK0=.0361ec61-06b1-4bdf-afbb-aa9f3e625394@github.com>
Message-ID: <NQH-cQkBQm7NMS5wD7i9e-3TQIY9fIFDEbCjHCit8OQ=.90b2e5aa-2b86-44fd-812d-8ad9aef63f1f@github.com>

On Tue, 21 Jan 2025 10:39:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Upcall stub frames and entry frames are always below the bottom frame.

Can you please explain this a little more? It's very confusing. Why is the logic here different from, say, x86 and AArch64? I guess it must be some difference to do with the shape of upcall stub frames and entry frames. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23197#issuecomment-2606752714

From rehn at openjdk.org  Wed Jan 22 10:28:49 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 22 Jan 2025 10:28:49 GMT
Subject: RFR: 8347794: RISC-V: Add Zfhmin - Float cleanup [v5]
In-Reply-To: <X-LkQru8kli9XmuwNpPiH6o-9ZFz8o3RuwqWUBl2yng=.935afded-7cbc-47b4-8661-28c9f2928d6a@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
 <X-LkQru8kli9XmuwNpPiH6o-9ZFz8o3RuwqWUBl2yng=.935afded-7cbc-47b4-8661-28c9f2928d6a@github.com>
Message-ID: <OjJDIoXKfnEN8NLP_c-TFxE_EscPnCFN9gR9ZTWnE0c=.ac01e3ef-dc82-4728-857a-a57b84df7dae@github.com>

On Tue, 21 Jan 2025 08:28:22 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hey, please consider.
>> 
>> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
>> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
>> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
>> We also had this same format repeated many times.
>> 
>> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
>> fadd_s is thus described in code as:
>> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
>> Instead of:
>> `INSN(fadd_s,   0b1010011, 0b0000000);`
>> 
>> It then moves zfh/zfhmin to a sepererate section and assert checks them.
>> 
>> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
>> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
>> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
>> 
>> Tested:
>> jdk/java/lang/Math
>> jdk/java/util/Formatter/
>> jdk/java/lang/Float/
>> jdk/java/lang/Double/
>> hotspot/jtreg/compiler/floatingpoint/
>> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> hotspot/jtreg/compiler/eliminateAutobox/
>> hotspot/jtreg/vmTestbase/jit/
>> 
>> And tier1 twice, no FP issues. (Using UseZfh/min)
>> 
>> Thanks, Robbin
>
> Robbin Ehn 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:
> 
>  - Fixed type Rs2
>  - Merge branch 'master' into zfhmin
>  - Fix nit
>  - Merge branch 'master' into zfhmin
>  - FClassBits
>  - Merge branch 'master' into zfhmin
>  - Baseline

Thanks guys!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23130#issuecomment-2606847154

From rehn at openjdk.org  Wed Jan 22 10:28:50 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 22 Jan 2025 10:28:50 GMT
Subject: Integrated: 8347794: RISC-V: Add Zfhmin - Float cleanup
In-Reply-To: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
References: <pbHoC4581nPO2rQTvdXU9Q976bygZYVjsCFP8nNzLZ4=.f4117f77-9d0b-4a74-b6d6-459df86d2a1c@github.com>
Message-ID: <kv-lvE1owt82il21GQxhp3WL3drDT3TiIfPE-0vPPtk=.6ef93916-acc3-471d-a6bc-0a02fc62a128@github.com>

On Wed, 15 Jan 2025 10:12:57 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hey, please consider.
> 
> I'm looking making RVA23 support complete and I was looking into adding Zfhmin.
> I notice Zfh instructions didn't have any asserts checking if this extensions was enabled.
> I then notice that we had the inferior instruction description using a funct7 instead of FMT + funct5.
> We also had this same format repeated many times.
> 
> This patch takes all instructions format duplicates and replaces them with 'fp_base'.
> fadd_s is thus described in code as:
> `fp_base<S_32_sp, 0b00000>(Rd, Rs1, Rs2, rm);`
> Instead of:
> `INSN(fadd_s,   0b1010011, 0b0000000);`
> 
> It then moves zfh/zfhmin to a sepererate section and assert checks them.
> 
> Also as a bonus RoundingMode uses camel case while fclass_mask C, style.
> So I changed fclass_mask to FClassBit, now thinking about it not sure if it should be bit or mask.
> As in the context of the instruction fclass it is a bit, but when using the helpers e.g. zero it's a mask.
> 
> Tested:
> jdk/java/lang/Math
> jdk/java/util/Formatter/
> jdk/java/lang/Float/
> jdk/java/lang/Double/
> hotspot/jtreg/compiler/floatingpoint/
> hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> hotspot/jtreg/compiler/eliminateAutobox/
> hotspot/jtreg/vmTestbase/jit/
> 
> And tier1 twice, no FP issues. (Using UseZfh/min)
> 
> Thanks, Robbin

This pull request has now been integrated.

Changeset: fb438492
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb438492275cd15390d26460cada2d5e1a49c159
Stats:     536 lines in 8 files changed: 303 ins; 133 del; 100 mod

8347794: RISC-V: Add Zfhmin - Float cleanup

Reviewed-by: fyang, mli

-------------

PR: https://git.openjdk.org/jdk/pull/23130

From stuefe at openjdk.org  Wed Jan 22 11:03:59 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 22 Jan 2025 11:03:59 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v3]
In-Reply-To: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
Message-ID: <TMXE8mJbB3iauRxr3F-B_xqVAPYs_vKLHUMJoYSmJI8=.abbc61c0-b7a8-4626-9b30-2ceb4096c919@github.com>

> If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 
> 
> Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.
> 
> We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.
> 
> This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.
> 
> Additionally, the patch provides a helpful output in the register/stack section, e.g:
> 
> 
> RDI=0x0000000800000000 points into nKlass protection zone
> 
> 
> 
> Testing: 
> - GHAs.
> - I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
> - I tested manually on Windows x64
> - I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - test-fixes
 - fix bug found with jtreg test where metaspace buddy allocator would accidentally replace the protection mapping
 - add jtreg test; replaces the gtest
 - Merge branch 'master' into JDK-8330174-Protection-zone-for-easier-detection-of-accidental-zero-nKlass-use
 - treat not-found protection zone buffer as fatal error
 - fix 32bit build
 - fix windows crash on os::protect
 - start

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23190/files
  - new: https://git.openjdk.org/jdk/pull/23190/files/aa063d94..6c1b0e97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=01-02

  Stats: 10012 lines in 1863 files changed: 3419 ins; 3999 del; 2594 mod
  Patch: https://git.openjdk.org/jdk/pull/23190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23190/head:pull/23190

PR: https://git.openjdk.org/jdk/pull/23190

From rehn at openjdk.org  Wed Jan 22 11:13:35 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 22 Jan 2025 11:13:35 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v2]
In-Reply-To: <LkrzacMIHzdUSGdFxVzSOgi4ruQ56bDXs5mfveKRDAI=.9f00f850-1dca-4123-9483-2e24e869ffbe@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <yI5YtZKwsMUtmnfkfieMLGxeGA0l0lBvVrP6_CeFvnI=.c6af5027-6154-43d8-b3ae-6b3241cc55fa@github.com>
 <ZXlJqtmjHbMgonfdHwckVk6GQFSEMOrKOOFpK08WViE=.45d985f5-999c-4ea6-b77c-859b051bc7cf@github.com>
 <Qy-WZ4eKz_YB4YaScL653RsYmHyxvGPs2gT0DefGieA=.539791b0-4144-4f9d-8ea9-fc66e8f8c7f7@github.com>
 <LkrzacMIHzdUSGdFxVzSOgi4ruQ56bDXs5mfveKRDAI=.9f00f850-1dca-4123-9483-2e24e869ffbe@github.com>
Message-ID: <2IYzXl9shQm1m8KuJb3c_Bk5IhXwy7yOCChAgj10jPY=.674e4f88-00e2-4ee5-aca8-0023d4d1160a@github.com>

On Tue, 21 Jan 2025 09:53:03 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> How about we do this directly on the callsite?
>> 
>>   int Rs = -1;
>>   if (can_zfa_zli_float(imm, &Rs)) {
>>     _fli_s(Rd, Rs);
>>   }
>
> Or can we use `zfa_zli_lookup_float/double` instead here?

Then we loose the assert on UseZfa and we still need to cast to bits, so basically copy out the code from can_zfa_zli_float.

I'll merge with zfh and try to address your concerns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1925139779

From rrich at openjdk.org  Wed Jan 22 12:07:37 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 22 Jan 2025 12:07:37 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <pAErLf6MXbz_0xFLKjf3IfzGaRJ1U1k6rf3duhELl_o=.1769911b-aea0-4049-85b9-0b86cbe7ca91@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <xJ6McgRAGAME1e7jGmE-Rg3-hzkqTKraxAh5-vgSPz4=.be7dd78d-8902-4fb3-9199-cd915fee645f@github.com>
 <pAErLf6MXbz_0xFLKjf3IfzGaRJ1U1k6rf3duhELl_o=.1769911b-aea0-4049-85b9-0b86cbe7ca91@github.com>
Message-ID: <zDQHpaeDpuUrxUMpjOlaNcir9WbBLEc7MlNT4qYKoOA=.e73dc9e3-dabe-4ae7-943e-d30ddecc1d29@github.com>

On Tue, 21 Jan 2025 17:20:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp line 607:
>> 
>>> 605:                        super_klass = R4,
>>> 606:                        temp1_reg = R6;
>>> 607:         __ check_klass_subtype_slow_path(sub_klass, super_klass, temp1_reg, noreg); // may return with CR0.eq if successful
>> 
>> The comment is unclear to me. Where is the result of the subtype check? Can it also return with CR0.ne if successful?
>> I noticed you added the `crandc` to `check_klass_subtype_slow_path_linear()` but if we reach there calling from this location then the `crandc` is not emitted because `L_success == nullptr`. Is this ok?
>> I'd appreciate comments on the masm methods explaining how the result of the subtype check is conveyed.
>
> The correct result is always in CR0 with this PR (unless a label or result GP reg is provided).
> "return" means "blr", here. That can optionally be used in case of success. In this case, CR0 is always "eq".
> I've moved the `crandc` instruction into `check_klass_subtype_slow_path_linear` which contains such a "blr" for a success case. This way, the linear version works exactly as before.
> The new code `check_klass_subtype_slow_path_table` doesn't use "blr". That's why I added "may" to the comment.

This is extremely hard to see.
L2154 with the "blr" in `check_klass_subtype_slow_path_linear` looks redundant to me. It should be removed if you agree.
The comment here should be adapted then too.
Also the comment at macroAssembler_ppc.cpp:2258 needs to be adapted because fallthrough from `check_klass_subtype_slow_path` does not mean "not successful". `L_failure` could be renamed to `L_fast_path_failure`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1925207385

From cnorrbin at openjdk.org  Wed Jan 22 12:13:04 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 22 Jan 2025 12:13:04 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v15]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  treap swap fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/8272e43f..e03b63f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=13-14

  Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From rrich at openjdk.org  Wed Jan 22 12:24:40 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 22 Jan 2025 12:24:40 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <pf8EohpEjn_fgy64mEtkKh8ZJxp81rpGnbafOXg44N0=.c40c1649-45c0-4113-b00e-2d6db070fdb7@github.com>

On Wed, 25 Dec 2024 15:40:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2157:

> 2155: 
> 2156:   bind(fallthru);
> 2157:   if (L_success != nullptr && result_reg == noreg) {

Is there a problem if `L_success == nullptr && result_reg == noreg` and there aren't any secondary supers?
In that case we would reach here with CR0.eq from L2134 and we would fallthrough with CR0.eq. Due to the change in `C1StubId::slow_subtype_check_id` we would return there with CR0.eq.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1925229785

From coleenp at openjdk.org  Wed Jan 22 12:24:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jan 2025 12:24:44 GMT
Subject: RFR: 8337458: Remove debugging code print_cpool_bytes
In-Reply-To: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
References: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
Message-ID: <idM2o8uKep6LJiNYyVVuzlmhEPGF8XH5MOUkATbUz0Y=.e970c057-17fb-4fd8-a0e5-745f633110a1@github.com>

On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
> Tested with tier1 locally.

Thanks for reviewing David and Aleksey.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23222#issuecomment-2607102885

From coleenp at openjdk.org  Wed Jan 22 12:24:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jan 2025 12:24:45 GMT
Subject: Integrated: 8337458: Remove debugging code print_cpool_bytes
In-Reply-To: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
References: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
Message-ID: <7ZHuVIo0XCKk-GE1NITDT5b61sUgcmBPYZO04iFw-F0=.93481fe6-6f4c-47eb-ab58-13e91389b2a0@github.com>

On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
> Tested with tier1 locally.

This pull request has now been integrated.

Changeset: 86a8b48b
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86a8b48b6cc315bae8d385c5c3aafcc6bd401e59
Stats:     153 lines in 1 file changed: 0 ins; 153 del; 0 mod

8337458: Remove debugging code print_cpool_bytes

Reviewed-by: dholmes, shade

-------------

PR: https://git.openjdk.org/jdk/pull/23222

From cnorrbin at openjdk.org  Wed Jan 22 12:34:42 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 22 Jan 2025 12:34:42 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v14]
In-Reply-To: <PH9gkD1VFyR-24gDYZSEl3V7OuD7gItLu5dEz8sQoM4=.a34d8e59-e395-49c7-b41f-99036a01b6cc@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <7uETGf-b8UH8j4OEow-u89ec_08pC-HEvtisfPJr258=.9aac817c-f33c-4619-9b76-069d9219367d@github.com>
 <PH9gkD1VFyR-24gDYZSEl3V7OuD7gItLu5dEz8sQoM4=.a34d8e59-e395-49c7-b41f-99036a01b6cc@github.com>
Message-ID: <n21CLjtlx7hKXvIm4kLCJV1spO2Ec7OQtVxk6uceDgw=.8d494bbe-0482-4b9e-9c56-cbb0a6b4d109@github.com>

On Tue, 21 Jan 2025 20:11:21 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> I remember Lois asked, during your presentation at the staff meeting, how to change our existing code to start using your RBTree and your answer was a single line change. Could you please remind me what that line was? I'd like to benchmark the new RBTree using my NMT benchmark to see whether there is any performance difference from Treap.


To swap out to the red-black tree, you can change these two lines in `vmatree.hpp`:
```c++
  using VMATreap = TreapCHeap<position, IntervalChange, PositionComparator>;
  using TreapNode = VMATreap::TreapNode;

to:
```c++
  using VMATreap = RBTreeCHeap<position, IntervalChange, PositionComparator, mtNMT>;
  using TreapNode = VMATreap::RBNode;


The internal variable names would still refer to the treap, but for testing that shouldn't matter.
If you want the VMATree gtests to compile, you need to do two more things:
Add `friend class NMTVMATreeTest;` to the `RBTree` class.
Change `treap.find(treap._root, key);` to `treap.find_node(key);` in `test_vmatree.cpp:54`

I have also done some benchmarking on my own only comparing the two trees in isolation. In the worst case scenario, which is only sequential inserts/removals, the red-black tree was a bit slower (~10%), but with more balanced operations, the treap was slower. Hopefully you will find similar results. I don't know how large of a % of NMT overhead is tree operations. If it's not high it shouldn't affect overall performance much in either direction.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2607127293

From epeter at openjdk.org  Wed Jan 22 12:37:42 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 22 Jan 2025 12:37:42 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>
 <H_eWDODWEakhmBpbiL2apPxV9iJeeoTFBjSBsagytNI=.0efc7881-efbc-4609-8982-17eb13f3c56a@github.com>
 <xCmBgJGY_IQMTbqFxlT3WKxI4ZQ9x4kgryTmUX8w3xU=.acbcba77-a4d3-4feb-87f2-2e12ea2477bc@github.com>
 <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>
Message-ID: <FlC9OUD_M5uFZhQM1SUS3n4wAbtXbnuvTVR_8-ASLfQ=.c821a426-1c79-4b76-9651-c42b173cc3b9@github.com>

On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > Can you quickly summarize what tests you have, and what they test?
>>> 
>>> Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
>> 
>> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.
>
>> > > Can you quickly summarize what tests you have, and what they test?
>> > 
>> > 
>> > Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
>> 
>> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.
> 
> 
> Validations details:-
> 
> A) x86 backend changes
>    - new assembler instruction
>    - macro assembly routines. 
>     Test point:-  test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java
>          - This test is based on a testng framework and includes new DataProviders to generate test vectors.
>          -  Test vectors cover the entire float16 value range and also special floating point values (NaN, +Int, -Inf, 0.0 and -0.0) 
> B) GVN transformations:-
>      -  Value Transforms
>         Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>               -  Covers all the constant folding scenarios for add, sub, mul, div, sqrt, fma, min, and max operations addressed by this patch.
>               -  It also tests special case scenarios for each operation as specified by Java language specification.
>     -   identity Transforms
>         Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>                -  Covers identity transformation for  ReinterpretS2HFNode,  DivHFNode
>     -  idealization Transforms
>         Test points:-  test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java
>                                 :-   test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>             - Contains test point for the following transform 
>                          MulHF idealization i.e. MulHF * 2 => AddHF  
>            -  Contains test point for the following transform
>                          DivHF SRC ,  PoT(constant) =>  MulHF SRC * reciprocal (constant) 
>             - Contains idealization test points for the following transform 
>                    ConvF2HF(FP32BinOp(ConvHF2F(x), ConvHF2F(y))) =>
>                            ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y)))

@jatin-bhateja can you also merge here, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2607132748

From coleenp at openjdk.org  Wed Jan 22 13:46:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jan 2025 13:46:54 GMT
Subject: RFR: 8334320: Replace
 vmTestbase/metaspace/share/TriggerUnloadingWithWhiteBox.java with
 ClassUnloadCommon from testlibrary
Message-ID: <Ksm0Ks2LeRw5B-pm2VL6tuQg11d5ivEMftSKoeceTso=.4da2555a-e6ba-4f83-a2ee-5a0da1740afc@github.com>

Rename and make TriggerUnloadingWithWhiteBox call ClassUnloadCommon.triggerUnloading() instead of WB.fullGC().

-------------

Commit messages:
 - 8334320: Replace vmTestbase/metaspace/share/TriggerUnloadingWithWhiteBox.java with ClassUnloadCommon from testlibrary

Changes: https://git.openjdk.org/jdk/pull/23174/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23174&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334320
  Stats: 80 lines in 4 files changed: 36 ins; 38 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23174/head:pull/23174

PR: https://git.openjdk.org/jdk/pull/23174

From gziemski at openjdk.org  Wed Jan 22 14:03:49 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 22 Jan 2025 14:03:49 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v14]
In-Reply-To: <n21CLjtlx7hKXvIm4kLCJV1spO2Ec7OQtVxk6uceDgw=.8d494bbe-0482-4b9e-9c56-cbb0a6b4d109@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <7uETGf-b8UH8j4OEow-u89ec_08pC-HEvtisfPJr258=.9aac817c-f33c-4619-9b76-069d9219367d@github.com>
 <PH9gkD1VFyR-24gDYZSEl3V7OuD7gItLu5dEz8sQoM4=.a34d8e59-e395-49c7-b41f-99036a01b6cc@github.com>
 <n21CLjtlx7hKXvIm4kLCJV1spO2Ec7OQtVxk6uceDgw=.8d494bbe-0482-4b9e-9c56-cbb0a6b4d109@github.com>
Message-ID: <GvlMeCrBFZhXu7Jjw26bo1W9l_KKtzGLwh0AsT9kfyw=.652fc865-42b8-465e-98f0-6f88ee16f23e@github.com>

On Wed, 22 Jan 2025 12:31:56 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> > I remember Lois asked, during your presentation at the staff meeting, how to change our existing code to start using your RBTree and your answer was a single line change. Could you please remind me what that line was? I'd like to benchmark the new RBTree using my NMT benchmark to see whether there is any performance difference from Treap.
> 
> To swap out to the red-black tree, you can change these two lines in `vmatree.hpp`:
> 
> ```c++
>   using VMATreap = TreapCHeap<position, IntervalChange, PositionComparator>;
>   using TreapNode = VMATreap::TreapNode;
> ```
> 
> to:
> 
> ```c++
>   using VMATreap = RBTreeCHeap<position, IntervalChange, PositionComparator, mtNMT>;
>   using TreapNode = VMATreap::RBNode;
> ```
> 
> The internal variable names would still refer to the treap, but for testing that shouldn't matter. If you want the VMATree gtests to compile, you need to do two more things: Add `friend class NMTVMATreeTest;` to the `RBTree` class. Change `treap.find(treap._root, key);` to `treap.find_node(key);` in `test_vmatree.cpp:54`
> 
> I have also done some benchmarking on my own only comparing the two trees in isolation. In the worst case scenario, which is only sequential inserts/removals, the red-black tree was a bit slower (~10%), but with more balanced operations, the treap was slower. Hopefully you will find similar results. I don't know how large of a % of NMT overhead is tree operations. If it's not high it shouldn't affect overall performance much in either direction.

Thank you! I don't need gtest, so the 2 line change will work for me. I will report back my findings after I run my benchmark...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2607327364

From gziemski at openjdk.org  Wed Jan 22 14:23:51 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 22 Jan 2025 14:23:51 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v15]
In-Reply-To: <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>
Message-ID: <bUw-5qx0uaEqAvusi5mnI6Ho1khcs2Tgo39q638zSC0=.8504ca2c-77cc-4fd5-9785-bb202c19af5f@github.com>

On Wed, 22 Jan 2025 12:13:04 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   treap swap fix

I see this when trying to compile:


* For target hotspot_variant-server_libjvm_objs_vmatree.o:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:1:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/precompiled/precompiled.hpp:45:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memTracker.hpp:30:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.hpp:32:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.hpp:34:
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/utilities/rbTree.hpp:253:8: error: function 'RBTree<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, RBTreeCHeapAllocator<MemTag::mtNMT>>::visit_range_in_order<(lambda at /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:136:44)>' is used but not defined in this translation unit, and cannot be defined in any other translation unit because its type does not have linkage
  253 |   void visit_range_in_order(const K& from, const K& to, F f);
      |        ^
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:136:9: note: used here
  136 |   _tree.visit_range_in_order(A + 1, B + 1, [&](TreapNode* head) {

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2607378308

From mdoerr at openjdk.org  Wed Jan 22 14:25:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 Jan 2025 14:25:41 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2 [v2]
In-Reply-To: <5mzVC2Orm-UK6GVDMIaL94k6ne7ojjE5PBRKIOE7-UQ=.4cc7aa73-e265-4a92-b646-8d17e8c147e3@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
 <5mzVC2Orm-UK6GVDMIaL94k6ne7ojjE5PBRKIOE7-UQ=.4cc7aa73-e265-4a92-b646-8d17e8c147e3@github.com>
Message-ID: <Q32aPWSisXlzsRDB2NEPVZuz96mFbQqJr-b8rbe-e8M=.40993185-a499-42f7-b2b8-dc5c3e6233ad@github.com>

On Wed, 22 Jan 2025 03:37:10 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Fixes `foreign/normalize/TestNormalize.java` failure on s390x.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   take ppc route

Marked as reviewed by mdoerr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23197#pullrequestreview-2567358901

From mdoerr at openjdk.org  Wed Jan 22 14:25:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 Jan 2025 14:25:43 GMT
Subject: RFR: 8345285: [s390x] test failures:
 foreign/normalize/TestNormalize.java with C2
In-Reply-To: <NQH-cQkBQm7NMS5wD7i9e-3TQIY9fIFDEbCjHCit8OQ=.90b2e5aa-2b86-44fd-812d-8ad9aef63f1f@github.com>
References: <YL7URKcHssjhRwz0RrvsdJvLG9E3rK2cBo1zRi5C_pk=.f79a7df2-9ebe-4ae0-bbc9-611f6008f49a@github.com>
 <MbvF1I34M2hux3ipJ2BzPMCaT0sgCBehDAexAOZrQK0=.0361ec61-06b1-4bdf-afbb-aa9f3e625394@github.com>
 <NQH-cQkBQm7NMS5wD7i9e-3TQIY9fIFDEbCjHCit8OQ=.90b2e5aa-2b86-44fd-812d-8ad9aef63f1f@github.com>
Message-ID: <b8nLMJzFkycCRtjwlwZGP6cVYkDS3qT0n2KpF7j7X-g=.c4d8d184-0e5c-42cf-be49-c28d36bd2cda@github.com>

On Wed, 22 Jan 2025 09:45:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Upcall stub frames and entry frames are always below the bottom frame.
> 
> Can you please explain this a little more? It's very confusing. Why is the logic here different from, say, x86 and AArch64? I guess it must be some difference to do with the shape of upcall stub frames and entry frames. Thanks.

The bottom frame already has the correct `sender_sp` from `push_skeleton_frame()`. Frames immediately on top of the entry frame or upcall stub frame are bottom frames. The solution is just to avoid overwriting the correct value.
The `sender_sp` computation at this point does not take everything into account (e.g. which frames were resized due to s390 or PPC64 ABI requirements) and may be wrong for bottom frames.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23197#issuecomment-2607382386

From gziemski at openjdk.org  Wed Jan 22 14:27:48 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 22 Jan 2025 14:27:48 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v15]
In-Reply-To: <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>
Message-ID: <t-fG9TRh2ZLQCzA3L5oDOQcamcghvxhPvXlDkCnD5Oo=.c6b93f0b-1713-4011-a29e-f135c5daa406@github.com>

On Wed, 22 Jan 2025 12:13:04 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   treap swap fix

And this:


* For target hotspot_variant-server_libjvm_objs_memoryFileTracker.o:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.cpp:1:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/precompiled/precompiled.hpp:45:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memTracker.hpp:30:
In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.hpp:32:
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.hpp:235:11: error: no matching member function for call to 'visit_in_order'
  235 |     _tree.visit_in_order(f);
      |     ~~~~~~^~~~~~~~~~~~~~
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.cpp:75:15: note: in instantiation of function template specialization 'VMATree::visit_in_order<(lambda at /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.cpp:75:30)>' requested here
   75 |   file->_tree.visit_in_order([&](VMATree::TreapNode* current) {
      |               ^
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/utilities/rbTree.hpp:249:8: note: candidate function template not viable: 'this' argument has type 'const VMATreap' (aka 'const RBTree<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, RBTreeCHeapAllocator<(MemTag)'\f'>>'), but method is not marked const
  249 |   void visit_in_order(F f);
      |        ^
1 error generated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2607387469

From rehn at openjdk.org  Wed Jan 22 14:29:13 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 22 Jan 2025 14:29:13 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
Message-ID: <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>

> Hi, please consider!
> 
> This patch the Zfa zli floating point immediate load.
> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
> 
> When using one of the 32 'popular' floats we can now materialze them without a load.
> E.g.
> `float f = f1 * 0.5 + f2 * 2.0;`
> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
> 
> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
> 
> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
> 
> Passes:
> ./test/jdk/java/lang/Math
> ./test/hotspot/jtreg/compiler/floatingpoint/
> ./test/jdk/java/util/Formatter/
> ./test/jdk/java/lang/Float/
> ./test/jdk/java/lang/Double/
> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> ./test/hotspot/jtreg/compiler/eliminateAutobox/
> ./test/hotspot/jtreg/vmTestbase/jit/
> 
> Running tier1
> 
> Thanks!

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into zfa
 - Merge branch 'master' into zfa
 - EXPERIMENTAL
 - Merge branch 'master' into zfa
 - Merge branch 'master' into zfa
 - Flip bool static decl
 - Merge branch 'master' into zfa
 - Baseline

-------------

Changes: https://git.openjdk.org/jdk/pull/23171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23171&range=02
  Stats: 192 lines in 7 files changed: 183 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23171/head:pull/23171

PR: https://git.openjdk.org/jdk/pull/23171

From cnorrbin at openjdk.org  Wed Jan 22 14:54:05 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 22 Jan 2025 14:54:05 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v15]
In-Reply-To: <t-fG9TRh2ZLQCzA3L5oDOQcamcghvxhPvXlDkCnD5Oo=.c6b93f0b-1713-4011-a29e-f135c5daa406@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>
 <t-fG9TRh2ZLQCzA3L5oDOQcamcghvxhPvXlDkCnD5Oo=.c6b93f0b-1713-4011-a29e-f135c5daa406@github.com>
Message-ID: <xjoq0pM3MymuW21Ea3044KXZcxMiNuL3dedw1_4MAHc=.2dfb85c2-fbf3-4915-8ec1-0fdb9ef91eb4@github.com>

On Wed, 22 Jan 2025 14:24:51 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   treap swap fix
>
> And this:
> 
> 
> * For target hotspot_variant-server_libjvm_objs_memoryFileTracker.o:
> In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.cpp:1:
> In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/precompiled/precompiled.hpp:45:
> In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memTracker.hpp:30:
> In file included from /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.hpp:32:
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.hpp:235:11: error: no matching member function for call to 'visit_in_order'
>   235 |     _tree.visit_in_order(f);
>       |     ~~~~~~^~~~~~~~~~~~~~
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.cpp:75:15: note: in instantiation of function template specialization 'VMATree::visit_in_order<(lambda at /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/memoryFileTracker.cpp:75:30)>' requested here
>    75 |   file->_tree.visit_in_order([&](VMATree::TreapNode* current) {
>       |               ^
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/utilities/rbTree.hpp:249:8: note: candidate function template not viable: 'this' argument has type 'const VMATreap' (aka 'const RBTree<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, RBTreeCHeapAllocator<(MemTag)'\f'>>'), but method is not marked const
>   249 |   void visit_in_order(F f);
>       |        ^
> 1 error generated.

@gerard-ziemski I ran in to both of these trying to verify that swapping still worked. 
I pushed an update earlier today to fix the second issue, the `const` of `visit_in_order` had disappeared when I moved functions around. For the first issue, you would need to `#include rbTree.inline.hpp` with/instead of `rbTree.hpp`  in vmatree.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2607456270

From sroy at openjdk.org  Wed Jan 22 15:10:44 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 22 Jan 2025 15:10:44 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v10]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <Lvl7V5F72UcomYN3OlIGnbHzzUY9TvR4ht39Gkh0pG8=.df69e02d-a8ac-4562-b246-737308ec93c6@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  vsx logic change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/b04b6924..fa896389

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=08-09

  Stats: 11 lines in 2 files changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From shade at openjdk.org  Wed Jan 22 15:31:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jan 2025 15:31:00 GMT
Subject: RFR: 8348195: More u2 conversion warnings after JDK-8347147
In-Reply-To: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>
References: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>
Message-ID: <SSh1RV0DGMLr9nhVuRUahbvlteUoe7oFPSKN0ntMLnM=.2c099abc-91bb-4237-82ed-84443c69851f@github.com>

On Tue, 21 Jan 2025 15:49:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8347147](https://bugs.openjdk.org/browse/JDK-8347147), SonarCloud reports a few risky conversions from int to u2. It would be good to cover them with either checked_cast or changing the underlying type.

Thank you for reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23217#issuecomment-2607550826

From shade at openjdk.org  Wed Jan 22 15:31:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jan 2025 15:31:00 GMT
Subject: Integrated: 8348195: More u2 conversion warnings after JDK-8347147
In-Reply-To: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>
References: <6ZtuspTq7e0Wf8BD6QT5eghVJnS63kKgbDC6SmNCxsw=.dbaffb99-5134-4370-9e3e-c8e4a8a05d45@github.com>
Message-ID: <_DFWnIkqohC9d2yq0-rIWx4KjRk9yoPQjSfzfBQLUNc=.ba03dfc5-2bff-4c92-8bee-2742dbde0ab3@github.com>

On Tue, 21 Jan 2025 15:49:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> After [JDK-8347147](https://bugs.openjdk.org/browse/JDK-8347147), SonarCloud reports a few risky conversions from int to u2. It would be good to cover them with either checked_cast or changing the underlying type.

This pull request has now been integrated.

Changeset: 25bb698e
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25bb698eff9f5aadb54dd37a442e2e1bc555353a
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8348195: More u2 conversion warnings after JDK-8347147

Reviewed-by: coleenp, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/23217

From gziemski at openjdk.org  Wed Jan 22 15:45:48 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 22 Jan 2025 15:45:48 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v5]
In-Reply-To: <g_StbwSW8Tk2FDJHx2Kp8FNUVmjF_-2qkskRAZI3Fm4=.aa8ea6fc-1696-4b63-8b72-99df7c052a38@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <GDRx6XhicQAtd5RKTvco86EIrz3hyCB1cjYvLcQ6rtA=.757b1b51-2786-4c3e-b974-ccaf3398b832@github.com>
 <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>
 <g_StbwSW8Tk2FDJHx2Kp8FNUVmjF_-2qkskRAZI3Fm4=.aa8ea6fc-1696-4b63-8b72-99df7c052a38@github.com>
Message-ID: <t5cnxy2InXJLLVAxoQIPMWUX0WgkEF4Ls0Q16f_-oYQ=.246363bc-3cb8-47b4-83bb-a681711896fa@github.com>

On Mon, 20 Jan 2025 01:56:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We check for the flags when we initialize NMT and run only when NMTBenchmarkRecordedPID is set.
>
> We do have some terminal flags like `-version` and `-Xshare:dump`, but generally the VM does not have magic flags that behave that way. I still don't have a clear picture of the different phases involved with this work. We have a recording phase. Then we have the benchmarking phase that does something (I can't figure out what) with the recording. Then we have the Java tool which does ... what?
> 
> In any case I have concerns about how the "benchmarking" is initiated.

The problem is I want to record every os::malloc(), so I need locks way before they are initialized in the VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1925547655

From stuefe at openjdk.org  Wed Jan 22 16:41:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 22 Jan 2025 16:41:06 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v4]
In-Reply-To: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
Message-ID: <sSx7z7h1RkzZ2e4CI9vXiBbfttmB-JMei9xCuKBKhP8=.6ad929de-ab00-4942-80ea-e66b0562b9a7@github.com>

> If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 
> 
> Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.
> 
> We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.
> 
> This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.
> 
> Additionally, the patch provides a helpful output in the register/stack section, e.g:
> 
> 
> RDI=0x0000000800000000 points into nKlass protection zone
> 
> 
> 
> Testing: 
> - GHAs.
> - I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
> - I tested manually on Windows x64
> - I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  fix test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23190/files
  - new: https://git.openjdk.org/jdk/pull/23190/files/6c1b0e97..84b0d8f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23190/head:pull/23190

PR: https://git.openjdk.org/jdk/pull/23190

From shade at openjdk.org  Wed Jan 22 17:02:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jan 2025 17:02:50 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <soLuE9bJ60nFyb_OSeyq-OBqq3uJLnTtKAHfUawfMY0=.778259ab-684a-4571-b1ef-91f9b3a1b643@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>
 <soLuE9bJ60nFyb_OSeyq-OBqq3uJLnTtKAHfUawfMY0=.778259ab-684a-4571-b1ef-91f9b3a1b643@github.com>
Message-ID: <Q_Vj8HgbyXfh-N4-PCFksQb1iW3c6TAquTtz2odKRDw=.3a0652a2-bd39-4aeb-b4cd-640592902734@github.com>

On Wed, 22 Jan 2025 04:20:57 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> > I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.
> 
> @shipilev - are you suggesting to patch all `shenandoahBarrierSetAssembler_*` backend specific files to not use `load_byte_map`? It looks like we would end up in a similar situation if I go with the approach that you're suggesting - if I'm understanding it correctly.

Yes, I was thinking that if Shenandoah cannot use super-class `load_byte_map` and needs its own implementation, then it makes sense that Shenandoah barrier set should be using a special implementation directly instead of hacking the super-class implementation? 

But mostly I want to avoid unnecessary changes in files that are not related to Shenandoah :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2607782057

From aph at openjdk.org  Wed Jan 22 17:33:50 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 22 Jan 2025 17:33:50 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v4]
In-Reply-To: <sSx7z7h1RkzZ2e4CI9vXiBbfttmB-JMei9xCuKBKhP8=.6ad929de-ab00-4942-80ea-e66b0562b9a7@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
 <sSx7z7h1RkzZ2e4CI9vXiBbfttmB-JMei9xCuKBKhP8=.6ad929de-ab00-4942-80ea-e66b0562b9a7@github.com>
Message-ID: <OunmgpIoKD5HkEeaQO1WrQB5F8YCTyacMf60n66cfZs=.d101f790-cd86-4124-b9d6-518865193525@github.com>

On Wed, 22 Jan 2025 16:41:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 
>> 
>> Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.
>> 
>> We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.
>> 
>> This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.
>> 
>> Additionally, the patch provides a helpful output in the register/stack section, e.g:
>> 
>> 
>> RDI=0x0000000800000000 points into nKlass protection zone
>> 
>> 
>> 
>> Testing: 
>> - GHAs.
>> - I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
>> - I tested manually on Windows x64
>> - I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)
>> 
>> -- Update 2024-01-22 -- 
>> I added a jtreg test that is more thorough than a gtest (also scans the produced hs-err file)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

src/hotspot/share/cds/metaspaceShared.cpp line 1373:

> 1371: static constexpr uint64_t protzone_tag       = 0x50524F545A4F4E45ULL; // "PROTZONE"
> 1372: static constexpr uint64_t protzone_tag_start = 0x2D3E2D3E50524F54ULL; // "->->PROT"
> 1373: static constexpr uint64_t protzone_tag_end   = 0x50524F543C2D3C2DULL; // "PROT<-<-"

Is this endianness dependent?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23190#discussion_r1925709505

From rrich at openjdk.org  Wed Jan 22 17:46:49 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 22 Jan 2025 17:46:49 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <pf8EohpEjn_fgy64mEtkKh8ZJxp81rpGnbafOXg44N0=.c40c1649-45c0-4113-b00e-2d6db070fdb7@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <pf8EohpEjn_fgy64mEtkKh8ZJxp81rpGnbafOXg44N0=.c40c1649-45c0-4113-b00e-2d6db070fdb7@github.com>
Message-ID: <zi9F3u3D7LO_XRAkOpZcSLwdmUm3Y7iX247VaxSBQr4=.1d9e632a-636d-4166-bd0a-1c18ae94b50e@github.com>

On Wed, 22 Jan 2025 12:21:54 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
>> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
>> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
>> 
>> Performance difference can be observed when C2 is disabled (measured on Power10):
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
>> 
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
>> 
>> 
>> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).
>
> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2157:
> 
>> 2155: 
>> 2156:   bind(fallthru);
>> 2157:   if (L_success != nullptr && result_reg == noreg) {
> 
> Is there a problem if `L_success == nullptr && result_reg == noreg` and there aren't any secondary supers?
> In that case we would reach here with CR0.eq from L2134 and we would fallthrough with CR0.eq. Due to the change in `C1StubId::slow_subtype_check_id` we would return there with CR0.eq.

This is a reproducer:

public class InstanceOfTest {

    public static interface TestInterfaceI {
    }

    public static class TestClassNegative {
    }

    public static void main(String[] args) {
        Object obj = new TestClassNegative();
        for (int i = 100_000; i > 0; i--) {
            dontinline_testMethod(obj);
        }
        boolean result = dontinline_testMethod(obj);
        System.out.println("result: " + result);
    }

    static boolean dontinline_testMethod(Object obj) {
        return obj instanceof TestInterfaceI;
    }
}


./jdk/bin/java -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable InstanceOfTest
result: true

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1925725737

From stuefe at openjdk.org  Wed Jan 22 18:42:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 22 Jan 2025 18:42:48 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v4]
In-Reply-To: <OunmgpIoKD5HkEeaQO1WrQB5F8YCTyacMf60n66cfZs=.d101f790-cd86-4124-b9d6-518865193525@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
 <sSx7z7h1RkzZ2e4CI9vXiBbfttmB-JMei9xCuKBKhP8=.6ad929de-ab00-4942-80ea-e66b0562b9a7@github.com>
 <OunmgpIoKD5HkEeaQO1WrQB5F8YCTyacMf60n66cfZs=.d101f790-cd86-4124-b9d6-518865193525@github.com>
Message-ID: <hjxux8B_XGfT2hcukOXQ3w8dwbXeAkSSsLqp_90RlJM=.1d753481-de7c-4cfc-883b-d86d68bf4a39@github.com>

On Wed, 22 Jan 2025 17:31:10 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix test
>
> src/hotspot/share/cds/metaspaceShared.cpp line 1373:
> 
>> 1371: static constexpr uint64_t protzone_tag       = 0x50524F545A4F4E45ULL; // "PROTZONE"
>> 1372: static constexpr uint64_t protzone_tag_start = 0x2D3E2D3E50524F54ULL; // "->->PROT"
>> 1373: static constexpr uint64_t protzone_tag_end   = 0x50524F543C2D3C2DULL; // "PROT<-<-"
> 
> Is this endianness dependent?

I don't think so. We only read archives created on the same architecture. The only thing that could change would be the page size.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23190#discussion_r1925798765

From gziemski at openjdk.org  Wed Jan 22 19:44:41 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 22 Jan 2025 19:44:41 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v6]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <mlGTFsF6XjnqcWa6ukvgGBzYBrHqIC12GbTCJ244s_k=.eafdb899-074d-4ef3-80e9-3138e2d76645@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
> 
> VM interacts with these through these APIs:
> 
>   ```
>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>   NMT_LogRecorder::logThreadName(name);
>   NMT_LogRecorder::finish();
> 
> 
> For controlling their liveness and through their "log" APIs for the actual logging.
> 
> For memory logger those are:
> 
> 
>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
> 
> 
> and for virtual memory logger, those are:
> 
> 
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
> 
> 
> That's the entirety of the surface area of the new code.
> 
> The actual implementation extends one existing VM API:
> 
> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
> `
> 
> and adds a few APIs to permit_forbidden_function.hpp:
> 
> 
>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
> 
>  #if defined(LINUX)
>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>  #elif defined(WINDOWS)
>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>  #elif defined(__APPLE__)
>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>  #endif
> 
> 
> Those are need if we want to calculate the memory overhead
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/...

Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision:

 - forgot to remove debug code
 - fix mem overhead reporting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/bf22bd7f..c71d1277

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=04-05

  Stats: 77 lines in 2 files changed: 22 ins; 33 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From gziemski at openjdk.org  Wed Jan 22 20:37:33 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 22 Jan 2025 20:37:33 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v7]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <krk4yOeZOqOITLcUn5Wdrz7G_GP3hf8xJgR0hTuH_7k=.a816fd8f-88ba-4681-a438-3d565fe0646b@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
> 
> VM interacts with these through these APIs:
> 
>   ```
>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>   NMT_LogRecorder::logThreadName(name);
>   NMT_LogRecorder::finish();
> 
> 
> For controlling their liveness and through their "log" APIs for the actual logging.
> 
> For memory logger those are:
> 
> 
>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
> 
> 
> and for virtual memory logger, those are:
> 
> 
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
> 
> 
> That's the entirety of the surface area of the new code.
> 
> The actual implementation extends one existing VM API:
> 
> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
> `
> 
> and adds a few APIs to permit_forbidden_function.hpp:
> 
> 
>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
> 
>  #if defined(LINUX)
>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>  #elif defined(WINDOWS)
>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>  #elif defined(__APPLE__)
>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>  #endif
> 
> 
> Those are need if we want to calculate the memory overhead
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/...

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  add memory summary per NMT category

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/c71d1277..0567f3b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=05-06

  Stats: 20 lines in 1 file changed: 16 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From lmesnik at openjdk.org  Wed Jan 22 20:43:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Jan 2025 20:43:04 GMT
Subject: RFR: 8318098: Update jfr tests with corresponding requires flags
 [v3]
In-Reply-To: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com>
References: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com>
Message-ID: <fINaRkBhhZqETw4T5QNgOAwPiy4LKtxpymr6ilyfinI=.b32c07fd-7af7-4076-a920-d8967b513f34@github.com>

> There are few JFR tests are failing with -Xcomp and compiler stress flags. 
> I added requires tag when tests are incompatible with corresponding mode:
> 1) huge stacks and DeoptimieALot cause timeout
> 2) WB controlled compilation doesn't work with Xcomp
> 3) Arguments tests might be sensitive to aby flags and should be flagless
> and excluded a 2 groups of tests failing with Xcomp for further invesitigation.
> 
> The drivers for these are following bug escapes because of JFR was not tested with VM flags:
> https://bugs.openjdk.org/browse/JDK-8340586
> https://bugs.openjdk.org/browse/JDK-8344199
> https://bugs.openjdk.org/browse/JDK-8340826
> https://bugs.openjdk.org/browse/JDK-8343893
> 
> The bug
> https://bugs.openjdk.org/browse/JDK-8347463
> is also filed while executing jfr tests with different VM flags.
> 
> 
> So now jfr tests support all flags used for testing  in CI with them.
> The bug
> https://bugs.openjdk.org/browse/JDK-8318098
> has a linked all the product issues found by running JFR tests with flags and explanation why is it needed.

Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into 8318098
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8318098
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8318098
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8318098
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8318098
 - 8318098: Update jfr tests with corresponding requires flags
 - Merge branch 'master' of https://github.com/lmesnik/jdk
 - 8344051

-------------

Changes: https://git.openjdk.org/jdk/pull/22249/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22249&range=02
  Stats: 21 lines in 8 files changed: 21 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22249.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22249/head:pull/22249

PR: https://git.openjdk.org/jdk/pull/22249

From dholmes at openjdk.org  Wed Jan 22 21:02:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 21:02:00 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <vQSFQilU7ukjazHSDGhoFFkxv5FlTQ2hsuh_cF28zK0=.cff0d302-b74d-40c0-9716-251f62541488@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

@earthling-amzn and @ysramakrishna  JDK 24 is already in RDP2 and as such this P3 issue should not have been integrated there. Did you really intend to send this to jdk24u?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23221#issuecomment-2608255604

From dholmes at openjdk.org  Wed Jan 22 21:18:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 21:18:47 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide [v2]
In-Reply-To: <JChUJHsXOxUFNs-FMGcSM2MsbsGjGqg31cNWsLWQqnA=.9a999154-b540-41a9-9fb7-6fb428cc9a5c@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
 <JChUJHsXOxUFNs-FMGcSM2MsbsGjGqg31cNWsLWQqnA=.9a999154-b540-41a9-9fb7-6fb428cc9a5c@github.com>
Message-ID: <w1CERraQ1IfVfaENATMP7HGgvXot8F0jGvD6h_k7d3M=.1ee005b4-2c11-4bd0-847f-5ca32e2f84b5@github.com>

On Wed, 22 Jan 2025 09:34:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need for HotSpot devs to include the precompiled.hpp. This is the PR to reflect that.
>> 
>> I know that there is some process around updating the style guide, but I can't find it, so I'm starting with a plain PR.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update hotspot-style.md
>  - Update hotspot-style.html

This update looks good to me.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23210#pullrequestreview-2568295889

From mdoerr at openjdk.org  Wed Jan 22 21:52:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 Jan 2025 21:52:02 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v2]
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <pZxuZDtY9LpVhABPYPyBHfrmm1lgh34DY7xb8_oUh4w=.8f2d9194-4a41-4b23-887a-13aa7c6513bd@github.com>

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Remove early return from check_klass_subtype_slow_path.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22881/files
  - new: https://git.openjdk.org/jdk/pull/22881/files/f7c1b79c..37789b38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22881&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22881&range=00-01

  Stats: 13 lines in 2 files changed: 5 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22881/head:pull/22881

PR: https://git.openjdk.org/jdk/pull/22881

From mdoerr at openjdk.org  Wed Jan 22 21:55:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 Jan 2025 21:55:47 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v2]
In-Reply-To: <pZxuZDtY9LpVhABPYPyBHfrmm1lgh34DY7xb8_oUh4w=.8f2d9194-4a41-4b23-887a-13aa7c6513bd@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <pZxuZDtY9LpVhABPYPyBHfrmm1lgh34DY7xb8_oUh4w=.8f2d9194-4a41-4b23-887a-13aa7c6513bd@github.com>
Message-ID: <WWZ-HvS9b9GoHr5_-5l58Am3G8Y5hqXaJAN_QPCsc7Q=.7caa8fc4-f2b7-4eea-9362-702e3eeb4e5d@github.com>

On Wed, 22 Jan 2025 21:52:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
>> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
>> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
>> 
>> Performance difference can be observed when C2 is disabled (measured on Power10):
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
>> 
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
>> 
>> 
>> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove early return from check_klass_subtype_slow_path.

Thanks for looking at this! The condition was wrong. I have improved the design of `check_klass_subtype_slow_path_linear` and removed the early return by "blr". Please take a look at https://github.com/openjdk/jdk/pull/22881/commits/37789b381be41ca3add115ac03f3e186d884fd5c.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22881#issuecomment-2608348179

From mdoerr at openjdk.org  Wed Jan 22 22:02:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 Jan 2025 22:02:46 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v2]
In-Reply-To: <zDQHpaeDpuUrxUMpjOlaNcir9WbBLEc7MlNT4qYKoOA=.e73dc9e3-dabe-4ae7-943e-d30ddecc1d29@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <xJ6McgRAGAME1e7jGmE-Rg3-hzkqTKraxAh5-vgSPz4=.be7dd78d-8902-4fb3-9199-cd915fee645f@github.com>
 <pAErLf6MXbz_0xFLKjf3IfzGaRJ1U1k6rf3duhELl_o=.1769911b-aea0-4049-85b9-0b86cbe7ca91@github.com>
 <zDQHpaeDpuUrxUMpjOlaNcir9WbBLEc7MlNT4qYKoOA=.e73dc9e3-dabe-4ae7-943e-d30ddecc1d29@github.com>
Message-ID: <uo5qWQZZs4ZMAJ5qrXQEwR4Y30bUih1TMhQjj2wW65c=.d4446994-b1e4-4d29-a522-5ed81d4e70e8@github.com>

On Wed, 22 Jan 2025 12:05:04 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The correct result is always in CR0 with this PR (unless a label or result GP reg is provided).
>> "return" means "blr", here. That can optionally be used in case of success. In this case, CR0 is always "eq".
>> I've moved the `crandc` instruction into `check_klass_subtype_slow_path_linear` which contains such a "blr" for a success case. This way, the linear version works exactly as before.
>> The new code `check_klass_subtype_slow_path_table` doesn't use "blr". That's why I added "may" to the comment.
>
> This is extremely hard to see.
> L2154 with the "blr" in `check_klass_subtype_slow_path_linear` looks redundant to me. It should be removed if you agree.
> The comment here should be adapted then too.
> Also the comment at macroAssembler_ppc.cpp:2258 needs to be adapted because fallthrough from `check_klass_subtype_slow_path` does not mean "not successful". `L_failure` could be renamed to `L_fast_path_failure`

I think `L_failure` is correct. And it's used the same way on all platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1926036237

From kcr at openjdk.org  Wed Jan 22 22:07:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Jan 2025 22:07:47 GMT
Subject: [jdk24] RFR: 8343978: Update the default value of
 CodeEntryAlignment for Ampere-1A and 1B
In-Reply-To: <Q2DyEyVRb9J2_izU0NignmRL5HuB8IPRh3xO9o99yVw=.30ea154e-ddf3-4125-8dd8-88c381e31ea0@github.com>
References: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
 <Q2DyEyVRb9J2_izU0NignmRL5HuB8IPRh3xO9o99yVw=.30ea154e-ddf3-4125-8dd8-88c381e31ea0@github.com>
Message-ID: <wX3NFWwgsIQluDWVZclbOJH8w-Q6cTCljzp1agSn_Vs=.b21cb0f5-f64e-46d1-8d89-9aa6aa6d22e2@github.com>

On Wed, 22 Jan 2025 03:08:46 GMT, Liming Liu <lliu at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit 89ee1a55 from the openjdk/jdk repository.
>> 
>> The commit being backported was authored by Liming Liu on 9 Jan 2025 and was reviewed by Dean Long and Vladimir Kozlov.
>> 
>> Thanks!
>
> Hi @dean-long, I think it is allowed according to the following page:
> https://openjdk.org/jeps/3#rdp-2

@limingliu-ampere No, it does not meet the RDP2 criteria. This PR should be closed. It is not a candidate for backporting to JDK 24 now that we are in RDP2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23027#issuecomment-2608366769

From coleenp at openjdk.org  Wed Jan 22 23:43:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jan 2025 23:43:45 GMT
Subject: RFR: 8348240: Remove
 SystemDictionaryShared::lookup_super_for_unregistered_class()
In-Reply-To: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
References: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
Message-ID: <KhqvBvtD4r-B12sFgx3IqdQjXa1VHB9j9DL6w4ecyOA=.04cc443d-9ca4-44b1-af9a-b48b7b7a219b@github.com>

On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there.
> 
> The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java.
> 
> ### How this works:
> 
> For example, let's assume you have the following classfiles in foo.jar:
> 
> 
> interface MyInterface1 {}
> interface MyInterface2 {}
> class MyClass extends Object implements MyInterface1, MyInterface2 {}
> 
> 
> The CDS classlist file can look like this:
> 
> 
> java/lang/Object id: 1
> MyInterface1: id: 2 super: 1 source: foo.jar
> MyInterface2: id: 3 super: 1 source: foo.jar
> MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar
> 
> 
> When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters:
> 
> - `name` = "MyClass"
> - `superClass` = java.lang.Object
> - `interfaces` = {MyInterface1, MyInterface2} 
> 
> `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`.

I like this change a lot, except for the name "unregistered" but that can be taken up in some other way.  If I understand correctly, this just creates a dummy class loader to load the classes you want to share from the non-boot, app or system class loader.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23226#pullrequestreview-2568515552

From ccheung at openjdk.org  Thu Jan 23 01:10:54 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 23 Jan 2025 01:10:54 GMT
Subject: RFR: 8348240: Remove
 SystemDictionaryShared::lookup_super_for_unregistered_class()
In-Reply-To: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
References: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
Message-ID: <JlJNLsTmB3T3NWVHLq-D8ss0O5QEIFECrQZ_vLE7XOo=.4586488b-5b8e-4223-b9bf-bc915d8b789a@github.com>

On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there.
> 
> The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java.
> 
> ### How this works:
> 
> For example, let's assume you have the following classfiles in foo.jar:
> 
> 
> interface MyInterface1 {}
> interface MyInterface2 {}
> class MyClass extends Object implements MyInterface1, MyInterface2 {}
> 
> 
> The CDS classlist file can look like this:
> 
> 
> java/lang/Object id: 1
> MyInterface1: id: 2 super: 1 source: foo.jar
> MyInterface2: id: 3 super: 1 source: foo.jar
> MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar
> 
> 
> When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters:
> 
> - `name` = "MyClass"
> - `superClass` = java.lang.Object
> - `interfaces` = {MyInterface1, MyInterface2} 
> 
> `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`.

Looks like a good cleanup. I have couple of comments.

src/hotspot/share/cds/unregisteredClasses.cpp line 72:

> 70: 
> 71:   JavaValue result(T_OBJECT);
> 72:   JavaCallArguments args(2);

Should the 2 be increased to 3?

src/hotspot/share/classfile/vmSymbols.hpp line 742:

> 740:   template(toFileURL_name,                                  "toFileURL")                                          \
> 741:   template(toFileURL_signature,                             "(Ljava/lang/String;)Ljava/net/URL;")                 \
> 742:   template(url_array_classloader_void_signature,            "([Ljava/net/URL;Ljava/lang/ClassLoader;)V")          \

I think you can also remove the following since `URLClassLoader` is not used directly anymore:
`do_klass(URLClassLoader_klass,                        java_net_URLClassLoader                               ) `

-------------

PR Review: https://git.openjdk.org/jdk/pull/23226#pullrequestreview-2568629771
PR Review Comment: https://git.openjdk.org/jdk/pull/23226#discussion_r1926215557
PR Review Comment: https://git.openjdk.org/jdk/pull/23226#discussion_r1926205535

From iklam at openjdk.org  Thu Jan 23 02:04:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 Jan 2025 02:04:33 GMT
Subject: RFR: 8348240: Remove
 SystemDictionaryShared::lookup_super_for_unregistered_class() [v2]
In-Reply-To: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
References: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
Message-ID: <eS5vOxcF2Pyb-eLXmPC1W-jf6LfugC0IUNxX7QAM7qI=.774cff51-1a04-41b7-ada3-18cf612eb1d9@github.com>

> I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there.
> 
> The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java.
> 
> ### How this works:
> 
> For example, let's assume you have the following classfiles in foo.jar:
> 
> 
> interface MyInterface1 {}
> interface MyInterface2 {}
> class MyClass extends Object implements MyInterface1, MyInterface2 {}
> 
> 
> The CDS classlist file can look like this:
> 
> 
> java/lang/Object id: 1
> MyInterface1: id: 2 super: 1 source: foo.jar
> MyInterface2: id: 3 super: 1 source: foo.jar
> MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar
> 
> 
> When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters:
> 
> - `name` = "MyClass"
> - `superClass` = java.lang.Object
> - `interfaces` = {MyInterface1, MyInterface2} 
> 
> `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`.

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 three additional commits since the last revision:

 - Merge branch 'master' into 8348240-remove-lookup_super_for_unregistered_class
 - @calvinccheung comments
 - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23226/files
  - new: https://git.openjdk.org/jdk/pull/23226/files/ca801052..e03dfc50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23226&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23226&range=00-01

  Stats: 1256 lines in 46 files changed: 574 ins; 462 del; 220 mod
  Patch: https://git.openjdk.org/jdk/pull/23226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23226/head:pull/23226

PR: https://git.openjdk.org/jdk/pull/23226

From iklam at openjdk.org  Thu Jan 23 02:28:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 Jan 2025 02:28:48 GMT
Subject: RFR: 8348240: Remove
 SystemDictionaryShared::lookup_super_for_unregistered_class() [v2]
In-Reply-To: <JlJNLsTmB3T3NWVHLq-D8ss0O5QEIFECrQZ_vLE7XOo=.4586488b-5b8e-4223-b9bf-bc915d8b789a@github.com>
References: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
 <JlJNLsTmB3T3NWVHLq-D8ss0O5QEIFECrQZ_vLE7XOo=.4586488b-5b8e-4223-b9bf-bc915d8b789a@github.com>
Message-ID: <3eKO2PFbnDRP4UFSSMDPeNJYNj_HL8y4E3GpVpHRTIk=.613bef4f-e927-4d68-8a2f-575d1c851868@github.com>

On Thu, 23 Jan 2025 01:04:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8348240-remove-lookup_super_for_unregistered_class
>>  - @calvinccheung comments
>>  - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class()
>
> src/hotspot/share/cds/unregisteredClasses.cpp line 72:
> 
>> 70: 
>> 71:   JavaValue result(T_OBJECT);
>> 72:   JavaCallArguments args(2);
> 
> Should the 2 be increased to 3?

I changed it to 3. I wonder why the 2 didn't fail. It turns out that `JavaCallArguments` reserves at least 8 slots.

> src/hotspot/share/classfile/vmSymbols.hpp line 742:
> 
>> 740:   template(toFileURL_name,                                  "toFileURL")                                          \
>> 741:   template(toFileURL_signature,                             "(Ljava/lang/String;)Ljava/net/URL;")                 \
>> 742:   template(url_array_classloader_void_signature,            "([Ljava/net/URL;Ljava/lang/ClassLoader;)V")          \
> 
> I think you can also remove the following since `URLClassLoader` is not used directly anymore:
> `do_klass(URLClassLoader_klass,                        java_net_URLClassLoader                               ) `

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23226#discussion_r1926270349
PR Review Comment: https://git.openjdk.org/jdk/pull/23226#discussion_r1926270410

From dholmes at openjdk.org  Thu Jan 23 03:04:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Jan 2025 03:04:55 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v7]
In-Reply-To: <t5cnxy2InXJLLVAxoQIPMWUX0WgkEF4Ls0Q16f_-oYQ=.246363bc-3cb8-47b4-83bb-a681711896fa@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <GDRx6XhicQAtd5RKTvco86EIrz3hyCB1cjYvLcQ6rtA=.757b1b51-2786-4c3e-b974-ccaf3398b832@github.com>
 <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com>
 <g_StbwSW8Tk2FDJHx2Kp8FNUVmjF_-2qkskRAZI3Fm4=.aa8ea6fc-1696-4b63-8b72-99df7c052a38@github.com>
 <t5cnxy2InXJLLVAxoQIPMWUX0WgkEF4Ls0Q16f_-oYQ=.246363bc-3cb8-47b4-83bb-a681711896fa@github.com>
Message-ID: <nQLcLXs-q6g46XAlG8RYLZEZoXePKoUtR4QzptG985M=.6891f417-485b-4171-b794-67178632f4d2@github.com>

On Wed, 22 Jan 2025 15:43:20 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We do have some terminal flags like `-version` and `-Xshare:dump`, but generally the VM does not have magic flags that behave that way. I still don't have a clear picture of the different phases involved with this work. We have a recording phase. Then we have the benchmarking phase that does something (I can't figure out what) with the recording. Then we have the Java tool which does ... what?
>> 
>> In any case I have concerns about how the "benchmarking" is initiated.
>
> The problem is I want to record every os::malloc(), so I need locks way before they are initialized in the VM.

I think the above comment ended up in the wrong discussion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1926294903

From lliu at openjdk.org  Thu Jan 23 03:35:59 2025
From: lliu at openjdk.org (Liming Liu)
Date: Thu, 23 Jan 2025 03:35:59 GMT
Subject: [jdk24] Withdrawn: 8343978: Update the default value of
 CodeEntryAlignment for Ampere-1A and 1B
In-Reply-To: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
References: <qx11Dw0gfPtcQ6HDVhvma5TcetEBeK_fqaZ99QSEIc4=.a91b4d64-be29-470e-8475-7af888368297@github.com>
Message-ID: <ubsNCQWHgMmYzyR7S7CQFxtdm0JXxmBUFaHj6DE6GsY=.23c45530-5bbf-4703-a99e-8f554f770bf3@github.com>

On Fri, 10 Jan 2025 07:42:33 GMT, Liming Liu <lliu at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 89ee1a55 from the openjdk/jdk repository.
> 
> The commit being backported was authored by Liming Liu on 9 Jan 2025 and was reviewed by Dean Long and Vladimir Kozlov.
> 
> Thanks!

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23027

From cslucas at openjdk.org  Thu Jan 23 04:58:46 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 23 Jan 2025 04:58:46 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v2]
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <VwqgWCSVMnDqsnmjkjwyv5dvkle51XH3PTJSJqeN-TE=.51e7e425-87d2-4540-8cfa-1697571cfb75@github.com>

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Addressing PR comments: some refactorings, ppc fix, off-by-one fix.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23170/files
  - new: https://git.openjdk.org/jdk/pull/23170/files/87a9993a..124c5f70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=00-01

  Stats: 82 lines in 9 files changed: 25 ins; 45 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170

PR: https://git.openjdk.org/jdk/pull/23170

From dholmes at openjdk.org  Thu Jan 23 05:03:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Jan 2025 05:03:45 GMT
Subject: RFR: 8334320: Replace
 vmTestbase/metaspace/share/TriggerUnloadingWithWhiteBox.java with
 ClassUnloadCommon from testlibrary
In-Reply-To: <Ksm0Ks2LeRw5B-pm2VL6tuQg11d5ivEMftSKoeceTso=.4da2555a-e6ba-4f83-a2ee-5a0da1740afc@github.com>
References: <Ksm0Ks2LeRw5B-pm2VL6tuQg11d5ivEMftSKoeceTso=.4da2555a-e6ba-4f83-a2ee-5a0da1740afc@github.com>
Message-ID: <a8Qwt9wZYtmryxkRO90PEeOJojN4tdTRJOcnQcthCIo=.ea06934a-fbd0-49cc-86cd-a76e365aaada@github.com>

On Fri, 17 Jan 2025 13:43:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Rename and make TriggerUnloadingWithWhiteBox call ClassUnloadCommon.triggerUnloading() instead of WB.fullGC().

I think it reasonable to reduce direct dependencies on WhiteBox, but I don't see any point in having `TriggerUnloadingWithFullGC` when the user of it can use `triggerUnloading()` directly. This framework may have been used more broadly in the past but today I see only a single implementation of `TriggerUnloadingHelper` so it too seems unnecessary. There is really only one reliable way to trigger class unloading and that is ultimately via WhiteBox.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23174#pullrequestreview-2568865846

From cnorrbin at openjdk.org  Thu Jan 23 05:07:49 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 23 Jan 2025 05:07:49 GMT
Subject: Integrated: 8337997: MallocHeader description refers to non-existent
 NMT state "minimal"
In-Reply-To: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
References: <bvG7Oo3ptT5utnbDLDV1Eb6chka4ydBnH-As2-zWKHE=.0f5e0756-ad48-431f-8402-c0090083c137@github.com>
Message-ID: <oAQDlkgoTsFzq7M7Itp9114wwrACVgUB5yTlxmddI4Q=.592ab715-b8e4-421b-885a-d010746a6bd8@github.com>

On Mon, 20 Jan 2025 15:16:10 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Small fix to a comment in `mallocHeader.hpp`, which referenced a non-existant NMT state. This has been changed to the correct (existing) state.

This pull request has now been integrated.

Changeset: 66513ddb
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66513ddbe97b56e3633abdd0922dd54ab42d5b28
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8337997: MallocHeader description refers to non-existent NMT state "minimal"

Reviewed-by: jsjolen, zgu

-------------

PR: https://git.openjdk.org/jdk/pull/23199

From cslucas at openjdk.org  Thu Jan 23 05:45:43 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 23 Jan 2025 05:45:43 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
Message-ID: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>

> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
> 
> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
> 
> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
> 
> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
> 
> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
> 
> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.

Cesar Soares Lucas 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 master
 - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
 - Relocation of Card Tables

-------------

Changes: https://git.openjdk.org/jdk/pull/23170/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23170&range=02
  Stats: 318 lines in 30 files changed: 161 ins; 95 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/23170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23170/head:pull/23170

PR: https://git.openjdk.org/jdk/pull/23170

From cslucas at openjdk.org  Thu Jan 23 05:45:43 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 23 Jan 2025 05:45:43 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <Q_Vj8HgbyXfh-N4-PCFksQb1iW3c6TAquTtz2odKRDw=.3a0652a2-bd39-4aeb-b4cd-640592902734@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <XOIZSvkw-z5NfTywxOnqWSPJbMrYo7Bek2rTOVAYXaY=.03258f45-0228-4b8b-8688-1a5796e941cb@github.com>
 <soLuE9bJ60nFyb_OSeyq-OBqq3uJLnTtKAHfUawfMY0=.778259ab-684a-4571-b1ef-91f9b3a1b643@github.com>
 <Q_Vj8HgbyXfh-N4-PCFksQb1iW3c6TAquTtz2odKRDw=.3a0652a2-bd39-4aeb-b4cd-640592902734@github.com>
Message-ID: <txKeuhHhBdvZiQtPVXMGE0WzUfqrXEnljxYxc1f4ypY=.04c0e006-da59-47b0-a9e7-18b55fa9e338@github.com>

On Wed, 22 Jan 2025 17:00:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > I do wonder if you can avoid a lot if not all arch-specific changes, if Shenandoah barrier set: a) does not use `MacroAssembler::load_byte_map_base` directly; b) returns deliberately bad pointer from `byte_map_base()`, so that C2 matcher would never match, and accidental use of `byte_map_base()` would cleanly crash.
> > 
> > 
> > @shipilev - are you suggesting to patch all `shenandoahBarrierSetAssembler_*` backend specific files to not use `load_byte_map`? It looks like we would end up in a similar situation if I go with the approach that you're suggesting - if I'm understanding it correctly.
> 
> Yes, I was thinking that if Shenandoah cannot use super-class `load_byte_map` and needs its own implementation, then it makes sense that Shenandoah barrier set should be using a special implementation directly instead of hacking the super-class implementation?
> 
> But mostly I want to avoid unnecessary changes in files that are not related to Shenandoah :)

@shipilev - Please, take a look at the latest changes when you can.

> It would be great if you can include some performance numbers either in this PR or, preferably, in the JBS ticket.

@ysramakrishna - I'm working on that!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2608907272

From fyang at openjdk.org  Thu Jan 23 06:03:54 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 23 Jan 2025 06:03:54 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
Message-ID: <0xOVSqgUtYDbmtS7QXK9pKbnJuCD-KH43b_0cOOxkXk=.f491a743-3385-40e5-8f28-895e3a79efd3@github.com>

On Wed, 22 Jan 2025 14:29:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider!
>> 
>> This patch the Zfa zli floating point immediate load.
>> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
>> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
>> 
>> When using one of the 32 'popular' floats we can now materialze them without a load.
>> E.g.
>> `float f = f1 * 0.5 + f2 * 2.0;`
>> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
>> 
>> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
>> 
>> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
>> 
>> Passes:
>> ./test/jdk/java/lang/Math
>> ./test/hotspot/jtreg/compiler/floatingpoint/
>> ./test/jdk/java/util/Formatter/
>> ./test/jdk/java/lang/Float/
>> ./test/jdk/java/lang/Double/
>> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> ./test/hotspot/jtreg/compiler/eliminateAutobox/
>> ./test/hotspot/jtreg/vmTestbase/jit/
>> 
>> Running tier1
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zfa
>  - Merge branch 'master' into zfa
>  - EXPERIMENTAL
>  - Merge branch 'master' into zfa
>  - Merge branch 'master' into zfa
>  - Flip bool static decl
>  - Merge branch 'master' into zfa
>  - Baseline

Thanks for the update. Seems fine to me modulo one minor comment.

src/hotspot/cpu/riscv/vm_version_riscv.hpp line 160:

> 158:   decl(ext_Zbs         , "Zbs"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZbs))         \
> 159:   decl(ext_Zcb         , "Zcb"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZcb))         \
> 160:   decl(ext_Zfa         , "Zfa"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZfa))         \

Are we auto-enabling an experimental feature?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23171#pullrequestreview-2568931169
PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1926407162

From lmesnik at openjdk.org  Thu Jan 23 06:09:27 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 23 Jan 2025 06:09:27 GMT
Subject: RFR: 8348367: Remove hotspot_not_fast_compiler and
 hotspot_slow_compiler test groups
Message-ID: <IBwkV7qAT-Ot70l8ZM90AFm99ezwKXjZy4lG1gXfbuw=.90f33d1e-d73f-4759-890c-5819e5d26846@github.com>

Test groups
hotspot_not_fast_compiler and hotspot_slow_compiler test
were used by Oracle. However, now tier2/tier3 are used instead.

So fix remove groups. and add exclusion of "slow" tests from tier1 groups. The content remains the same except 
-compiler/memoryinitialization/ZeroTLABTest.java 
int tier1_compiler_3.


The tier1/2/3 are organized similar to tiers in other groups where
tier1 = set of groups 
  - some long tests/groups
tier2 = set of groups
  - some long tests/groups
 - tier1
 tier3 =
  hotspot_compiler
 - tier1
 - tier2


The  test group
 compiler/codegen/ \
was in the tier1 and tier2, so should be removed it from tier2, not tests are affected.

-------------

Commit messages:
 - 8348367: Remove hotspot_not_fast_compiler and hotspot_slow_compiler test groups

Changes: https://git.openjdk.org/jdk/pull/23253/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23253&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348367
  Stats: 28 lines in 1 file changed: 5 ins; 19 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23253/head:pull/23253

PR: https://git.openjdk.org/jdk/pull/23253

From stuefe at openjdk.org  Thu Jan 23 06:15:24 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Jan 2025 06:15:24 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v5]
In-Reply-To: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
Message-ID: <h4SWSe9QZjelrN2veT18VjIPcjd60EDgf9cbSLe61H0=.31012b2e-054e-4f5d-a3aa-5d344f432319@github.com>

> If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 
> 
> Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.
> 
> We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.
> 
> This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.
> 
> Additionally, the patch provides a helpful output in the register/stack section, e.g:
> 
> 
> RDI=0x0000000800000000 points into nKlass protection zone
> 
> 
> 
> Testing: 
> - GHAs.
> - I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
> - I tested manually on Windows x64
> - I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)
> 
> -- Update 2024-01-22 -- 
> I added a jtreg test that is more thorough than a gtest (also scans the produced hs-err file)

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  fix whitespace error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23190/files
  - new: https://git.openjdk.org/jdk/pull/23190/files/84b0d8f4..0840cf07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23190&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23190.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23190/head:pull/23190

PR: https://git.openjdk.org/jdk/pull/23190

From stuefe at openjdk.org  Thu Jan 23 06:15:24 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Jan 2025 06:15:24 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v4]
In-Reply-To: <sSx7z7h1RkzZ2e4CI9vXiBbfttmB-JMei9xCuKBKhP8=.6ad929de-ab00-4942-80ea-e66b0562b9a7@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
 <sSx7z7h1RkzZ2e4CI9vXiBbfttmB-JMei9xCuKBKhP8=.6ad929de-ab00-4942-80ea-e66b0562b9a7@github.com>
Message-ID: <jHAt3W0rcnSKzfu-c8AEbjVZoPFtrKWsy2CCSQRX5h8=.ded3d4fc-3473-4cac-8905-d1d2b70c4cb9@github.com>

On Wed, 22 Jan 2025 16:41:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 
>> 
>> Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.
>> 
>> We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.
>> 
>> This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.
>> 
>> Additionally, the patch provides a helpful output in the register/stack section, e.g:
>> 
>> 
>> RDI=0x0000000800000000 points into nKlass protection zone
>> 
>> 
>> 
>> Testing: 
>> - GHAs.
>> - I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
>> - I tested manually on Windows x64
>> - I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)
>> 
>> -- Update 2024-01-22 -- 
>> I added a jtreg test that is more thorough than a gtest (also scans the produced hs-err file)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix test

@iklam, could you please take a look if you got time?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23190#issuecomment-2608945090

From iklam at openjdk.org  Thu Jan 23 07:01:46 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 Jan 2025 07:01:46 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v5]
In-Reply-To: <h4SWSe9QZjelrN2veT18VjIPcjd60EDgf9cbSLe61H0=.31012b2e-054e-4f5d-a3aa-5d344f432319@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
 <h4SWSe9QZjelrN2veT18VjIPcjd60EDgf9cbSLe61H0=.31012b2e-054e-4f5d-a3aa-5d344f432319@github.com>
Message-ID: <KSgJ-O3mIgwqlyaCaCku1Tun-znbMPELRtcNMET1Xw8=.28a36a6f-89a2-452a-b334-c94ce13b7ad4@github.com>

On Thu, 23 Jan 2025 06:15:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> If we wrongly decode an nKlass of `0`, and the nKlass encoding base is not NULL (typical for most cases that run with CDS enabled), the resulting pointer points to the start of the Klass encoding range. That area is readable. If CDS is enabled, it will be at the start of the CDS metadata archive. If CDS is off, it is at the start of the class space. 
>> 
>> Now, both CDS and class space allocate a safety buffer at the start to prevent Klass structures from being located there. However, that memory is still readable, so we can read garbage data from that area. In the case of CDS, that area is just 16 bytes, after that come real data. Since Klass is large, most accesses will read beyond the 16-byte zone.
>> 
>> We should protect the first page in the narrow Klass encoding range to make analysis of errors like this easier. Especially in release builds where decode_not_null does not assert. We already use a similar technique in the heap, and most OSes protect the zero page for the same reason.
>> 
>> This patch does that. Now, decoding an `0` nKlass and then using the result `Klass` - calling virtual functions or accessing members - crashes right away.
>> 
>> Additionally, the patch provides a helpful output in the register/stack section, e.g:
>> 
>> 
>> RDI=0x0000000800000000 points into nKlass protection zone
>> 
>> 
>> 
>> Testing: 
>> - GHAs.
>> - I tested the patch manually on x64 Linux for both CDS on, CDS off and zero-based encoding, CDS off and non-zero-based encoding.
>> - I tested manually on Windows x64
>> - I also prepared an automatic gtest, but that needs some preparatory work on the gtest suite first to work (see https://bugs.openjdk.org/browse/JDK-8348029)
>> 
>> -- Update 2024-01-22 -- 
>> I added a jtreg test that is more thorough than a gtest (also scans the produced hs-err file)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix whitespace error

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/archiveBuilder.cpp line 370:

> 368:     // The region that will be located at the bottom of the encoding range at runtime shall have
> 369:     // space for a protection zone.
> 370:     MetaspaceShared::allocate_and_mark_protection_zone(rw_region());

This will add up 64KBs of space to the front of the RW region, increasing the file size. Could you try changing the `CDSFileMapRegion::_mapping_offset` of the RW region to `MetaspaceShared::core_region_alignment()` so we can avoid storing the data in the CDS file?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23190#pullrequestreview-2569004078
PR Review Comment: https://git.openjdk.org/jdk/pull/23190#discussion_r1926454503

From rehn at openjdk.org  Thu Jan 23 07:13:49 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 23 Jan 2025 07:13:49 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <0xOVSqgUtYDbmtS7QXK9pKbnJuCD-KH43b_0cOOxkXk=.f491a743-3385-40e5-8f28-895e3a79efd3@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
 <0xOVSqgUtYDbmtS7QXK9pKbnJuCD-KH43b_0cOOxkXk=.f491a743-3385-40e5-8f28-895e3a79efd3@github.com>
Message-ID: <a4B9iw3kCRhK_8Tjt5Hgdz99dtuEaOVyMtPhQyKOS5k=.f9515188-2df2-4ca1-b21d-6243cac5d887@github.com>

On Thu, 23 Jan 2025 05:58:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into zfa
>>  - Merge branch 'master' into zfa
>>  - EXPERIMENTAL
>>  - Merge branch 'master' into zfa
>>  - Merge branch 'master' into zfa
>>  - Flip bool static decl
>>  - Merge branch 'master' into zfa
>>  - Baseline
>
> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 160:
> 
>> 158:   decl(ext_Zbs         , "Zbs"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZbs))         \
>> 159:   decl(ext_Zcb         , "Zcb"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZcb))         \
>> 160:   decl(ext_Zfa         , "Zfa"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZfa))         \
> 
> Are we auto-enabling an experimental feature?

No, as Zfa is not mapped in RiscvHwprobe::add_features_from_query_result() I don't see how it would auto enbled?

 UPDATE_DEFAULT only updates "Use flag" after the extension, if it is default, i.e. not set by user, no?

As we have a two step mechanism hwprobe -> extensions flag -> Use flag.

But if you want I can do it the other way around, add it to hwprobe but do not update the Use flag?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1926471771

From fyang at openjdk.org  Thu Jan 23 07:27:50 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 23 Jan 2025 07:27:50 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <a4B9iw3kCRhK_8Tjt5Hgdz99dtuEaOVyMtPhQyKOS5k=.f9515188-2df2-4ca1-b21d-6243cac5d887@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
 <0xOVSqgUtYDbmtS7QXK9pKbnJuCD-KH43b_0cOOxkXk=.f491a743-3385-40e5-8f28-895e3a79efd3@github.com>
 <a4B9iw3kCRhK_8Tjt5Hgdz99dtuEaOVyMtPhQyKOS5k=.f9515188-2df2-4ca1-b21d-6243cac5d887@github.com>
Message-ID: <zUPPJzs0ptZl3t9zx2FWPxpUwYpe0n2p_gRVT8P-BjI=.ab43f044-bb9d-4d08-bc4a-bcd9fcbf0fa7@github.com>

On Thu, 23 Jan 2025 07:10:25 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 160:
>> 
>>> 158:   decl(ext_Zbs         , "Zbs"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZbs))         \
>>> 159:   decl(ext_Zcb         , "Zcb"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZcb))         \
>>> 160:   decl(ext_Zfa         , "Zfa"         , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZfa))         \
>> 
>> Are we auto-enabling an experimental feature?
>
> No, as Zfa is not mapped in RiscvHwprobe::add_features_from_query_result() I don't see how it would auto enbled?
> 
>  UPDATE_DEFAULT only updates "Use flag" after the extension, if it is default, i.e. not set by user, no?
> 
> As we have a two step mechanism hwprobe -> extensions flag -> Use flag.
> 
> But if you want I can do it the other way around, add it to hwprobe but do not update the Use flag?

Ah, I see. Thanks. Let's keep the current shape. We can auto-enable it when we have the hardware for testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23171#discussion_r1926486760

From fyang at openjdk.org  Thu Jan 23 07:27:49 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 23 Jan 2025 07:27:49 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
Message-ID: <EemKPyz-5DFgdEa16fsw3YVzzxHrPWaUGwqEd5aFmwM=.a31f0f14-9eee-40be-9520-bf30f8705fa0@github.com>

On Wed, 22 Jan 2025 14:29:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider!
>> 
>> This patch the Zfa zli floating point immediate load.
>> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
>> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
>> 
>> When using one of the 32 'popular' floats we can now materialze them without a load.
>> E.g.
>> `float f = f1 * 0.5 + f2 * 2.0;`
>> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
>> 
>> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
>> 
>> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
>> 
>> Passes:
>> ./test/jdk/java/lang/Math
>> ./test/hotspot/jtreg/compiler/floatingpoint/
>> ./test/jdk/java/util/Formatter/
>> ./test/jdk/java/lang/Float/
>> ./test/jdk/java/lang/Double/
>> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> ./test/hotspot/jtreg/compiler/eliminateAutobox/
>> ./test/hotspot/jtreg/vmTestbase/jit/
>> 
>> Running tier1
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zfa
>  - Merge branch 'master' into zfa
>  - EXPERIMENTAL
>  - Merge branch 'master' into zfa
>  - Merge branch 'master' into zfa
>  - Flip bool static decl
>  - Merge branch 'master' into zfa
>  - Baseline

Looks good to me. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23171#pullrequestreview-2569055775

From sroy at openjdk.org  Thu Jan 23 08:12:03 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 23 Jan 2025 08:12:03 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v11]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <J5Sxq5HaN0fExFquDypzBjYqEFXwvdUMZmWPHvddFoc=.5f1f948e-0ca0-4ec6-9db2-d3d6eee222cf@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/fa896389..1da740a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=09-10

  Stats: 11 lines in 1 file changed: 0 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From rehn at openjdk.org  Thu Jan 23 08:14:51 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 23 Jan 2025 08:14:51 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <EemKPyz-5DFgdEa16fsw3YVzzxHrPWaUGwqEd5aFmwM=.a31f0f14-9eee-40be-9520-bf30f8705fa0@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
 <EemKPyz-5DFgdEa16fsw3YVzzxHrPWaUGwqEd5aFmwM=.a31f0f14-9eee-40be-9520-bf30f8705fa0@github.com>
Message-ID: <bzN_4TDCSkLPPaY96oDxgPJFD_QPw9P3PII3_uinCRc=.e0314e6d-8e76-4265-8cdb-8ede9ec6e9e8@github.com>

On Thu, 23 Jan 2025 07:25:27 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Looks good to me. Thanks.

Thank you !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23171#issuecomment-2609118703

From mli at openjdk.org  Thu Jan 23 08:16:52 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 23 Jan 2025 08:16:52 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
Message-ID: <jFHV7MFZ4EkQfVcDZI9xOV_fA9zt-zxmWsdNc_UI200=.1187e930-0d66-4ea0-a0a2-8ed60fe93c8a@github.com>

On Fri, 17 Jan 2025 16:02:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

src/hotspot/share/opto/library_call.cpp line 8670:

> 8668: 
> 8669:   const TypeInstPtr* box_type = _gvn.type(argument(0))->isa_instptr();
> 8670:   if (box_type == nullptr || box_type->const_oop() == nullptr) {

Hi, this is not a review comment.
Just curious, to continue the following code path why does `box_type` must have a valid `const_oop`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926540874

From jbhateja at openjdk.org  Thu Jan 23 08:36:01 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 23 Jan 2025 08:36:01 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <jFHV7MFZ4EkQfVcDZI9xOV_fA9zt-zxmWsdNc_UI200=.1187e930-0d66-4ea0-a0a2-8ed60fe93c8a@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
 <jFHV7MFZ4EkQfVcDZI9xOV_fA9zt-zxmWsdNc_UI200=.1187e930-0d66-4ea0-a0a2-8ed60fe93c8a@github.com>
Message-ID: <9kjqXKPElm3xOqpAi2u7FNf9G4ATlLNMc6Tf0genUwA=.6de34b54-b56d-4f15-91f6-90ef2d358476@github.com>

On Thu, 23 Jan 2025 08:14:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestions incorporated.
>
> src/hotspot/share/opto/library_call.cpp line 8670:
> 
>> 8668: 
>> 8669:   const TypeInstPtr* box_type = _gvn.type(argument(0))->isa_instptr();
>> 8670:   if (box_type == nullptr || box_type->const_oop() == nullptr) {
> 
> Hi, this is not a review comment.
> Just curious, to continue the following code path why does `box_type` must have a valid `const_oop`?

@Hamlin-Li , Class types are passed as constant oop, this check is added for argument validation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926564701

From rehn at openjdk.org  Thu Jan 23 09:55:49 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 23 Jan 2025 09:55:49 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
Message-ID: <iw8V_nBOJAwBEa4DYpJQ9NrVzTy3Hpqe34ZEaxr59BM=.b852f0a2-cd29-405e-8e47-6a1451d0581c@github.com>

On Wed, 22 Jan 2025 14:29:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider!
>> 
>> This patch the Zfa zli floating point immediate load.
>> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
>> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
>> 
>> When using one of the 32 'popular' floats we can now materialze them without a load.
>> E.g.
>> `float f = f1 * 0.5 + f2 * 2.0;`
>> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
>> 
>> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
>> 
>> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
>> 
>> Passes:
>> ./test/jdk/java/lang/Math
>> ./test/hotspot/jtreg/compiler/floatingpoint/
>> ./test/jdk/java/util/Formatter/
>> ./test/jdk/java/lang/Float/
>> ./test/jdk/java/lang/Double/
>> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> ./test/hotspot/jtreg/compiler/eliminateAutobox/
>> ./test/hotspot/jtreg/vmTestbase/jit/
>> 
>> Running tier1
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zfa
>  - Merge branch 'master' into zfa
>  - EXPERIMENTAL
>  - Merge branch 'master' into zfa
>  - Merge branch 'master' into zfa
>  - Flip bool static decl
>  - Merge branch 'master' into zfa
>  - Baseline

@luhenry do you have any futher concerns, or are you happy ? :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23171#issuecomment-2609358907

From mdoerr at openjdk.org  Thu Jan 23 10:21:57 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 10:21:57 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v9]
In-Reply-To: <Kya5-f1Cb3uMq0jp5mNk7oB3iAEAvjhjPmyH3UAH8kA=.30729ae7-5e1f-4391-8630-887a6e71350b@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <SZM-JCrTK8KfbZU5S2DKIa8XvtQQWV6DePUlFJqRgAo=.85227d0f-fbba-494e-aae0-20e44b16161e@github.com>
 <Kya5-f1Cb3uMq0jp5mNk7oB3iAEAvjhjPmyH3UAH8kA=.30729ae7-5e1f-4391-8630-887a6e71350b@github.com>
Message-ID: <wXu94hyq_WSCrNtZoG7gtUVSSNxfRTAiKRclE6iP4sc=.27863baf-3587-4a04-8c12-76769efb7224@github.com>

On Wed, 22 Jan 2025 11:57:58 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - spaces
>>  - Merge branch 'master' into ghash_processblocks
>>  - spaces
>>  - update references
>>  - Comments and vsx check
>>  - restore
>>  -  assertion for blocks
>>  -  assertion for blocks
>>  -  clearing bits
>>  -  clearing bits
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/d777218f...b04b6924
>
> src/hotspot/cpu/ppc/vm_version_ppc.cpp line 314:
> 
>> 312:   else if (UseGHASHIntrinsics) {
>> 313:     FLAG_SET_DEFAULT(UseGHASHIntrinsics, true);
>> 314:   }
> 
> This looks broken. Please take a look how it is implemented for `UseAES`.

hotspot uses 2 spaces indentation. Otherwise, it looks good. We'll test it. Reviewing the algorithm will need some more time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1926726175

From jbhateja at openjdk.org  Thu Jan 23 11:01:49 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 23 Jan 2025 11:01:49 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <OUQ_VEZa56I-USBTOebr8147s5MwmK0I2r7vmewsjhQ=.f460f84f-a05d-4998-be11-e20535ed394f@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
 <jFHV7MFZ4EkQfVcDZI9xOV_fA9zt-zxmWsdNc_UI200=.1187e930-0d66-4ea0-a0a2-8ed60fe93c8a@github.com>
 <9kjqXKPElm3xOqpAi2u7FNf9G4ATlLNMc6Tf0genUwA=.6de34b54-b56d-4f15-91f6-90ef2d358476@github.com>
 <OUQ_VEZa56I-USBTOebr8147s5MwmK0I2r7vmewsjhQ=.f460f84f-a05d-4998-be11-e20535ed394f@github.com>
Message-ID: <mYEJS4ir7_RM3yIyyJPmFCRfQKdpDqzLa5OF2ZyjJX8=.ddb1e8ff-67df-42eb-9407-072d51232ab4@github.com>

On Thu, 23 Jan 2025 10:54:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> @Hamlin-Li , Class types are passed as constant oop, this check is added for argument validation.
>
> Thanks!
> Seems it could be an assert instead? Or maybe I could have misunderstood your above explanation.

Hi @Hamlin-Li, We intend to disable intrinsification if constraints are not met.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926786421

From mli at openjdk.org  Thu Jan 23 10:57:49 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 23 Jan 2025 10:57:49 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <9kjqXKPElm3xOqpAi2u7FNf9G4ATlLNMc6Tf0genUwA=.6de34b54-b56d-4f15-91f6-90ef2d358476@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
 <jFHV7MFZ4EkQfVcDZI9xOV_fA9zt-zxmWsdNc_UI200=.1187e930-0d66-4ea0-a0a2-8ed60fe93c8a@github.com>
 <9kjqXKPElm3xOqpAi2u7FNf9G4ATlLNMc6Tf0genUwA=.6de34b54-b56d-4f15-91f6-90ef2d358476@github.com>
Message-ID: <OUQ_VEZa56I-USBTOebr8147s5MwmK0I2r7vmewsjhQ=.f460f84f-a05d-4998-be11-e20535ed394f@github.com>

On Thu, 23 Jan 2025 08:32:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 8670:
>> 
>>> 8668: 
>>> 8669:   const TypeInstPtr* box_type = _gvn.type(argument(0))->isa_instptr();
>>> 8670:   if (box_type == nullptr || box_type->const_oop() == nullptr) {
>> 
>> Hi, this is not a review comment.
>> Just curious, to continue the following code path why does `box_type` must have a valid `const_oop`?
>
> @Hamlin-Li , Class types are passed as constant oop, this check is added for argument validation.

Thanks!
Seems it could be an assert instead? Or maybe I could have misunderstood your above explanation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926780216

From mli at openjdk.org  Thu Jan 23 10:53:53 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 23 Jan 2025 10:53:53 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
Message-ID: <d9Gu6d8jZ-r_KTXU4qkPUsjLL6tiAuLe_QhOYtLKP0s=.7deba479-b6ae-485e-b702-c8ca7513ce89@github.com>

On Fri, 17 Jan 2025 16:02:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

One minor comment about the test.

test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 48:

> 46:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "f16c", "true"},
> 47:         counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
> 48:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "zvfh", "true"},

Is `"avx512_fp16", "false"` necessary at this line?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2569517611
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926770427

From adinn at openjdk.org  Thu Jan 23 11:31:48 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 23 Jan 2025 11:31:48 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal
 code [v2]
In-Reply-To: <t5pUMo34G9wNor8JuSVzBZQBcwBOjq6t4SL4uDI8BYE=.0cc58040-5e72-4482-bfd5-8621c05cf9a0@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
 <t5pUMo34G9wNor8JuSVzBZQBcwBOjq6t4SL4uDI8BYE=.0cc58040-5e72-4482-bfd5-8621c05cf9a0@github.com>
Message-ID: <z1JcXoh413AGZL3LcW_a44SCbtX1jCyPuE6ND4wOBDc=.e633b180-aacc-4c4e-8b1d-5c4fbe9d678b@github.com>

On Fri, 10 Jan 2025 12:42:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.
>> 
>> This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leave for later

Changes look good apart from a nit over the comment

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1176:

> 1174:   // Arithmetics
> 1175: 
> 1176:   // Clobber: rscratch2

I'm not entirely sure why this has been added as part of this fix. It's ok as a comment but 1) I'm not sure why you do not also note that `addptr` also clobbers `rscratch1` and 2) `cmpptr` clobbers `rscratch1` but not `rscratch2` but it is not clear that this comment only applies to `addptr`. Perhaps a newline between the two methods would make that clearer.

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23012#pullrequestreview-2569605141
PR Review Comment: https://git.openjdk.org/jdk/pull/23012#discussion_r1926823070

From stefank at openjdk.org  Thu Jan 23 12:40:06 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 23 Jan 2025 12:40:06 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

Stefan Karlsson 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 remote-tracking branch 'upstream/master' into 8346572_check_is_reserved
 - 8346572: Check is_reserved() before using ReservedSpace instances

-------------

Changes: https://git.openjdk.org/jdk/pull/22825/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22825&range=01
  Stats: 117 lines in 10 files changed: 47 ins; 31 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/22825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22825/head:pull/22825

PR: https://git.openjdk.org/jdk/pull/22825

From rrich at openjdk.org  Thu Jan 23 13:41:47 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 23 Jan 2025 13:41:47 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v2]
In-Reply-To: <uo5qWQZZs4ZMAJ5qrXQEwR4Y30bUih1TMhQjj2wW65c=.d4446994-b1e4-4d29-a522-5ed81d4e70e8@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <xJ6McgRAGAME1e7jGmE-Rg3-hzkqTKraxAh5-vgSPz4=.be7dd78d-8902-4fb3-9199-cd915fee645f@github.com>
 <pAErLf6MXbz_0xFLKjf3IfzGaRJ1U1k6rf3duhELl_o=.1769911b-aea0-4049-85b9-0b86cbe7ca91@github.com>
 <zDQHpaeDpuUrxUMpjOlaNcir9WbBLEc7MlNT4qYKoOA=.e73dc9e3-dabe-4ae7-943e-d30ddecc1d29@github.com>
 <uo5qWQZZs4ZMAJ5qrXQEwR4Y30bUih1TMhQjj2wW65c=.d4446994-b1e4-4d29-a522-5ed81d4e70e8@github.com>
Message-ID: <wJ4_QiOdOX9exUA5rbRWcehZADILPv01P5hk_NCXYB0=.e8e61736-240e-4caf-bbfb-e36904badb45@github.com>

On Wed, 22 Jan 2025 22:00:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This is extremely hard to see.
>> L2154 with the "blr" in `check_klass_subtype_slow_path_linear` looks redundant to me. It should be removed if you agree.
>> The comment here should be adapted then too.
>> Also the comment at macroAssembler_ppc.cpp:2258 needs to be adapted because fallthrough from `check_klass_subtype_slow_path` does not mean "not successful". `L_failure` could be renamed to `L_fast_path_failure`
>
> I think `L_failure` is correct. And it's used the same way on all platforms.

Ah, I see. I missed that `L_failure` is passed by reference
https://github.com/openjdk/jdk/blob/c00557f8f53ff729c8a1857a4ffcc585d3f8c6c4/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp#L2159-L2168
Therefore it's never null and `L_failure` is reached if, and only if the result of the type check is negative.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1926994939

From rrich at openjdk.org  Thu Jan 23 13:51:48 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 23 Jan 2025 13:51:48 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v2]
In-Reply-To: <pZxuZDtY9LpVhABPYPyBHfrmm1lgh34DY7xb8_oUh4w=.8f2d9194-4a41-4b23-887a-13aa7c6513bd@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <pZxuZDtY9LpVhABPYPyBHfrmm1lgh34DY7xb8_oUh4w=.8f2d9194-4a41-4b23-887a-13aa7c6513bd@github.com>
Message-ID: <DQcKgUbTFOtBEmUMxzilefYQoJ6cMqbLL8FibRkf6-I=.7f3830bf-1ba7-46f9-8150-365b1fff9adf@github.com>

On Wed, 22 Jan 2025 21:52:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
>> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
>> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
>> 
>> Performance difference can be observed when C2 is disabled (measured on Power10):
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
>> 
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
>> 
>> 
>> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove early return from check_klass_subtype_slow_path.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2158:

> 2156:   std(super_klass, target_offset, sub_klass); // save result to cache
> 2157:   if (result_reg != noreg) { li(result_reg, 0); } // load zero result (indicates a hit)
> 2158:   if (L_success != nullptr) { b(*L_success); }

Handling `L_success != nullptr` should be put on the else-branch of the previous if-statement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1927009873

From mdoerr at openjdk.org  Thu Jan 23 14:07:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 14:07:29 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v3]
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Minor cleanup of check_klass_subtype_slow_path_linear.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22881/files
  - new: https://git.openjdk.org/jdk/pull/22881/files/37789b38..db3d6dec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22881&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22881&range=01-02

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22881/head:pull/22881

PR: https://git.openjdk.org/jdk/pull/22881

From mdoerr at openjdk.org  Thu Jan 23 14:07:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 14:07:29 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v2]
In-Reply-To: <DQcKgUbTFOtBEmUMxzilefYQoJ6cMqbLL8FibRkf6-I=.7f3830bf-1ba7-46f9-8150-365b1fff9adf@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <pZxuZDtY9LpVhABPYPyBHfrmm1lgh34DY7xb8_oUh4w=.8f2d9194-4a41-4b23-887a-13aa7c6513bd@github.com>
 <DQcKgUbTFOtBEmUMxzilefYQoJ6cMqbLL8FibRkf6-I=.7f3830bf-1ba7-46f9-8150-365b1fff9adf@github.com>
Message-ID: <yXTKMnEc9RzI7YP602DMiniLqC_8gM_d9G7R5Px5GJE=.5e71ff6a-9f3b-4fca-aa48-5a837ada7418@github.com>

On Thu, 23 Jan 2025 13:49:34 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove early return from check_klass_subtype_slow_path.
>
> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2158:
> 
>> 2156:   std(super_klass, target_offset, sub_klass); // save result to cache
>> 2157:   if (result_reg != noreg) { li(result_reg, 0); } // load zero result (indicates a hit)
>> 2158:   if (L_success != nullptr) { b(*L_success); }
> 
> Handling `L_success != nullptr` should be put on the else-branch of the previous if-statement.

Doesn't make a real difference, but I've cleaned it up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1927032384

From mdoerr at openjdk.org  Thu Jan 23 14:10:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 14:10:47 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v3]
In-Reply-To: <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>
Message-ID: <fzwBtSalAsXbYD8bEd2__b5XdArFkD3rcLhS3q_iGmM=.ace11fce-846e-47d0-b13f-0a6a506f518f@github.com>

On Thu, 23 Jan 2025 14:07:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
>> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
>> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
>> 
>> Performance difference can be observed when C2 is disabled (measured on Power10):
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
>> 
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
>> 
>> 
>> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup of check_klass_subtype_slow_path_linear.

I've run most of the tier 1 tests with JTREG="VM_OPTIONS=-XX:-UseSecondarySupersTable" and didn't see new failures. I'll rerun tests. Note that Oracle Copyright years are already updated in head, but I don't want to merge because the PPC64le build is currently broken.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22881#issuecomment-2609902298

From rrich at openjdk.org  Thu Jan 23 14:26:51 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 23 Jan 2025 14:26:51 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v2]
In-Reply-To: <yXTKMnEc9RzI7YP602DMiniLqC_8gM_d9G7R5Px5GJE=.5e71ff6a-9f3b-4fca-aa48-5a837ada7418@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <pZxuZDtY9LpVhABPYPyBHfrmm1lgh34DY7xb8_oUh4w=.8f2d9194-4a41-4b23-887a-13aa7c6513bd@github.com>
 <DQcKgUbTFOtBEmUMxzilefYQoJ6cMqbLL8FibRkf6-I=.7f3830bf-1ba7-46f9-8150-365b1fff9adf@github.com>
 <yXTKMnEc9RzI7YP602DMiniLqC_8gM_d9G7R5Px5GJE=.5e71ff6a-9f3b-4fca-aa48-5a837ada7418@github.com>
Message-ID: <z43Y00Y7ZSwwB5ElgnWuVUNUBNKQWHNLm_AIa5vFquE=.df7035f3-f9c9-4a82-a9cc-cbe6ffb083df@github.com>

On Thu, 23 Jan 2025 14:04:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2158:
>> 
>>> 2156:   std(super_klass, target_offset, sub_klass); // save result to cache
>>> 2157:   if (result_reg != noreg) { li(result_reg, 0); } // load zero result (indicates a hit)
>>> 2158:   if (L_success != nullptr) { b(*L_success); }
>> 
>> Handling `L_success != nullptr` should be put on the else-branch of the previous if-statement.
>
> Doesn't make a real difference, but I've cleaned it up.

Thanks. It matches the assertion you've added. I like consistency. It helps understanding stuff.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22881#discussion_r1927064061

From rrich at openjdk.org  Thu Jan 23 14:33:48 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 23 Jan 2025 14:33:48 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v3]
In-Reply-To: <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>
Message-ID: <zvgl5xOSUO5sDkJbpixj_WUkARfCJQ_VTnFRiXZd4IY=.22cd6eab-a0fd-4191-bd43-d3f45ab0de1c@github.com>

On Thu, 23 Jan 2025 14:07:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
>> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
>> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
>> 
>> Performance difference can be observed when C2 is disabled (measured on Power10):
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
>> 
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
>> 
>> 
>> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup of check_klass_subtype_slow_path_linear.

Thanks for doing the port ?
Cheers, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22881#pullrequestreview-2570024260

From mdoerr at openjdk.org  Thu Jan 23 14:33:49 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 14:33:49 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v3]
In-Reply-To: <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>
Message-ID: <zGVh-vzZXxQMVGOOl5KBkEbdj3u0u-claAaP7XZnfEs=.1107251b-d88c-4ae8-bfe8-c13cbd594e32@github.com>

On Thu, 23 Jan 2025 14:07:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
>> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
>> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
>> 
>> Performance difference can be observed when C2 is disabled (measured on Power10):
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
>> 
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
>> 
>> 
>> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup of check_klass_subtype_slow_path_linear.

Thanks for the review and for finding the bug!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22881#issuecomment-2609961916

From gziemski at openjdk.org  Thu Jan 23 15:50:18 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 23 Jan 2025 15:50:18 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v8]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <2uWGvmWo1UfE-qAfexSIT0eXzjKFeEwoDv-bPBT8heg=.3bb80646-26f1-4885-92aa-159865d654f6@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
> 
> VM interacts with these through these APIs:
> 
>   ```
>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>   NMT_LogRecorder::logThreadName(name);
>   NMT_LogRecorder::finish();
> 
> 
> For controlling their liveness and through their "log" APIs for the actual logging.
> 
> For memory logger those are:
> 
> 
>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
> 
> 
> and for virtual memory logger, those are:
> 
> 
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
> 
> 
> That's the entirety of the surface area of the new code.
> 
> The actual implementation extends one existing VM API:
> 
> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
> `
> 
> and adds a few APIs to permit_forbidden_function.hpp:
> 
> 
>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
> 
>  #if defined(LINUX)
>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>  #elif defined(WINDOWS)
>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>  #elif defined(__APPLE__)
>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>  #endif
> 
> 
> Those are need if we want to calculate the memory overhead
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/...

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  simplify, remove optional code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/0567f3b8..6579e34d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=06-07

  Stats: 35 lines in 3 files changed: 0 ins; 35 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From mdoerr at openjdk.org  Thu Jan 23 15:58:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 15:58:51 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
Message-ID: <_DLDS4E1k7FLGIsHsm1_tjnX_D5xWQTA3CBUu_3nXRE=.5462cd0d-4fbb-4e1b-860f-495f14b54fb1@github.com>

On Thu, 23 Jan 2025 05:45:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Cesar Soares Lucas 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 master
>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>  - Relocation of Card Tables

The ppc fix looks good. Thanks! I guess we should rerun tests shortly before integration. There are currently many Shenandoah issues (mostly related to GenShen).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2610196760

From kcr at openjdk.org  Thu Jan 23 16:27:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Jan 2025 16:27:52 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <bJY35XOxd5GMfhJKn7wLEMxFTSMQ17CHm3ZI0cfMegU=.3dd38c81-4908-4c5c-956c-29dd1cdc1322@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

@earthling-amzn Did you see David's question? I think this should not have been integrated to jdk24 given the RDP2 rules. Was this instead intended for jdk24u (for 24.0.1)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23221#issuecomment-2610302874

From ccheung at openjdk.org  Thu Jan 23 16:39:48 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 23 Jan 2025 16:39:48 GMT
Subject: RFR: 8348240: Remove
 SystemDictionaryShared::lookup_super_for_unregistered_class() [v2]
In-Reply-To: <eS5vOxcF2Pyb-eLXmPC1W-jf6LfugC0IUNxX7QAM7qI=.774cff51-1a04-41b7-ada3-18cf612eb1d9@github.com>
References: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
 <eS5vOxcF2Pyb-eLXmPC1W-jf6LfugC0IUNxX7QAM7qI=.774cff51-1a04-41b7-ada3-18cf612eb1d9@github.com>
Message-ID: <2DJ4nTPwrRAk_oqyWf8z37DBZJLrfGFnkZS2xhPOuyE=.199caeaa-8582-49ba-ac00-74caf43414b5@github.com>

On Thu, 23 Jan 2025 02:04:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there.
>> 
>> The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java.
>> 
>> ### How this works:
>> 
>> For example, let's assume you have the following classfiles in foo.jar:
>> 
>> 
>> interface MyInterface1 {}
>> interface MyInterface2 {}
>> class MyClass extends Object implements MyInterface1, MyInterface2 {}
>> 
>> 
>> The CDS classlist file can look like this:
>> 
>> 
>> java/lang/Object id: 1
>> MyInterface1: id: 2 super: 1 source: foo.jar
>> MyInterface2: id: 3 super: 1 source: foo.jar
>> MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar
>> 
>> 
>> When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters:
>> 
>> - `name` = "MyClass"
>> - `superClass` = java.lang.Object
>> - `interfaces` = {MyInterface1, MyInterface2} 
>> 
>> `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`.
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8348240-remove-lookup_super_for_unregistered_class
>  - @calvinccheung comments
>  - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class()

Thanks for the update.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23226#pullrequestreview-2570418706

From sroy at openjdk.org  Thu Jan 23 16:46:27 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 23 Jan 2025 16:46:27 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v12]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <5bhEDHXvXHpx8vSgyoi8QD8zLWTMG1HD6o_tC74_i-E=.16243801-4270-45ad-a412-fee7c7d543a9@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/1da740a6..05d16980

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=10-11

  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From gziemski at openjdk.org  Thu Jan 23 17:16:37 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 23 Jan 2025 17:16:37 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v9]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <EVtVi5pptwQWN3wWiWz8peBckTsFzKjZTY3hgt1bqnY=.dfe1fff2-85df-4f11-a50a-1cb379e7415a@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
> 
> VM interacts with these through these APIs:
> 
>   ```
>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>   NMT_LogRecorder::logThreadName(name);
>   NMT_LogRecorder::finish();
> 
> 
> For controlling their liveness and through their "log" APIs for the actual logging.
> 
> For memory logger those are:
> 
> 
>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
> 
> 
> and for virtual memory logger, those are:
> 
> 
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
> 
> 
> That's the entirety of the surface area of the new code.
> 
> The actual implementation extends one existing VM API:
> 
> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
> `
> 
> and adds a few APIs to permit_forbidden_function.hpp:
> 
> 
>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
> 
>  #if defined(LINUX)
>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>  #elif defined(WINDOWS)
>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>  #elif defined(__APPLE__)
>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>  #endif
> 
> 
> Those are need if we want to calculate the memory overhead
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/...

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  substract free from NMT components correctly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/6579e34d..1fae5cee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=07-08

  Stats: 15 lines in 1 file changed: 10 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From gziemski at openjdk.org  Thu Jan 23 17:20:43 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 23 Jan 2025 17:20:43 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v10]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <VtVuKDswjAIz_KDEvAfhQnZNSxheGYX730tkcDteNbU=.58befe13-16f3-4ef1-8176-9b81af728d91@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
> 
> VM interacts with these through these APIs:
> 
>   ```
>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>   NMT_LogRecorder::logThreadName(name);
>   NMT_LogRecorder::finish();
> 
> 
> For controlling their liveness and through their "log" APIs for the actual logging.
> 
> For memory logger those are:
> 
> 
>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
> 
> 
> and for virtual memory logger, those are:
> 
> 
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
> 
> 
> That's the entirety of the surface area of the new code.
> 
> The actual implementation extends one existing VM API:
> 
> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
> `
> 
> and adds a few APIs to permit_forbidden_function.hpp:
> 
> 
>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
> 
>  #if defined(LINUX)
>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>  #elif defined(WINDOWS)
>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>  #elif defined(__APPLE__)
>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>  #endif
> 
> 
> Those are need if we want to calculate the memory overhead
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/...

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  account for live objects for NMT components correctly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/1fae5cee..bb9d487f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=08-09

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From gziemski at openjdk.org  Thu Jan 23 17:40:29 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 23 Jan 2025 17:40:29 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v11]
In-Reply-To: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
Message-ID: <bRnr3b9foKZHVSsxQWotbMmUPBQoiFetQOxHLX2FDgs=.5e3437f7-4f04-4c42-8170-7c571cc1c747@github.com>

> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
> 
> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
> 
> VM interacts with these through these APIs:
> 
>   ```
>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>   NMT_LogRecorder::logThreadName(name);
>   NMT_LogRecorder::finish();
> 
> 
> For controlling their liveness and through their "log" APIs for the actual logging.
> 
> For memory logger those are:
> 
> 
>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
> 
> 
> and for virtual memory logger, those are:
> 
> 
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
> 
> 
> That's the entirety of the surface area of the new code.
> 
> The actual implementation extends one existing VM API:
> 
> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
> `
> 
> and adds a few APIs to permit_forbidden_function.hpp:
> 
> 
>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
> 
>  #if defined(LINUX)
>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>  #elif defined(WINDOWS)
>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>  #elif defined(__APPLE__)
>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>  #endif
> 
> 
> Those are need if we want to calculate the memory overhead
> 
> To use, you first need to record the pattern of operations, ex:
> 
> `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/...

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  more detail in summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23115/files
  - new: https://git.openjdk.org/jdk/pull/23115/files/bb9d487f..3d299c31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=09-10

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115

PR: https://git.openjdk.org/jdk/pull/23115

From gziemski at openjdk.org  Thu Jan 23 17:59:56 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 23 Jan 2025 17:59:56 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v15]
In-Reply-To: <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>
Message-ID: <FjIqhbSdlF-9r9WzQeduvVPdmd9-W5VOH7PjYbMRDps=.9fba5e9d-23c3-420d-abb4-1b7f50ef1196@github.com>

On Wed, 22 Jan 2025 12:13:04 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   treap swap fix

Hmm, I still can't compile it, I see:


/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:235:18: error: expected ';' after expression
  235 |   VMATreap::Range range(nullptr, nullptr);
      |                  ^
      |                  ;
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:235:13: error: no member named 'Range' in 'RBTree<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, RBTreeCHeapAllocator<MemTag::mtNMT>>'
  235 |   VMATreap::Range range(nullptr, nullptr);
      |   ~~~~~~~~~~^
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:235:19: error: use of undeclared identifier 'range'
  235 |   VMATreap::Range range(nullptr, nullptr);
      |                   ^
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:240:5: error: use of undeclared identifier 'range'
  240 |     range = _tree.find_enclosing_range(from);
      |     ^
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:240:19: error: no member named 'find_enclosing_range' in 'RBTree<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, RBTreeCHeapAllocator<MemTag::mtNMT>>'
  240 |     range = _tree.find_enclosing_range(from);
      |             ~~~~~ ^
/Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:241:10: error: use of undeclared identifier 'range'
  241 |     if ((range.start == nullptr && range.end == nullptr) ||
      |          ^

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2610583025

From vpaprotski at openjdk.org  Thu Jan 23 18:11:02 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 23 Jan 2025 18:11:02 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v2]
In-Reply-To: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
Message-ID: <p6gjQIuZTOmeeFUvvyDN_jETOCm_wzRjKP1w16iRnHs=.f0d19d12-19e8-48cc-aba3-ce9a2877c75f@github.com>

> @TobiHartmann  There are still some unanswered questions I have, but committing this since we need to work around vacation schedules.
> 
> **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This fix fixes the crash but I don't understand entirely why the crash happens in the first place.
> 
> The issue fixed here are all the CheckJNI warnings:
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> Crash has nothing to do with String.indexOf work, but was introduced by my `8319429: Resetting MXCSR flags degrades ecore` change. I was able to get HelloWorld to crash on Windows (`-Xcheck:jni -XX:+EnableX86ECoreOpts`). Same command on linux produces hundreds of CheckJNI warnings. Is it odd that its only being found now, no other CheckJNI tests?
> 
> I would appreciate some help/reviews from somebody more aware of the Java-to-C linkage. I think I got the masks fixed, but there is one specific place (see the 'FIXME' question in the diff) for Windows I am not certain about. (@sviswa7 is on vacation for few more weeks)
> 
> Note: Crash on windows (if I have the Windows debugger actually correct), happens on:
> 
> 0x000001f2525f13c1:   fxrstor64 (%rsp)
> Stack:
> 0x00000088f1bfe060:   00007ff8b4384310 0000025bfaeb2200
> 
> 
> `00007ff8` _seems_ like a valid mxcsr value, only way it should crash is if top 2 bytes weren't zeroes, which they are.

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22673/files
  - new: https://git.openjdk.org/jdk/pull/22673/files/c106e350..6768b9df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=00-01

  Stats: 86 lines in 7 files changed: 42 ins; 35 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22673/head:pull/22673

PR: https://git.openjdk.org/jdk/pull/22673

From wkemper at openjdk.org  Thu Jan 23 18:17:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Jan 2025 18:17:55 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
Message-ID: <52g1j3w9Wl6NwJqpJI-Im6Smp9wPb4IGtNkRpkTsPMI=.8d4cf740-4b91-4c0c-a957-b32c1d5bd85d@github.com>

On Thu, 23 Jan 2025 12:40:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
>> 
>> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
>> 
>> Tested tier1 and GHA, but will run more tests when/if this gets accepted.
>
> Stefan Karlsson 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 remote-tracking branch 'upstream/master' into 8346572_check_is_reserved
>  - 8346572: Check is_reserved() before using ReservedSpace instances

Filed https://bugs.openjdk.org/browse/JDK-8348420 to follow up for Shenandoah.

-------------

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2570660032

From vpaprotski at openjdk.org  Thu Jan 23 18:26:06 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 23 Jan 2025 18:26:06 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v3]
In-Reply-To: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
Message-ID: <Qr5PrJudM7WMHlsf4T5azeW343hIug9ChYPjEoucLbc=.da53cb18-e12c-4772-954d-5f3a337d05bb@github.com>

> (Also see `8319429: Resetting MXCSR flags degrades ecore`) 
> 
> For performance, signaling flags (bottom 6 bits) are set by default in MXCSR. This PR fixes the Xcheck:jni comparison that is producing these copious warnings:
> 
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
> 
> 
> **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This PR fixes the crash but I have not been able to track down the source of the crash (i.e. crash in the warn handler).

Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22673/files
  - new: https://git.openjdk.org/jdk/pull/22673/files/6768b9df..2b15f99a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22673/head:pull/22673

PR: https://git.openjdk.org/jdk/pull/22673

From vpaprotski at openjdk.org  Thu Jan 23 18:26:06 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Thu, 23 Jan 2025 18:26:06 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v3]
In-Reply-To: <Qr5PrJudM7WMHlsf4T5azeW343hIug9ChYPjEoucLbc=.da53cb18-e12c-4772-954d-5f3a337d05bb@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <Qr5PrJudM7WMHlsf4T5azeW343hIug9ChYPjEoucLbc=.da53cb18-e12c-4772-954d-5f3a337d05bb@github.com>
Message-ID: <N_Ovwfxffj9EDpOUjYzgqEQ9yPeaTAWO5HM3R6A5tE4=.3d21b08c-e453-4f3c-bcbd-93635fb8e290@github.com>

On Thu, 23 Jan 2025 18:23:01 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> (Also see `8319429: Resetting MXCSR flags degrades ecore`) 
>> 
>> For performance, signaling flags (bottom 6 bits) are set by default in MXCSR. This PR fixes the Xcheck:jni comparison that is producing these copious warnings:
>> 
>> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall
>> 
>> 
>> **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This PR fixes the crash but I have not been able to track down the source of the crash (i.e. crash in the warn handler).
>
> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 185:

> 183:       // On ECore, restore with signaling flags enabled
> 184:       MxCsr |= 0x3F;
> 185:     }

@JornVernee I came across your comment https://github.com/openjdk/jdk/pull/14523/files#r1236920072

I believe I am following the 'spirit' of that comment here, but would appreciate you having a look.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1927463691

From cjplummer at openjdk.org  Thu Jan 23 20:21:24 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Jan 2025 20:21:24 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
Message-ID: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>

If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:


 stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)


The following can be used to reproduce this failure. Most SA tests will fail:

 make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 

I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.

I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

-------------

Commit messages:
 - Add DeoptimizeObjectsALotThread support

Changes: https://git.openjdk.org/jdk/pull/23279/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23279&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348239
  Stats: 82 lines in 6 files changed: 62 ins; 14 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23279/head:pull/23279

PR: https://git.openjdk.org/jdk/pull/23279

From cslucas at openjdk.org  Thu Jan 23 21:29:47 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 23 Jan 2025 21:29:47 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <_DLDS4E1k7FLGIsHsm1_tjnX_D5xWQTA3CBUu_3nXRE=.5462cd0d-4fbb-4e1b-860f-495f14b54fb1@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
 <_DLDS4E1k7FLGIsHsm1_tjnX_D5xWQTA3CBUu_3nXRE=.5462cd0d-4fbb-4e1b-860f-495f14b54fb1@github.com>
Message-ID: <qDoub4RmoYmn6KNd2KwmM2HIH-FZlDfz8g1MitgcHwQ=.8ded4b8b-73e1-4199-862b-4da4b0b83341@github.com>

On Thu, 23 Jan 2025 15:56:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> There are currently many Shenandoah issues (mostly related to GenShen).

@TheRealMDoerr - are the issues coming from a build with this patch or something prior?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2611052027

From dlong at openjdk.org  Thu Jan 23 22:03:46 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 23 Jan 2025 22:03:46 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <sxtToa2PCVgTkpzIumkb-WdkYVfPPgzvbEz6vwwmDZE=.ed393e8a-c8c6-4617-9a18-395e5558b705@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java line 92:

> 90:   public boolean   isMonitorDeflationThread()    { return false; }
> 91:   public boolean   isAttachListenerThread()      { return false; }
> 92:   public boolean   isDeoptimizeObjectsALotThread() { return false; }

Is this method used anywhere?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1927740178

From iklam at openjdk.org  Thu Jan 23 22:05:59 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 Jan 2025 22:05:59 GMT
Subject: RFR: 8348240: Remove
 SystemDictionaryShared::lookup_super_for_unregistered_class() [v2]
In-Reply-To: <KhqvBvtD4r-B12sFgx3IqdQjXa1VHB9j9DL6w4ecyOA=.04cc443d-9ca4-44b1-af9a-b48b7b7a219b@github.com>
References: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
 <KhqvBvtD4r-B12sFgx3IqdQjXa1VHB9j9DL6w4ecyOA=.04cc443d-9ca4-44b1-af9a-b48b7b7a219b@github.com>
Message-ID: <lU17qn9zMtokdbPiIq92jJscFSlGurlE0x3GiXHt8Y4=.783e5f14-647e-47de-a6df-c7acc916e252@github.com>

On Wed, 22 Jan 2025 23:41:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8348240-remove-lookup_super_for_unregistered_class
>>  - @calvinccheung comments
>>  - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class()
>
> I like this change a lot, except for the name "unregistered" but that can be taken up in some other way.  If I understand correctly, this just creates a dummy class loader to load the classes you want to share from the non-boot, app or system class loader.

Thanks @coleenp @calvinccheung for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23226#issuecomment-2611107641

From iklam at openjdk.org  Thu Jan 23 22:06:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 Jan 2025 22:06:00 GMT
Subject: Integrated: 8348240: Remove
 SystemDictionaryShared::lookup_super_for_unregistered_class()
In-Reply-To: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
References: <pHhhr9rtVc7mWhHc6MC0Kupg_UgwAy5_lfTxyCT67fs=.afdeb97b-1e63-4f30-b0dc-f39f619779e5@github.com>
Message-ID: <ANH5lpVMVpoh3_tNkACzDbxIPWcbHPa9qVYirtIWHFE=.afa6d387-b815-410a-9f60-0eb708648b24@github.com>

On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there.
> 
> The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java.
> 
> ### How this works:
> 
> For example, let's assume you have the following classfiles in foo.jar:
> 
> 
> interface MyInterface1 {}
> interface MyInterface2 {}
> class MyClass extends Object implements MyInterface1, MyInterface2 {}
> 
> 
> The CDS classlist file can look like this:
> 
> 
> java/lang/Object id: 1
> MyInterface1: id: 2 super: 1 source: foo.jar
> MyInterface2: id: 3 super: 1 source: foo.jar
> MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar
> 
> 
> When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters:
> 
> - `name` = "MyClass"
> - `superClass` = java.lang.Object
> - `interfaces` = {MyInterface1, MyInterface2} 
> 
> `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`.

This pull request has now been integrated.

Changeset: 7f16a087
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f16a0875ced8669b9d2131c67496a66e74ea36f
Stats:     346 lines in 10 files changed: 193 ins; 115 del; 38 mod

8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class()

Reviewed-by: ccheung, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/23226

From dlong at openjdk.org  Thu Jan 23 22:06:45 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 23 Jan 2025 22:06:45 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Overall the changes seem fine, however it would be nice if the vmStructs.cpp registration mechanism was modular and extensible, instead of monolithic.  That would make it easier to register private types, or even types outside of libjvm.

-------------

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2571122889

From cjplummer at openjdk.org  Thu Jan 23 22:33:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Jan 2025 22:33:45 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
Message-ID: <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>

On Thu, 23 Jan 2025 22:03:45 GMT, Dean Long <dlong at openjdk.org> wrote:

> Overall the changes seem fine, however it would be nice if the vmStructs.cpp registration mechanism was modular and extensible, instead of monolithic. That would make it easier to register private types, or even types outside of libjvm.

I'm not too sure what you are suggesting here.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java line 92:
> 
>> 90:   public boolean   isMonitorDeflationThread()    { return false; }
>> 91:   public boolean   isAttachListenerThread()      { return false; }
>> 92:   public boolean   isDeoptimizeObjectsALotThread() { return false; }
> 
> Is this method used anywhere?

No, but I added it to be consistent with all the other JavaThread subclasses. Actually none of these are used except for isCompilerThread and isCodeCacheSweeperThread. The latter reference is irrelevant since there is no longer a CodeCacheSweeperThread, and the former reference should be replaced with isHiddenFromExternalView(). These are all things documented to fix as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347), but in the meantime I though it best to be consistent with existing code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2611148710
PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1927768244

From mdoerr at openjdk.org  Thu Jan 23 23:16:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Jan 2025 23:16:47 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <qDoub4RmoYmn6KNd2KwmM2HIH-FZlDfz8g1MitgcHwQ=.8ded4b8b-73e1-4199-862b-4da4b0b83341@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
 <_DLDS4E1k7FLGIsHsm1_tjnX_D5xWQTA3CBUu_3nXRE=.5462cd0d-4fbb-4e1b-860f-495f14b54fb1@github.com>
 <qDoub4RmoYmn6KNd2KwmM2HIH-FZlDfz8g1MitgcHwQ=.8ded4b8b-73e1-4199-862b-4da4b0b83341@github.com>
Message-ID: <cJAazPehWZ1CHqkSKWSqkHrMcC9x44Aq6r0GKj0u6Nk=.9ce49f16-00a8-4ba2-9200-3dd7ea44b01e@github.com>

On Thu, 23 Jan 2025 21:27:36 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> > There are currently many Shenandoah issues (mostly related to GenShen).
> 
> @TheRealMDoerr - are the issues coming from a build with this patch or something prior?

Before this patch. We have linked the issues we found with [JDK-8337511](https://bugs.openjdk.org/browse/JDK-8337511).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2611204842

From fyang at openjdk.org  Fri Jan 24 01:03:51 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 24 Jan 2025 01:03:51 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
Message-ID: <MDGRV75H1vIpGZRwc-NFoOOq5a5SKnl3G-q0pIy9CLo=.82603af9-094c-4048-8319-23690b30260e@github.com>

On Thu, 23 Jan 2025 05:45:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Cesar Soares Lucas 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 master
>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>  - Relocation of Card Tables

FYI: `gtest:all` and `hotspot_gc_shenandoah` are clean on linux-riscv64 platform with this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2611324901

From lmesnik at openjdk.org  Fri Jan 24 01:14:35 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 Jan 2025 01:14:35 GMT
Subject: RFR: 8318098: Update jfr tests to replace keyword jfr with vm.flagless
Message-ID: <nXYifnGGUXS1CoUGZiMuJgD10ty8wL_I5_hGzzO4Kq8=.9491ef9f-42ab-445c-9f58-3d0401fef596@github.com>

A lot of jfr tests are very specific. Currently all of them are marked with jfr keyword and excluded when VM flags are set.

It makes sense to mark them with @requires <something> to be complaint with all other openjdk tests. 
The next step is to review tests and remove vm.flagless from tests that should be executed with different VM flags.

Bug https://bugs.openjdk.org/browse/JDK-8318097 is filed for this activity.

-------------

Commit messages:
 - 8318098: Update jfr tests to replace keyword jfr with vm.flagless

Changes: https://git.openjdk.org/jdk/pull/23285/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23285&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318098
  Stats: 1090 lines in 582 files changed: 2 ins; 0 del; 1088 mod
  Patch: https://git.openjdk.org/jdk/pull/23285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23285/head:pull/23285

PR: https://git.openjdk.org/jdk/pull/23285

From dholmes at openjdk.org  Fri Jan 24 06:35:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Jan 2025 06:35:48 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <J5r63DXbAL3sKyHad22LYgpMWab6i3b8YOZprE-mu3Y=.8109ec0a-cfd6-4b38-bc27-79b2560279b6@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Okay as a quick fix but I look forward to all this going away.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2571746144

From lmesnik at openjdk.org  Fri Jan 24 06:38:49 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 Jan 2025 06:38:49 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <JT7-1s8_PWX8dVD-XoP72nTT-FWJbKAfD6oqwn-jcko=.0f9d3f0b-d205-4a4c-89a7-bc34f208c5e6@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2571749964

From lmesnik at openjdk.org  Fri Jan 24 06:47:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 Jan 2025 06:47:50 GMT
Subject: RFR: 8334320: Replace
 vmTestbase/metaspace/share/TriggerUnloadingWithWhiteBox.java with
 ClassUnloadCommon from testlibrary
In-Reply-To: <Ksm0Ks2LeRw5B-pm2VL6tuQg11d5ivEMftSKoeceTso=.4da2555a-e6ba-4f83-a2ee-5a0da1740afc@github.com>
References: <Ksm0Ks2LeRw5B-pm2VL6tuQg11d5ivEMftSKoeceTso=.4da2555a-e6ba-4f83-a2ee-5a0da1740afc@github.com>
Message-ID: <ddyefc1-gTfSggvsYWg801M2GucyWdZ4vVl9JUQk5cs=.381d589b-7450-4556-8366-c423ae9d5849@github.com>

On Fri, 17 Jan 2025 13:43:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Rename and make TriggerUnloadingWithWhiteBox call ClassUnloadCommon.triggerUnloading() instead of WB.fullGC().

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23174#pullrequestreview-2571761142

From stefank at openjdk.org  Fri Jan 24 09:11:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 24 Jan 2025 09:11:52 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
Message-ID: <SAF8HLQNenvbDGaa07u_dKeYcWnCCJEYxdxuGgH_eZY=.e7b68b51-73c6-41c3-bf75-e62d9f761afe@github.com>

On Thu, 23 Jan 2025 12:40:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
>> 
>> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
>> 
>> Tested tier1 and GHA, but will run more tests when/if this gets accepted.
>
> Stefan Karlsson 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 remote-tracking branch 'upstream/master' into 8346572_check_is_reserved
>  - 8346572: Check is_reserved() before using ReservedSpace instances

Thank you all!

Tier1-3 testing passed again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22825#issuecomment-2612021846

From tschatzl at openjdk.org  Fri Jan 24 09:26:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Jan 2025 09:26:54 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
Message-ID: <W0x5jZioyVHNK1Ngoi4-QUJ-2kYXgJEl5f8SAMA7viU=.a008f770-54f5-46a6-a430-629ca4e86d11@github.com>

On Thu, 23 Jan 2025 12:40:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
>> 
>> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
>> 
>> Tested tier1 and GHA, but will run more tests when/if this gets accepted.
>
> Stefan Karlsson 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 remote-tracking branch 'upstream/master' into 8346572_check_is_reserved
>  - 8346572: Check is_reserved() before using ReservedSpace instances

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22825#pullrequestreview-2572119144

From stefank at openjdk.org  Fri Jan 24 09:26:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 24 Jan 2025 09:26:55 GMT
Subject: Integrated: 8346572: Check is_reserved() before using ReservedSpace
 instances
In-Reply-To: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
Message-ID: <As9oR1hixVKX0Coh9BPH7vRG-RFDVwJRU9M8Rewr8k8=.bf7e9c45-3a52-4a21-8c21-aea03a5f8aed@github.com>

On Thu, 19 Dec 2024 09:35:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.
> 
> The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.
> 
> Tested tier1 and GHA, but will run more tests when/if this gets accepted.

This pull request has now been integrated.

Changeset: 0df9dcb6
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0df9dcb6aa7c31511ca3137da246962faca818a3
Stats:     117 lines in 10 files changed: 47 ins; 31 del; 39 mod

8346572: Check is_reserved() before using ReservedSpace instances

Reviewed-by: tschatzl, wkemper, ayang, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/22825

From azafari at openjdk.org  Fri Jan 24 09:40:35 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 24 Jan 2025 09:40:35 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v16]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <6Ibgx32GiBVL0bhgX54I6ACUq0dqHTpd2BqhUjqvkfw=.cb83b031-fe62-4ae2-b2b2-ee538b0db165@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - one small fix for SSIZE_FORMAT
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - undo overlapping checks.
 - size_t format fixed.
 - fix for debug prints
 - added overlap checks.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - visit committed regions refined.
 - visit_committed_regions signature changed.
 - removed unused local var.
 - ... and 51 more: https://git.openjdk.org/jdk/compare/15e06b61...5352894a

-------------

Changes: https://git.openjdk.org/jdk/pull/20425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=15
  Stats: 3023 lines in 47 files changed: 1244 ins; 1530 del; 249 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 mdoerr at openjdk.org  Fri Jan 24 09:49:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Jan 2025 09:49:50 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
Message-ID: <oIoDgp2uO0H7OWF5EOgiL9UNSBgPv6xmk0Y9mK5uGj8=.20871b16-5adc-42cb-83e0-b62d9df51485@github.com>

On Thu, 23 Jan 2025 05:45:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Cesar Soares Lucas 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 master
>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>  - Relocation of Card Tables

I have run this PR through our nightly tests on all our platforms and there were no new issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2612094642

From shade at openjdk.org  Fri Jan 24 09:52:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Jan 2025 09:52:46 GMT
Subject: RFR: 8346890: AArch64: Type profile counters generate suboptimal
 code [v3]
In-Reply-To: <SsEZRBp3Z0T6jlvdsicvXXh2E7o3hYRs5fl1FeyWA1I=.e3ce4361-0e64-4be5-aee1-e35df823e63b@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
 <SsEZRBp3Z0T6jlvdsicvXXh2E7o3hYRs5fl1FeyWA1I=.e3ce4361-0e64-4be5-aee1-e35df823e63b@github.com>
Message-ID: <JDbkpQqufJnwZC853tlA8tWL4wbT4etz3ztxKjUoQo0=.6c4612f4-ca7a-4d3b-ab39-378fb9f830f2@github.com>

On Thu, 23 Jan 2025 12:01:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.
>> 
>> This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23012#pullrequestreview-2572186996

From mdoerr at openjdk.org  Fri Jan 24 09:53:57 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Jan 2025 09:53:57 GMT
Subject: Integrated: 8344232: [PPC64] secondary_super_cache does not scale
 well: C1 and interpreter
In-Reply-To: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
Message-ID: <Vh7ED2HYykgXXN7-aXAnYgJker6cud8nQ3u4nH40sSk=.ee98a2c0-6fb1-42b1-bc5e-74f4846b0c35@github.com>

On Wed, 25 Dec 2024 15:40:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
> 
> Performance difference can be observed when C2 is disabled (measured on Power10):
> 
> 
> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
> 
> 
> 
> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
> 
> 
> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

This pull request has now been integrated.

Changeset: 4a375e5b
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a375e5b8899aa684b8a921e198203e76794f709
Stats:     320 lines in 7 files changed: 260 ins; 7 del; 53 mod

8344232: [PPC64] secondary_super_cache does not scale well: C1 and interpreter

Reviewed-by: rrich, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/22881

From mdoerr at openjdk.org  Fri Jan 24 09:53:57 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Jan 2025 09:53:57 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well:
 C1 and interpreter [v3]
In-Reply-To: <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>
References: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>
 <M1eF67X9Tf_qCkDV86ZFKxWzwu5-pkSXU2vEVoc-Lo0=.b1c4eef4-de45-4246-a931-90a8bc802db2@github.com>
Message-ID: <PE0S6p7KX66rUWA1UQduCCHrRdiAubBJrtrt_si4FFo=.6ecd74de-881a-40e5-ac3c-82c44f913049@github.com>

On Thu, 23 Jan 2025 14:07:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
>> The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.
>> C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled. Some stubs are modified to provide one more temp register.
>> 
>> Performance difference can be observed when C2 is disabled (measured on Power10):
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op
>> 
>> 
>> 
>> -XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
>> SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
>> SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
>> SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op
>> 
>> 
>> `SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup of check_klass_subtype_slow_path_linear.

Tier 1-4 have passed with and without UseSecondarySupersTable on both, linux ppc64le and AIX.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22881#issuecomment-2612099046

From luhenry at openjdk.org  Fri Jan 24 10:02:52 2025
From: luhenry at openjdk.org (Ludovic Henry)
Date: Fri, 24 Jan 2025 10:02:52 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
Message-ID: <9X5jNqTgRU5aOnn8WtKkcX7JGPNphMbyV1LOG9vuV_o=.4326378f-a1df-4206-a58d-466020b1261d@github.com>

On Wed, 22 Jan 2025 14:29:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider!
>> 
>> This patch the Zfa zli floating point immediate load.
>> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
>> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
>> 
>> When using one of the 32 'popular' floats we can now materialze them without a load.
>> E.g.
>> `float f = f1 * 0.5 + f2 * 2.0;`
>> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
>> 
>> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
>> 
>> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
>> 
>> Passes:
>> ./test/jdk/java/lang/Math
>> ./test/hotspot/jtreg/compiler/floatingpoint/
>> ./test/jdk/java/util/Formatter/
>> ./test/jdk/java/lang/Float/
>> ./test/jdk/java/lang/Double/
>> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
>> ./test/hotspot/jtreg/compiler/eliminateAutobox/
>> ./test/hotspot/jtreg/vmTestbase/jit/
>> 
>> Running tier1
>> 
>> Thanks!
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zfa
>  - Merge branch 'master' into zfa
>  - EXPERIMENTAL
>  - Merge branch 'master' into zfa
>  - Merge branch 'master' into zfa
>  - Flip bool static decl
>  - Merge branch 'master' into zfa
>  - Baseline

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23171#pullrequestreview-2572208023

From kevinw at openjdk.org  Fri Jan 24 10:21:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 10:21:45 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <TIdNnxTG7pqGZa6knY80iOp0xjtmfFCt1TRQUcHKG8A=.cca77d61-c285-45fe-8d14-db2173b46ac2@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 168:

> 166:       JvmtiAgentThread, NotificationThread, MonitorDeflationThread,
> 167:       StringDedupThread, AttachListenerThread, DeoptimizeObjectsALotThread and
> 168:       ServiceThread. The latter seven subclasses of the former. Most operations

The latter eight are subclasses of the former? 8-) Or just "JavaThread, or its subclasses..."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1928457607

From kevinw at openjdk.org  Fri Jan 24 10:25:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 10:25:45 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <tzhNl0atcSwmopzzmLMbW5sfpIV5gawT7T4MzMz0oyg=.55d1f427-e5dd-401a-a771-3d60538d161b@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2572270646

From jbhateja at openjdk.org  Fri Jan 24 10:39:34 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 24 Jan 2025 10:39:34 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v12]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <DGN7lI-1ytNB4X9iZS5RKFt6RUsXO1gknKmTJLNIOkY=.5f6da603-2a48-47ff-983e-f16b69909aa3@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Rebasing to jdk mainline
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103
 - Refining IR match rule
 - Review suggestions incorporated.
 - Review comments resolutions
 - Updating copyright year of modified files.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103
 - Review suggestions incorporated.
 - Review comments resolutions
 - Addressing review comments
 - ... and 4 more: https://git.openjdk.org/jdk/compare/4a375e5b...e0602c1d

-------------

Changes: https://git.openjdk.org/jdk/pull/22754/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=11
  Stats: 2864 lines in 56 files changed: 2797 ins; 0 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Fri Jan 24 10:39:34 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 24 Jan 2025 10:39:34 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
Message-ID: <NqzykMhBjgQ8xyFP8Adurw3lFdet7lLgV0Uvsad3yLA=.8d92b867-cc75-4605-898d-e46d14338cf7@github.com>

On Fri, 17 Jan 2025 16:02:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java

Hi @eme64 , Rebased to the latest mainline code please proceed with test runs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2612203710

From aph at openjdk.org  Fri Jan 24 10:41:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 24 Jan 2025 10:41:54 GMT
Subject: Integrated: 8346890: AArch64: Type profile counters generate
 suboptimal code
In-Reply-To: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
References: <qsGgTNc_i-Z4o7C-48Lr8Zh4Rm7gdYbKUTORl5KNGd4=.c6253c4e-9da3-46f6-a5cf-74a798efed61@github.com>
Message-ID: <LWQVUPQ586qCRRuyJFYcXMsh4hPxUlEHka9flb_PkHA=.b4c9e1e3-d964-4f0c-b922-48b8609c3c7c@github.com>

On Thu, 9 Jan 2025 16:30:49 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Type profile counters are emitted many times in C1-generated code. The generator was written a long time ago before we knew how best to write AArch64 code, and the generated code is rather suboptimal.
> 
> This PR reduces the size of a typical bimorphic type profile counter from 33 to 27 instructions.

This pull request has now been integrated.

Changeset: 5a0bdd04
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a0bdd04e0d62bbdd01373510cb1d06c586e69b3
Stats:     30 lines in 2 files changed: 16 ins; 6 del; 8 mod

8346890: AArch64: Type profile counters generate suboptimal code

Reviewed-by: shade, adinn

-------------

PR: https://git.openjdk.org/jdk/pull/23012

From rehn at openjdk.org  Fri Jan 24 10:58:50 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 24 Jan 2025 10:58:50 GMT
Subject: RFR: 8347981: RISC-V: Add Zfa zli imm loads [v3]
In-Reply-To: <9X5jNqTgRU5aOnn8WtKkcX7JGPNphMbyV1LOG9vuV_o=.4326378f-a1df-4206-a58d-466020b1261d@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
 <RmIrM08I6xG3mn0O707ALohvHAMJUoiDkkH4lZowQc4=.d85b2312-0a57-4292-88c8-cd438845b69a@github.com>
 <9X5jNqTgRU5aOnn8WtKkcX7JGPNphMbyV1LOG9vuV_o=.4326378f-a1df-4206-a58d-466020b1261d@github.com>
Message-ID: <lOajGiX3FfS6z_MFmRl6PeajZX4ya4RosOA3xhnFd8w=.916eba32-e40f-4a84-9e64-5e04c2a90be9@github.com>

On Fri, 24 Jan 2025 09:59:49 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into zfa
>>  - Merge branch 'master' into zfa
>>  - EXPERIMENTAL
>>  - Merge branch 'master' into zfa
>>  - Merge branch 'master' into zfa
>>  - Flip bool static decl
>>  - Merge branch 'master' into zfa
>>  - Baseline
>
> Marked as reviewed by luhenry (Committer).

Thank you @luhenry !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23171#issuecomment-2612240638

From cnorrbin at openjdk.org  Fri Jan 24 11:21:37 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 24 Jan 2025 11:21:37 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v16]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <rsuFkvQF_jeb-96vYnZMkOeNAq0o73P4OXqg3nucKAk=.222fb077-250d-4ea9-bea6-c8a0e69d52cb@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - readd find_enclosing_range
 - Merge branch 'master' into rb-tree
 - treap swap fix
 - const functions
 - thomas feedback
 - axel feedback
 - clarified comment
 - Improved comments
 - chaged assert to EXPECTs in node tests
 - additonal node stability test
 - ... and 24 more: https://git.openjdk.org/jdk/compare/0fbf10a9...aa0d1ee0

-------------

Changes: https://git.openjdk.org/jdk/pull/22360/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=15
  Stats: 1437 lines in 3 files changed: 1437 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From cnorrbin at openjdk.org  Fri Jan 24 11:23:52 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 24 Jan 2025 11:23:52 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v15]
In-Reply-To: <FjIqhbSdlF-9r9WzQeduvVPdmd9-W5VOH7PjYbMRDps=.9fba5e9d-23c3-420d-abb4-1b7f50ef1196@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Irrr_XaOYHNksyXYkVNDQyCp5-Fjjf3B5wwTVcYNzb0=.8cf9b973-d50a-4944-a606-5ff447121abb@github.com>
 <FjIqhbSdlF-9r9WzQeduvVPdmd9-W5VOH7PjYbMRDps=.9fba5e9d-23c3-420d-abb4-1b7f50ef1196@github.com>
Message-ID: <cUyJuoXQVR0vNMICLP3XilRNo2BcKMUIkY0_2bezVqA=.5f6ca7ee-febf-4c0f-8545-ec8dd11c226b@github.com>

On Thu, 23 Jan 2025 17:57:04 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   treap swap fix
>
> Hmm, I still can't compile it, I see:
> 
> 
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:235:18: error: expected ';' after expression
>   235 |   VMATreap::Range range(nullptr, nullptr);
>       |                  ^
>       |                  ;
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:235:13: error: no member named 'Range' in 'RBTree<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, RBTreeCHeapAllocator<MemTag::mtNMT>>'
>   235 |   VMATreap::Range range(nullptr, nullptr);
>       |   ~~~~~~~~~~^
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:235:19: error: use of undeclared identifier 'range'
>   235 |   VMATreap::Range range(nullptr, nullptr);
>       |                   ^
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:240:5: error: use of undeclared identifier 'range'
>   240 |     range = _tree.find_enclosing_range(from);
>       |     ^
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:240:19: error: no member named 'find_enclosing_range' in 'RBTree<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, RBTreeCHeapAllocator<MemTag::mtNMT>>'
>   240 |     range = _tree.find_enclosing_range(from);
>       |             ~~~~~ ^
> /Users/gerard/Work/bugs/8317453/jdk/src/hotspot/share/nmt/vmatree.cpp:241:10: error: use of undeclared identifier 'range'
>   241 |     if ((range.start == nullptr && range.end == nullptr) ||
>       |          ^

@gerard-ziemski That one is on me! I still had an old copy of VMATree that didn't have `find_enclosing range`. I've added it now and tested with the latest version, so hopefully there should not be any more issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2612285325

From mdoerr at openjdk.org  Fri Jan 24 11:34:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 24 Jan 2025 11:34:50 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v12]
In-Reply-To: <5bhEDHXvXHpx8vSgyoi8QD8zLWTMG1HD6o_tC74_i-E=.16243801-4270-45ad-a412-fee7c7d543a9@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <5bhEDHXvXHpx8vSgyoi8QD8zLWTMG1HD6o_tC74_i-E=.16243801-4270-45ad-a412-fee7c7d543a9@github.com>
Message-ID: <GyOtH-mxuhzURQ5QS2GaHdRRUlJsSS1KM58NoeG1WaQ=.d49bacc6-87a3-424a-b3ac-22dcbd9d0772@github.com>

On Thu, 23 Jan 2025 16:46:27 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

There are test failures:
- compiler/codegen/aes/TestAESMain.java
- com/sun/crypto/provider/Cipher/AES/TestCopySafe.java
- many jdk tier2 http and ssl tests

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2612304487

From stefank at openjdk.org  Fri Jan 24 11:35:19 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 24 Jan 2025 11:35:19 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc, heap, 
 coops) for ReservedCodeSpace failures
Message-ID: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>

The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.

While doing this change I also added some extra info about the area that we tried to reserve and commit.

A couple of G1 tests had to be tweaked.

-------------

Commit messages:
 - log_on_large_pages_failure reports log_debug(gc, heap, coops) for ReservedCodeSpace failures

Changes: https://git.openjdk.org/jdk/pull/23297/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23297&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321529
  Stats: 20 lines in 3 files changed: 8 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23297/head:pull/23297

PR: https://git.openjdk.org/jdk/pull/23297

From stefank at openjdk.org  Fri Jan 24 11:35:19 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 24 Jan 2025 11:35:19 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures
In-Reply-To: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
Message-ID: <eKT9Hfoc0g3-mP5wBq9-G7n4h1dSXsmuSUaVz9nc6FY=.d305c5a9-d691-4d3c-a602-353611a763c0@github.com>

On Fri, 24 Jan 2025 11:29:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.
> 
> While doing this change I also added some extra info about the area that we tried to reserve and commit.
> 
> A couple of G1 tests had to be tweaked.

Note that I used JDK-8321529, which is a bug that @eastig created a over a year ago. Evgeny do you think this is a decent fix? Or do you need something else? Is it OK if I make this change under your bug or do you want me to create a separate bug for this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23297#issuecomment-2612305513

From rehn at openjdk.org  Fri Jan 24 11:49:56 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 24 Jan 2025 11:49:56 GMT
Subject: Integrated: 8347981: RISC-V: Add Zfa zli imm loads
In-Reply-To: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
References: <W-XYEEtdFhbak_klQbVaH-YtzzPfUym6iC-lH0jPB84=.47d4be59-1149-4176-997a-a67a2190c9a6@github.com>
Message-ID: <hk0txL-FIrcZ-kRDjXdtnN6HMOzGzid-dF9_NLOHWdE=.8bd92706-defb-4989-a4e0-9ba155136544@github.com>

On Fri, 17 Jan 2025 08:47:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider!
> 
> This patch the Zfa zli floating point immediate load.
> As a bonus it adds fmv_?_x(Rd, zr); for loading fp/dp 0x0.
> There are some more instruction in Zfa, but this was such a clear use-case so I only did fli as a start.
> 
> When using one of the 32 'popular' floats we can now materialze them without a load.
> E.g.
> `float f = f1 * 0.5 + f2 * 2.0;`
> Only require 2 loads instead of 4: as '0.5' and '2.0' is such popular float values.
> 
> As Java is often memory bound we should also investigate doing lui+ssli+fmv for float/doubles instead of a load when materializing.
> 
> Note the _fli_s/_fli_d will be proper merged on the 8347794: RISC-V: Add Zfhmin - Float cleanup.
> 
> Passes:
> ./test/jdk/java/lang/Math
> ./test/hotspot/jtreg/compiler/floatingpoint/
> ./test/jdk/java/util/Formatter/
> ./test/jdk/java/lang/Float/
> ./test/jdk/java/lang/Double/
> ./test/hotspot/jtreg/compiler/c2/FloatingPointFoldingTest.java
> ./test/hotspot/jtreg/compiler/eliminateAutobox/
> ./test/hotspot/jtreg/vmTestbase/jit/
> 
> Running tier1
> 
> Thanks!

This pull request has now been integrated.

Changeset: 9c55e253
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c55e2538c5c7374d6f4589d8bdd45ee205276f1
Stats:     192 lines in 7 files changed: 183 ins; 0 del; 9 mod

8347981: RISC-V: Add Zfa zli imm loads

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/23171

From coleenp at openjdk.org  Fri Jan 24 12:50:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Jan 2025 12:50:49 GMT
Subject: RFR: 8334320: Replace
 vmTestbase/metaspace/share/TriggerUnloadingWithWhiteBox.java with
 ClassUnloadCommon from testlibrary
In-Reply-To: <Ksm0Ks2LeRw5B-pm2VL6tuQg11d5ivEMftSKoeceTso=.4da2555a-e6ba-4f83-a2ee-5a0da1740afc@github.com>
References: <Ksm0Ks2LeRw5B-pm2VL6tuQg11d5ivEMftSKoeceTso=.4da2555a-e6ba-4f83-a2ee-5a0da1740afc@github.com>
Message-ID: <jtkKKU5yo-ICmxuIbyv6tnv4H6eIpIB7KyS6j6ve8vU=.4346523e-b73a-4b46-b493-f917699625b9@github.com>

On Fri, 17 Jan 2025 13:43:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Rename and make TriggerUnloadingWithWhiteBox call ClassUnloadCommon.triggerUnloading() instead of WB.fullGC().

@tstuefe Can you review and comment since you added these tests?  Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23174#issuecomment-2612454953

From jvernee at openjdk.org  Fri Jan 24 15:50:47 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 24 Jan 2025 15:50:47 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni [v3]
In-Reply-To: <N_Ovwfxffj9EDpOUjYzgqEQ9yPeaTAWO5HM3R6A5tE4=.3d21b08c-e453-4f3c-bcbd-93635fb8e290@github.com>
References: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>
 <Qr5PrJudM7WMHlsf4T5azeW343hIug9ChYPjEoucLbc=.da53cb18-e12c-4772-954d-5f3a337d05bb@github.com>
 <N_Ovwfxffj9EDpOUjYzgqEQ9yPeaTAWO5HM3R6A5tE4=.3d21b08c-e453-4f3c-bcbd-93635fb8e290@github.com>
Message-ID: <m13LHpQfDz5TM3oG4Eo1nolkSFtB-mHVbu7yj0xI6AY=.550c4c7f-40a0-470f-975c-c1a418247453@github.com>

On Thu, 23 Jan 2025 18:23:01 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

>> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 185:
> 
>> 183:       // On ECore, restore with signaling flags enabled
>> 184:       MxCsr |= 0x3F;
>> 185:     }
> 
> @JornVernee I came across your comment https://github.com/openjdk/jdk/pull/14523/files#r1236920072
> 
> I believe I am following the 'spirit' of that comment here, but would appreciate you having a look.

Yes, I think so. Originally I was seeing some cases where we were always resetting MxCsr, even for unrelated exceptions. The new code still only resets it for the FLT_* exceptions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1928894440

From gziemski at openjdk.org  Fri Jan 24 16:28:58 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 24 Jan 2025 16:28:58 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v16]
In-Reply-To: <rsuFkvQF_jeb-96vYnZMkOeNAq0o73P4OXqg3nucKAk=.222fb077-250d-4ea9-bea6-c8a0e69d52cb@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <rsuFkvQF_jeb-96vYnZMkOeNAq0o73P4OXqg3nucKAk=.222fb077-250d-4ea9-bea6-c8a0e69d52cb@github.com>
Message-ID: <1T0nh-OumW27Un5IERLFc-9vMQ6y9RWaOR_xyr_vWmY=.b16aa77f-d3c8-44d2-b9a4-6ae3d986dc70@github.com>

On Fri, 24 Jan 2025 11:21:37 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - readd find_enclosing_range
>  - Merge branch 'master' into rb-tree
>  - treap swap fix
>  - const functions
>  - thomas feedback
>  - axel feedback
>  - clarified comment
>  - Improved comments
>  - chaged assert to EXPECTs in node tests
>  - additonal node stability test
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/0fbf10a9...aa0d1ee0

>From the point of view of my benchmark, using data recorded from a java server with 10k accesses, the performance looks identical. I ran benchmark 100 times for each and chose the fastest run:

`time:194,279[ns] [samples:1,803]` vs `time:194,516[ns] [samples:1,803]`

No recursion and deterministic behavior (no dependency on 64bit random), however, in my opinion gives RBTree an advantage over Treaps. Good job!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2612923335

From ysr at openjdk.org  Fri Jan 24 18:44:53 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 24 Jan 2025 18:44:53 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace
 instances [v2]
In-Reply-To: <52g1j3w9Wl6NwJqpJI-Im6Smp9wPb4IGtNkRpkTsPMI=.8d4cf740-4b91-4c0c-a957-b32c1d5bd85d@github.com>
References: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>
 <iW8WAEm45XfsTIobS1Ra8vosG3DUXs2FGcrHI9WBnJA=.40eacded-36d6-4c81-9b47-69ce72a750e9@github.com>
 <52g1j3w9Wl6NwJqpJI-Im6Smp9wPb4IGtNkRpkTsPMI=.8d4cf740-4b91-4c0c-a957-b32c1d5bd85d@github.com>
Message-ID: <JOeKkb7vP3-o1RhHvoPRlSPhMJ-Oz_egXkKl86iETAw=.5b3fb25c-906f-42e6-b253-4779c46e7281@github.com>

On Thu, 23 Jan 2025 18:15:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Filed https://bugs.openjdk.org/browse/JDK-8348420 to follow up for Shenandoah.

Thank you William!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22825#issuecomment-2613165189

From cjplummer at openjdk.org  Fri Jan 24 20:15:49 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:15:49 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <TIdNnxTG7pqGZa6knY80iOp0xjtmfFCt1TRQUcHKG8A=.cca77d61-c285-45fe-8d14-db2173b46ac2@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <TIdNnxTG7pqGZa6knY80iOp0xjtmfFCt1TRQUcHKG8A=.cca77d61-c285-45fe-8d14-db2173b46ac2@github.com>
Message-ID: <xqTf-pvHCfg_l7X-ltKhWvg33zaNJVmEWjatLVLb-DI=.a5fa3185-3a78-402f-b079-214544cca3c1@github.com>

On Fri, 24 Jan 2025 10:19:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
>> 
>> 
>>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> 
>> 
>> The following can be used to reproduce this failure. Most SA tests will fail:
>> 
>>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
>> 
>> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
>> 
>> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 168:
> 
>> 166:       JvmtiAgentThread, NotificationThread, MonitorDeflationThread,
>> 167:       StringDedupThread, AttachListenerThread, DeoptimizeObjectsALotThread and
>> 168:       ServiceThread. The latter seven subclasses of the former. Most operations
> 
> The latter eight are subclasses of the former? 8-) Or just "JavaThread, or its subclasses..."

Yes, it should be updated to eight, but I think what would be better is "returns objects of type JavaThraed or one of its subclasses..."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1929185927

From cjplummer at openjdk.org  Fri Jan 24 20:22:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:22:07 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23279/files
  - new: https://git.openjdk.org/jdk/pull/23279/files/8ba5e23a..5779c9eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23279&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23279&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23279/head:pull/23279

PR: https://git.openjdk.org/jdk/pull/23279

From cjplummer at openjdk.org  Fri Jan 24 20:22:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:22:07 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <xqTf-pvHCfg_l7X-ltKhWvg33zaNJVmEWjatLVLb-DI=.a5fa3185-3a78-402f-b079-214544cca3c1@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <TIdNnxTG7pqGZa6knY80iOp0xjtmfFCt1TRQUcHKG8A=.cca77d61-c285-45fe-8d14-db2173b46ac2@github.com>
 <xqTf-pvHCfg_l7X-ltKhWvg33zaNJVmEWjatLVLb-DI=.a5fa3185-3a78-402f-b079-214544cca3c1@github.com>
Message-ID: <K2qxJO4zLE7N9nEuihbK9Su17XFsuPqWyFEjr6dvk6Y=.89c33ab4-176e-40da-bc25-b3bed1a8ab2a@github.com>

On Fri, 24 Jan 2025 20:13:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 168:
>> 
>>> 166:       JvmtiAgentThread, NotificationThread, MonitorDeflationThread,
>>> 167:       StringDedupThread, AttachListenerThread, DeoptimizeObjectsALotThread and
>>> 168:       ServiceThread. The latter seven subclasses of the former. Most operations
>> 
>> The latter eight are subclasses of the former? 8-) Or just "JavaThread, or its subclasses..."
>
> Yes, it should be updated to eight, but I think what would be better is "returns objects of type JavaThraed or one of its subclasses..."

Ok, it's fixed now. I stuck with a somewhat minimal update mostly just to resolve the incorrect count. This comment may have further cleanup as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1929190501

From dlong at openjdk.org  Fri Jan 24 22:54:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 24 Jan 2025 22:54:51 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
 <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>
Message-ID: <HQlT0k_cC6fh2GBZZpl2wNREhuQTANK-NfqtP3Xsw-k=.20abae09-54f2-4681-96e7-bc88a610c9fd@github.com>

On Thu, 23 Jan 2025 22:30:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > Overall the changes seem fine, however it would be nice if the vmStructs.cpp registration mechanism was modular and extensible, instead of monolithic. That would make it easier to register private types, or even types outside of libjvm.
> 
> I'm not too sure what you are suggesting here.

For example, instead of a single table, allow multiple tables.  They could be registered with with an API similar to JNI RegisterNatives.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2613547838

From kevinw at openjdk.org  Fri Jan 24 22:58:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 22:58:47 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>
Message-ID: <IZASOZekd_Rg1q9Ab0cn1Dc5Tmo63jezhMi-0O01xts=.05e7d0ec-0013-4e0a-bc83-c334e8657762@github.com>

On Fri, 24 Jan 2025 20:22:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
>> 
>> 
>>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> 
>> 
>> The following can be used to reproduce this failure. Most SA tests will fail:
>> 
>>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
>> 
>> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
>> 
>> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup comment

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2573741547

From cjplummer at openjdk.org  Fri Jan 24 23:26:46 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 23:26:46 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <HQlT0k_cC6fh2GBZZpl2wNREhuQTANK-NfqtP3Xsw-k=.20abae09-54f2-4681-96e7-bc88a610c9fd@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
 <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>
 <HQlT0k_cC6fh2GBZZpl2wNREhuQTANK-NfqtP3Xsw-k=.20abae09-54f2-4681-96e7-bc88a610c9fd@github.com>
Message-ID: <O3pxJ-hCpGKGo7TDrzqBhPHnstCu_gHHcLwJSBmjqt4=.e647ecea-75a0-4393-94c9-1278a9f728cf@github.com>

On Fri, 24 Jan 2025 22:52:19 GMT, Dean Long <dlong at openjdk.org> wrote:

> > > Overall the changes seem fine, however it would be nice if the vmStructs.cpp registration mechanism was modular and extensible, instead of monolithic. That would make it easier to register private types, or even types outside of libjvm.
> > 
> > 
> > I'm not too sure what you are suggesting here.
> 
> For example, instead of a single table, allow multiple tables. They could be registered with with an API similar to JNI RegisterNatives.

I don't see how that relates to this change. It sounds more like a general suggestion to overhaul of how vmStructs is implemented.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2613584454

From dlong at openjdk.org  Sat Jan 25 01:29:47 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 25 Jan 2025 01:29:47 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <O3pxJ-hCpGKGo7TDrzqBhPHnstCu_gHHcLwJSBmjqt4=.e647ecea-75a0-4393-94c9-1278a9f728cf@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
 <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>
 <HQlT0k_cC6fh2GBZZpl2wNREhuQTANK-NfqtP3Xsw-k=.20abae09-54f2-4681-96e7-bc88a610c9fd@github.com>
 <O3pxJ-hCpGKGo7TDrzqBhPHnstCu_gHHcLwJSBmjqt4=.e647ecea-75a0-4393-94c9-1278a9f728cf@github.com>
Message-ID: <1i5RWKGP-ICfyoE21UB2OQT5QTkU6dGHPmzLW9o3-ME=.75b5a4f5-7bc1-4629-9775-8f3aa37fc257@github.com>

On Fri, 24 Jan 2025 23:23:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I don't see how that relates to this change. It sounds more like a general suggestion to overhaul of how vmStructs is implemented.

It relates because if something like that was available then we could register types that are local to a .cpp file without moving them to a .hpp first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2613705537

From cslucas at openjdk.org  Sat Jan 25 02:38:55 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Sat, 25 Jan 2025 02:38:55 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <lNguXjkHP0ET0RdCYmR_QIlNUQlwa_jIxklZ4pMLqYc=.952dcda2-8cdf-4bd9-bf8f-6897f9267d1a@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <lNguXjkHP0ET0RdCYmR_QIlNUQlwa_jIxklZ4pMLqYc=.952dcda2-8cdf-4bd9-bf8f-6897f9267d1a@github.com>
Message-ID: <yisMPBJ3kO9OIF1KvKxN8btxfaL9THkrFvKC8YRsdYs=.fff2a972-2a79-4628-894c-4e96e4339fa5@github.com>

On Fri, 17 Jan 2025 15:06:33 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Thanks for implementing this very important feature which already improves performance (and which will further unlock better performance when init-mark becomes a per-thread handshake in the future).
> 
>> Our internal performance testing showed a significant reduction in the duration of init-mark pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
> 
> It would be great if you can include some performance numbers either in this PR or, preferably, in the JBS ticket.
> 
> Thanks!

@ysramakrishna - I attached to the RFE a graph showing the reduction in init-pause duration when executing SPECJBB2015 on x86_64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2613735937

From iklam at openjdk.org  Mon Jan 27 05:48:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 27 Jan 2025 05:48:28 GMT
Subject: RFR: 8348349: Refactor CDSConfig::is_dumping_heap()
Message-ID: <aJSxWYbphwjmduPtneuham3ICMNxPNl_n45g5uZhNLw=.d3cef46f-715d-4586-8cb0-fbe99fa118ee@github.com>

Please review this small clean up:

`HeapShared::can_write()` and `CDSConfig::is_dumping_heap()` are both for deciding whether CDS should dump heap objects. I removed the former and consolidated all the logic to the latter.

I also updated the logging message in case heap objects cannot be dumped.

I also updated VMProps to clarify what `vmCDSCanWriteArchivedJavaHeap()` means.

-------------

Commit messages:
 - Fixed whitespace
 - Fixed 32-bit build
 - 8348349: Refactor HeapShared::can_write()

Changes: https://git.openjdk.org/jdk/pull/23249/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23249&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348349
  Stats: 117 lines in 12 files changed: 59 ins; 36 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/23249.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23249/head:pull/23249

PR: https://git.openjdk.org/jdk/pull/23249

From matsaave at openjdk.org  Mon Jan 27 05:48:29 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 27 Jan 2025 05:48:29 GMT
Subject: RFR: 8348349: Refactor CDSConfig::is_dumping_heap()
In-Reply-To: <aJSxWYbphwjmduPtneuham3ICMNxPNl_n45g5uZhNLw=.d3cef46f-715d-4586-8cb0-fbe99fa118ee@github.com>
References: <aJSxWYbphwjmduPtneuham3ICMNxPNl_n45g5uZhNLw=.d3cef46f-715d-4586-8cb0-fbe99fa118ee@github.com>
Message-ID: <I2RWfR6XjjAo-jWV4ST3OXURbwEoCYkxUfjakfyQqyU=.2352d434-1830-43c9-ab8b-11d7af6136f9@github.com>

On Thu, 23 Jan 2025 02:35:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this small clean up:
> 
> `HeapShared::can_write()` and `CDSConfig::is_dumping_heap()` are both for deciding whether CDS should dump heap objects. I removed the former and consolidated all the logic to the latter.
> 
> I also updated the logging message in case heap objects cannot be dumped.
> 
> I also updated VMProps to clarify what `vmCDSCanWriteArchivedJavaHeap()` means.

Change looks good, thanks for the cleanup! I have some small comments that you can address if you think it's valuable:

src/hotspot/share/cds/cdsConfig.cpp line 572:

> 570: bool CDSConfig::is_dumping_heap() {
> 571:   // heap dump is not supported in dynamic dump
> 572:   if (!is_dumping_static_archive()) {

I think you can compress these three cases into one if-statement

src/hotspot/share/cds/cdsConfig.hpp line 49:

> 47: 
> 48:   static bool  _old_cds_flags_used;
> 49:   static bool  _disable_heap_dumping;

Following with the previous implementation, I'd prefer `can_dump_heap` to avoid the double negative.

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23249#pullrequestreview-2571137386
PR Review Comment: https://git.openjdk.org/jdk/pull/23249#discussion_r1927751925
PR Review Comment: https://git.openjdk.org/jdk/pull/23249#discussion_r1927759369

From iklam at openjdk.org  Mon Jan 27 05:51:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 27 Jan 2025 05:51:58 GMT
Subject: RFR: 8348349: Refactor CDSConfig::is_dumping_heap() [v2]
In-Reply-To: <aJSxWYbphwjmduPtneuham3ICMNxPNl_n45g5uZhNLw=.d3cef46f-715d-4586-8cb0-fbe99fa118ee@github.com>
References: <aJSxWYbphwjmduPtneuham3ICMNxPNl_n45g5uZhNLw=.d3cef46f-715d-4586-8cb0-fbe99fa118ee@github.com>
Message-ID: <9oFUK6ektKeH7tMcXqYPS_jCn6TsNTal_JPUAhioZrg=.3241f2d3-49d1-4ba7-8aeb-e266da61a026@github.com>

> Please review this small clean up:
> 
> `HeapShared::can_write()` and `CDSConfig::is_dumping_heap()` are both for deciding whether CDS should dump heap objects. I removed the former and consolidated all the logic to the latter.
> 
> I also updated the logging message in case heap objects cannot be dumped.
> 
> I also updated VMProps to clarify what `vmCDSCanWriteArchivedJavaHeap()` means.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @matias9927 comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23249/files
  - new: https://git.openjdk.org/jdk/pull/23249/files/5993ef74..a6a77ca7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23249&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23249&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23249.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23249/head:pull/23249

PR: https://git.openjdk.org/jdk/pull/23249

From iklam at openjdk.org  Mon Jan 27 06:02:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 27 Jan 2025 06:02:54 GMT
Subject: RFR: 8348349: Refactor CDSConfig::is_dumping_heap() [v2]
In-Reply-To: <I2RWfR6XjjAo-jWV4ST3OXURbwEoCYkxUfjakfyQqyU=.2352d434-1830-43c9-ab8b-11d7af6136f9@github.com>
References: <aJSxWYbphwjmduPtneuham3ICMNxPNl_n45g5uZhNLw=.d3cef46f-715d-4586-8cb0-fbe99fa118ee@github.com>
 <I2RWfR6XjjAo-jWV4ST3OXURbwEoCYkxUfjakfyQqyU=.2352d434-1830-43c9-ab8b-11d7af6136f9@github.com>
Message-ID: <mtvW0nUawVqvNAbVViCnQ9yZ50lN7drDz16BwnUGY6k=.7e11054b-2180-4cff-bc09-1604aa18e48b@github.com>

On Thu, 23 Jan 2025 22:14:06 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @matias9927 comment
>
> src/hotspot/share/cds/cdsConfig.cpp line 572:
> 
>> 570: bool CDSConfig::is_dumping_heap() {
>> 571:   // heap dump is not supported in dynamic dump
>> 572:   if (!is_dumping_static_archive()) {
> 
> I think you can compress these three cases into one if-statement

Fixed.

> src/hotspot/share/cds/cdsConfig.hpp line 49:
> 
>> 47: 
>> 48:   static bool  _old_cds_flags_used;
>> 49:   static bool  _disable_heap_dumping;
> 
> Following with the previous implementation, I'd prefer `can_dump_heap` to avoid the double negative.

`_disable_heap_dumping` is for unconditionally disabling heap dumping. The opposite does not mean we can dump the heap -- heap dumping can also be disabled if ZGC is used. So `can_dump_heap` will be misleading.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23249#discussion_r1930017837
PR Review Comment: https://git.openjdk.org/jdk/pull/23249#discussion_r1930017826

From epeter at openjdk.org  Mon Jan 27 06:52:06 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 27 Jan 2025 06:52:06 GMT
Subject: RFR: 8323582: C2 SuperWord AlignVector: misaligned vector memory
 access with unaligned native memory
Message-ID: <pVg3luDG6rcogJccQNhdBPlNNyLclJwqrRy6D9PYcfI=.759355f9-d318-4b1c-a1e1-fe2071922da8@github.com>

Note: the approach with Predicates and Multiversioning prepares us well for Runtime Checks for Aliasing Analysis, see more below.

**Background**

With `-XX:+AlignVector`, all vector loads/stores must be aligned. We try to statically determine if we can always align the vectors. One condition is that the address `base` is already aligned. For arrays, we know that this always holds, because they are `ObjectAlignmentInBytes` aligned. But with native memory, the `base` is just some arbitrarily aligned pointer.

**Problem**

So far, we have just naively assumed that the `base` is always `ObjectAlignmentInBytes` aligned. But that does not hold for `native` memory segments: the `base` can also be unaligned. I had constructed such an example, and with `-XX:+AlignVector -XX:+VerifyAlignVector` this example hits the verification code.


MemorySegment nativeAligned = Arena.ofAuto().allocate(RANGE * 4 + 1);
MemorySegment nativeUnaligned = nativeAligned.asSlice(1);
test3(nativeUnaligned);


When compiling the test method, we assume that the `nativeUnaligned.address()` is aligned - but it is not!

    static void test3(MemorySegment ms) {
        for (int i = 0; i < RANGE; i++) {
            long adr = i * 4L;
            int v = ms.get(ELEMENT_LAYOUT, adr);
            ms.set(ELEMENT_LAYOUT, adr, (int)(v + 1));
        }
    }


**Solution: Runtime Checks - Predicate and Multiversioning**

Of course we could just forbid cases where we have a `native` base from vectorizing. But that would lead to regressions currently - in most cases we do get aligned `base`s, and we currently vectorize those. We cannot statically determine if the `base` is aligned, we need a runtime check.

I came up with 2 options where to place the runtime checks:
- A new "auto vectorization" Parse Predicate:
  - This only works when predicates are available.
  - If we fail the predicate, then we recompile without the predicate. That means we cannot add a check to the predicate any more, and we would have to do multiversioning at that point if we still want to have a vectorized loop.
- Multiversion the loop:
  - Create 2 copies of the loop (fast and slow loops).
  - The `fast_loop` can make speculative alignment assumptions, and add the corresponding check to the `multiversion_if` which decides which loop we take
  - In the `slow_loop`, we make no assumption which means we can not vectorize, but we still compile - so even unaligned `base`s would end up with reasonably fast code.
  - We "stall" the `slow_loop` from optimizing until we have fully vectorized the `fast_loop`, and know that we actually are adding runtime checks to the `multiversion_if`, and we really need the `slow_loop`.

Hence, the goal is that we compile like this:
- First with predicate: if we are lucky we never see an unaligned `base`.
- If we fail the check at the predicate: deopt, next time do not use the predicate for that loop.
- When we recompile, we find no predicate, and instead multiversion the loop, so that we can compile both for aligned (vectorize) and unaligned (not vectorize) `base`.


**Future Work: Runtime Check for Aliasing Analysis**

See: [JDK-8324751](https://bugs.openjdk.org/browse/JDK-8324751): C2 SuperWord: Aliasing Analysis runtime check
This whole infrastructure with "auto vectorization" Parse Predicate and Multiversioning can be used when we implement Runtime Checks for Aliasing Analysis: We speculate that there is no aliasing. If the runtime check fails, we deopt at the predicate, or take the `slow_loop` for Multiversioning.

-------------

Commit messages:
 - remove multiversion mark if we break the structure
 - register opaque with igvn
 - copyright and rm CFG check
 - IR rules for all cases
 - 3 test versions
 - test changed to unaligned ints
 - stub for slicing
 - add Verify/AlignVector runs to test
 - refactor verify
 - rm TODO
 - ... and 52 more: https://git.openjdk.org/jdk/compare/16dcf15a...c53985f6

Changes: https://git.openjdk.org/jdk/pull/22016/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323582
  Stats: 1074 lines in 27 files changed: 951 ins; 28 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/22016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22016/head:pull/22016

PR: https://git.openjdk.org/jdk/pull/22016

From epeter at openjdk.org  Mon Jan 27 06:52:07 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 27 Jan 2025 06:52:07 GMT
Subject: RFR: 8323582: C2 SuperWord AlignVector: misaligned vector memory
 access with unaligned native memory
In-Reply-To: <pVg3luDG6rcogJccQNhdBPlNNyLclJwqrRy6D9PYcfI=.759355f9-d318-4b1c-a1e1-fe2071922da8@github.com>
References: <pVg3luDG6rcogJccQNhdBPlNNyLclJwqrRy6D9PYcfI=.759355f9-d318-4b1c-a1e1-fe2071922da8@github.com>
Message-ID: <LSgd-nNr8SHzaBSHliijfJWii8-Zq3rWKvi_2KKOozE=.7103653a-dd75-4ed2-a87e-8160266c6fe3@github.com>

On Mon, 11 Nov 2024 14:40:09 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Note: the approach with Predicates and Multiversioning prepares us well for Runtime Checks for Aliasing Analysis, see more below.
> 
> **Background**
> 
> With `-XX:+AlignVector`, all vector loads/stores must be aligned. We try to statically determine if we can always align the vectors. One condition is that the address `base` is already aligned. For arrays, we know that this always holds, because they are `ObjectAlignmentInBytes` aligned. But with native memory, the `base` is just some arbitrarily aligned pointer.
> 
> **Problem**
> 
> So far, we have just naively assumed that the `base` is always `ObjectAlignmentInBytes` aligned. But that does not hold for `native` memory segments: the `base` can also be unaligned. I had constructed such an example, and with `-XX:+AlignVector -XX:+VerifyAlignVector` this example hits the verification code.
> 
> 
> MemorySegment nativeAligned = Arena.ofAuto().allocate(RANGE * 4 + 1);
> MemorySegment nativeUnaligned = nativeAligned.asSlice(1);
> test3(nativeUnaligned);
> 
> 
> When compiling the test method, we assume that the `nativeUnaligned.address()` is aligned - but it is not!
> 
>     static void test3(MemorySegment ms) {
>         for (int i = 0; i < RANGE; i++) {
>             long adr = i * 4L;
>             int v = ms.get(ELEMENT_LAYOUT, adr);
>             ms.set(ELEMENT_LAYOUT, adr, (int)(v + 1));
>         }
>     }
> 
> 
> **Solution: Runtime Checks - Predicate and Multiversioning**
> 
> Of course we could just forbid cases where we have a `native` base from vectorizing. But that would lead to regressions currently - in most cases we do get aligned `base`s, and we currently vectorize those. We cannot statically determine if the `base` is aligned, we need a runtime check.
> 
> I came up with 2 options where to place the runtime checks:
> - A new "auto vectorization" Parse Predicate:
>   - This only works when predicates are available.
>   - If we fail the predicate, then we recompile without the predicate. That means we cannot add a check to the predicate any more, and we would have to do multiversioning at that point if we still want to have a vectorized loop.
> - Multiversion the loop:
>   - Create 2 copies of the loop (fast and slow loops).
>   - The `fast_loop` can make speculative alignment assumptions, and add the corresponding check to the `multiversion_if` which decides which loop we take
>   - In the `slow_loop`, we make no assumption which means we can not vectorize, but we still compile - so even unaligned `base`s would end up with reasonably fast code.
>   - We "stall" the `...

src/hotspot/share/opto/loopnode.cpp line 5016:

> 5014:        tty->print_cr("PredicatesOff");
> 5015:      }
> 5016:      C->set_major_progress();

fix indentation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22016#discussion_r1850505281

From epeter at openjdk.org  Mon Jan 27 07:32:52 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 27 Jan 2025 07:32:52 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <NqzykMhBjgQ8xyFP8Adurw3lFdet7lLgV0Uvsad3yLA=.8d92b867-cc75-4605-898d-e46d14338cf7@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
 <NqzykMhBjgQ8xyFP8Adurw3lFdet7lLgV0Uvsad3yLA=.8d92b867-cc75-4605-898d-e46d14338cf7@github.com>
Message-ID: <BG4cWXI9RKYRFY17dMDAADgF-NdGTQrUy-g29imop10=.d75e9e91-1643-428d-b9d7-48a429c9630c@github.com>

On Fri, 24 Jan 2025 10:36:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestions incorporated.
>
>> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java
> 
> Hi @eme64 , Rebased to the latest mainline code please proceed with test runs.

@jatin-bhateja Thanks for the merge, testing is running!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2615015991

From epeter at openjdk.org  Mon Jan 27 07:45:54 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 27 Jan 2025 07:45:54 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v11]
In-Reply-To: <NqzykMhBjgQ8xyFP8Adurw3lFdet7lLgV0Uvsad3yLA=.8d92b867-cc75-4605-898d-e46d14338cf7@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VlmSiqYkH6d-6awXsnGSZwnM1KCqEMETb0OLw1X6Jf4=.fa785c7f-1029-4be6-9591-a1ab147445a6@github.com>
 <NqzykMhBjgQ8xyFP8Adurw3lFdet7lLgV0Uvsad3yLA=.8d92b867-cc75-4605-898d-e46d14338cf7@github.com>
Message-ID: <wWqCT2rCt4BD527nLqpiX2L_z6ayMeUHcKaLEAufyo8=.cc5e4b39-1042-4c0c-bb37-193fd685fb19@github.com>

On Fri, 24 Jan 2025 10:36:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestions incorporated.
>
>> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java
> 
> Hi @eme64 , Rebased to the latest mainline code please proceed with test runs.

@jatin-bhateja I'm getting a bad Copyright issue:


[2025-01-27T07:30:55,551Z] BAD COPYRIGHT LINE: .../test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java
[2025-01-27T07:30:55,552Z] 1 header format error(s).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2615032561

From epeter at openjdk.org  Mon Jan 27 07:45:57 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 27 Jan 2025 07:45:57 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v12]
In-Reply-To: <DGN7lI-1ytNB4X9iZS5RKFt6RUsXO1gknKmTJLNIOkY=.5f6da603-2a48-47ff-983e-f16b69909aa3@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <DGN7lI-1ytNB4X9iZS5RKFt6RUsXO1gknKmTJLNIOkY=.5f6da603-2a48-47ff-983e-f16b69909aa3@github.com>
Message-ID: <NXtc_za9iQwrTBgrRuJxlHbMo-OYFiQR5uX7A7QwB7I=.5af76d94-e906-4cad-a3fa-70a4ac312b1c@github.com>

On Fri, 24 Jan 2025 10:39:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Rebasing to jdk mainline
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103
>  - Refining IR match rule
>  - Review suggestions incorporated.
>  - Review comments resolutions
>  - Updating copyright year of modified files.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103
>  - Review suggestions incorporated.
>  - Review comments resolutions
>  - Addressing review comments
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/4a375e5b...e0602c1d

test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights vectorReserved.

Suggestion:

 * Copyright (c) 2025, Oracle and/or its affiliates. All rights Reserved.

Looks like a "vector" snuck in there ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1930090362

From sroy at openjdk.org  Mon Jan 27 08:04:34 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 27 Jan 2025 08:04:34 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v13]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <dcf29twWAZtV3UAOhftSmWYcDxxTMxrqp6f4TnSgnvw=.781b34b7-083a-46ad-9064-0467ffb3e9e8@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:

 - Merge branch 'openjdk:master' into ghash_processblocks
 - indentation
 - comments
 - vsx logic change
 - spaces
 - Merge branch 'master' into ghash_processblocks
 - spaces
 - update references
 - Comments and vsx check
 - restore
 - ... and 31 more: https://git.openjdk.org/jdk/compare/70eec900...0b62c633

-------------

Changes: https://git.openjdk.org/jdk/pull/20235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=12
  Stats: 165 lines in 2 files changed: 160 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From sroy at openjdk.org  Mon Jan 27 08:34:29 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 27 Jan 2025 08:34:29 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v14]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <gegUcaYa9wrAvFSTAtpVskhNIsjbY6IeiO6YFUXcJM4=.d3ac4b4e-5114-47e5-9d58-523d1280fa57@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'openjdk:master' into ghash_processblocks
 - Merge branch 'openjdk:master' into ghash_processblocks
 - indentation
 - comments
 - vsx logic change
 - spaces
 - Merge branch 'master' into ghash_processblocks
 - spaces
 - update references
 - Comments and vsx check
 - ... and 32 more: https://git.openjdk.org/jdk/compare/175e58b2...3caf1d8c

-------------

Changes: https://git.openjdk.org/jdk/pull/20235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=13
  Stats: 165 lines in 2 files changed: 160 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From jbhateja at openjdk.org  Mon Jan 27 08:35:44 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 27 Jan 2025 08:35:44 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v13]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <gbRIwc8Wau5tjAZLz2BRghtGcMjhhmHn_klmJ3nsTaI=.7da97dff-926a-498b-8640-c4b5cd997920@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Copyright header fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/e0602c1d..4f22ed85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Mon Jan 27 08:35:47 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 27 Jan 2025 08:35:47 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v12]
In-Reply-To: <NXtc_za9iQwrTBgrRuJxlHbMo-OYFiQR5uX7A7QwB7I=.5af76d94-e906-4cad-a3fa-70a4ac312b1c@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <DGN7lI-1ytNB4X9iZS5RKFt6RUsXO1gknKmTJLNIOkY=.5f6da603-2a48-47ff-983e-f16b69909aa3@github.com>
 <NXtc_za9iQwrTBgrRuJxlHbMo-OYFiQR5uX7A7QwB7I=.5af76d94-e906-4cad-a3fa-70a4ac312b1c@github.com>
Message-ID: <Jh3aFzbxdJ2nGCCSlNawSHB4ylwVe1rf-BFANLL1LII=.95dec829-6e7b-4a98-9845-74e90194b013@github.com>

On Mon, 27 Jan 2025 07:42:48 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Rebasing to jdk mainline
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103
>>  - Refining IR match rule
>>  - Review suggestions incorporated.
>>  - Review comments resolutions
>>  - Updating copyright year of modified files.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103
>>  - Review suggestions incorporated.
>>  - Review comments resolutions
>>  - Addressing review comments
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/4a375e5b...e0602c1d
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights vectorReserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2025, Oracle and/or its affiliates. All rights Reserved.
> 
> Looks like a "vector" snuck in there ?

DONE

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1930140699

From azafari at openjdk.org  Mon Jan 27 08:56:21 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 27 Jan 2025 08:56:21 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v17]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <c8ihnUOCZ61nc6EYZIqdrdx8gtxd_JB1tUnf5Te8LM8=.ab4a88f7-308a-4129-a7ba-21ed06096ee4@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  merge with master

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/5352894a..5429e79c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=15-16

  Stats: 13437 lines in 1976 files changed: 4728 ins; 5210 del; 3499 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 stuefe at openjdk.org  Mon Jan 27 09:35:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 27 Jan 2025 09:35:51 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v5]
In-Reply-To: <KSgJ-O3mIgwqlyaCaCku1Tun-znbMPELRtcNMET1Xw8=.28a36a6f-89a2-452a-b334-c94ce13b7ad4@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
 <h4SWSe9QZjelrN2veT18VjIPcjd60EDgf9cbSLe61H0=.31012b2e-054e-4f5d-a3aa-5d344f432319@github.com>
 <KSgJ-O3mIgwqlyaCaCku1Tun-znbMPELRtcNMET1Xw8=.28a36a6f-89a2-452a-b334-c94ce13b7ad4@github.com>
Message-ID: <X-dKhpcm-kGXhrQC3ft0cDyTlMjZ5P26DJ0r-d51jIA=.5c88b65e-0941-4440-b520-22b5facc8f35@github.com>

On Thu, 23 Jan 2025 06:50:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix whitespace error
>
> src/hotspot/share/cds/archiveBuilder.cpp line 370:
> 
>> 368:     // The region that will be located at the bottom of the encoding range at runtime shall have
>> 369:     // space for a protection zone.
>> 370:     MetaspaceShared::allocate_and_mark_protection_zone(rw_region());
> 
> This will add up 64KBs of space to the front of the RW region, increasing the file size. Could you try changing the `CDSFileMapRegion::_mapping_offset` of the RW region to `MetaspaceShared::core_region_alignment()` so we can avoid storing the data in the CDS file?

@iklam Ugh, this is more invasive than I thought. I worked my way through the belly of `MetaspaceShared::reserve_address_space_for_archives`, fixing up things for an explicit protection zone at the beginning. 

This gets complicated because of Windows and its inability to replace memory mappings. So I need to reserve space for the protection zone as an individual ReservedSpace, including fixing `release_reserved_spaces` etc. The final splitup for the Posix variant is also getting more complex.

Could we not just deprecate the "Windows mapping and use_archive_base_addr=true path" ? Does anyone still benefit since we, by default, look for a randomized base anyway?

I will probably have to delay this work until mid-February. Unless you would be okay with me to push it in its current form and do the improvement for jsa file size later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23190#discussion_r1930218753

From aph at openjdk.org  Mon Jan 27 15:08:30 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 27 Jan 2025 15:08:30 GMT
Subject: RFR: 8337251: C1: Improve Class.isInstance intrinsic [v3]
In-Reply-To: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>
References: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>
Message-ID: <DVU3t3ArlJ5I_1gKs1wb2St5TyoJQcWmrDvrrXLn3xs=.1a92f818-4ef9-4d3c-b083-37b4974d8ae8@github.com>

> This replaces a runtime call to `Runtime1::is_instance_of()` by a platform-dependent C1 intrinsic.
> 
> This improves overall performance significantly. and it minimizes icache footprint.
> 
> The original commit contains this comment:
> 
> 
>   // TODO could try to substitute this node with an equivalent InstanceOf
>   // if clazz is known to be a constant Class. This will pick up newly found
>   // constants after HIR construction. I'll leave this to a future change.
> 
> 
> 
> However, there's little performance to be gained by restricting this optimization to constant Class instances, and after this this patch, C1 `Class.isInstance()` compares favorably with the current platform-dependent `instanceof` intrinsic.
> 
> It's not strictly necessary for other platforms to implement this optimization.
> 
> Performance:
> 
> Xeon-E5 2430, before and after::
> 
> 
> Benchmark                               Score    Error       Score     Error  Units
> SecondarySupersLookup.testNegative00   11.783 ?  0.491      10.459 ?   0.183  ns/op
> SecondarySupersLookup.testNegative01   11.757 ?  0.127      10.475 ?   0.661  ns/op
> SecondarySupersLookup.testNegative02   11.771 ?  0.700      10.479 ?   0.357  ns/op
> SecondarySupersLookup.testNegative55   23.997 ?  1.816      16.854 ?   1.034  ns/op
> SecondarySupersLookup.testNegative60   29.598 ?  1.326      26.828 ?   0.637  ns/op
> SecondarySupersLookup.testNegative63   74.528 ?  3.157      69.431 ?   0.357  ns/op
> SecondarySupersLookup.testNegative64   75.936 ?  1.805      70.124 ?   0.397  ns/op
> 
> SecondarySupersLookup.testPositive01   15.257 ?  1.179       9.722 ?   0.326  ns/op
> SecondarySupersLookup.testPositive02   15.164 ?  1.383       9.737 ?   0.708  ns/op
> SecondarySupersLookup.testPositive03   15.166 ?  0.934       9.726 ?   0.184  ns/op
> SecondarySupersLookup.testPositive40   20.384 ?  0.530      12.805 ?   0.778  ns/op
> SecondarySupersLookup.testPositive50   15.118 ?  0.140       9.735 ?   0.555  ns/op
> SecondarySupersLookup.testPositive60   20.415 ?  3.083      11.603 ?   0.106  ns/op
> SecondarySupersLookup.testPositive63   65.478 ?  8.484      58.507 ?   2.837  ns/op
> SecondarySupersLookup.testPositive64   75.880 ?  1.047      68.667 ?   1.347  ns/op
> 
> 
> AArch64 (Apple M1)
> 
> 
> Benchmark                              Score   Error   Score   Error  Units
> SecondarySupersLookup.testNegative00   4.139 ? 0.005   2.815 ? 0.014  ns/op
> SecondarySupersLookup.testNegative01   4.071 ? 0.153   2.826 ? 0.291  ns/op
> SecondarySupersLookup.testNegative02   4.089 ? 0.752   2.817 ? 0.028  ns/...

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Next

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22491/files
  - new: https://git.openjdk.org/jdk/pull/22491/files/cf55fdd9..4458afc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22491&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22491&range=01-02

  Stats: 19 lines in 5 files changed: 13 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22491/head:pull/22491

PR: https://git.openjdk.org/jdk/pull/22491

From coleenp at openjdk.org  Mon Jan 27 15:33:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Jan 2025 15:33:47 GMT
Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure
 speed and memory [v11]
In-Reply-To: <bRnr3b9foKZHVSsxQWotbMmUPBQoiFetQOxHLX2FDgs=.5e3437f7-4f04-4c42-8170-7c571cc1c747@github.com>
References: <hJuUN-L58GjGxOtF5dvK9iSG0nwM63G_1yFnvYY58tw=.3ff4e360-f86d-414d-bfaf-121fa1d939dd@github.com>
 <bRnr3b9foKZHVSsxQWotbMmUPBQoiFetQOxHLX2FDgs=.5e3437f7-4f04-4c42-8170-7c571cc1c747@github.com>
Message-ID: <v75Kzk1uzkwBUzvwxmdxJN-51HSC1gTl3TAmkJIBtPY=.42e70e7c-cea1-4ec1-9d8c-c95f84b6f539@github.com>

On Thu, 23 Jan 2025 17:40:29 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism.
>> 
>> We create 2 static instances: one NMT_MemoryLogRecorder the other NMT_VirtualMemoryLogRecorder.
>> 
>> VM interacts with these through these APIs:
>> 
>>   ```
>>   NMT_LogRecorder::initialize(NMTRecordMemoryAllocations, NMTRecordVirtualMemoryAllocations);
>>   NMT_LogRecorder::replay(NMTBenchmarkRecordedDir, NMTBenchmarkRecordedPID);
>>   NMT_LogRecorder::logThreadName(name);
>>   NMT_LogRecorder::finish();
>> 
>> 
>> For controlling their liveness and through their "log" APIs for the actual logging.
>> 
>> For memory logger those are:
>> 
>> 
>>   NMT_MemoryLogRecorder::log_malloc(mem_tag, outer_size, outer_ptr, &stack);
>>   NMT_MemoryLogRecorder::log_realloc(mem_tag, new_outer_size, new_outer_ptr, header, &stack);
>>   NMT_MemoryLogRecorder::log_free(old_outer_ptr);
>> 
>> 
>> and for virtual memory logger, those are:
>> 
>> 
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve((address)addr, size, stack, mem_tag);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_release((address)addr, size);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_uncommit((address)addr, size);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_reserve_and_commit((address)addr, size, stack, mem_tag);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_commit((address)addr, size, stack);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_split_reserved((address)addr, size, split, mem_tag, split_tag);
>>       NMT_VirtualMemoryLogRecorder::log_virtual_memory_tag((address)addr, mem_tag);
>> 
>> 
>> That's the entirety of the surface area of the new code.
>> 
>> The actual implementation extends one existing VM API:
>> 
>> `bool Arguments::copy_expand_pid(const char* src, size_t srclen, char* buf, size_t buflen, int pid)
>> `
>> 
>> and adds a few APIs to permit_forbidden_function.hpp:
>> 
>> 
>>  inline char *strtok(char *str, const char *sep) { return ::strtok(str, sep); }
>>  inline long strtol(const char *str, char **endptr, int base) { return ::strtol(str, endptr, base); }
>> 
>>  #if defined(LINUX)
>>  inline size_t malloc_usable_size(void *_Nullable ptr) { return ::malloc_usable_size(ptr); }
>>  #elif defined(WINDOWS)
>>  inline size_t _msize(void *memblock) { return ::_msize(memblock); }
>>  #elif defined(__APPLE__)
>>  inline size_t malloc_size(const void *ptr) { return ::malloc_size(ptr); }
>>  #endif
>> 
>> 
>> Those are need if we want to calculate the memory overhead
>> 
>> To u...
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more detail in summary

This change fails jcheck and GHA because it doesn't build.  Can you fix these problems before people start reviewing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2616076480

From aph at openjdk.org  Mon Jan 27 16:13:35 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 27 Jan 2025 16:13:35 GMT
Subject: RFR: 8337251: C1: Improve Class.isInstance intrinsic [v4]
In-Reply-To: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>
References: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>
Message-ID: <yVjfvt9afbr2HQFF0suuD0GVsgAaIWwa5cXdTMWf2AM=.be673f45-60b3-4133-bccb-cc4d43590ffc@github.com>

> This replaces a runtime call to `Runtime1::is_instance_of()` by a platform-dependent C1 intrinsic.
> 
> This improves overall performance significantly. and it minimizes icache footprint.
> 
> The original commit contains this comment:
> 
> 
>   // TODO could try to substitute this node with an equivalent InstanceOf
>   // if clazz is known to be a constant Class. This will pick up newly found
>   // constants after HIR construction. I'll leave this to a future change.
> 
> 
> 
> However, there's little performance to be gained by restricting this optimization to constant Class instances, and after this this patch, C1 `Class.isInstance()` compares favorably with the current platform-dependent `instanceof` intrinsic.
> 
> It's not strictly necessary for other platforms to implement this optimization.
> 
> Performance:
> 
> Xeon-E5 2430, before and after::
> 
> 
> Benchmark                               Score    Error       Score     Error  Units
> SecondarySupersLookup.testNegative00   11.783 ?  0.491      10.459 ?   0.183  ns/op
> SecondarySupersLookup.testNegative01   11.757 ?  0.127      10.475 ?   0.661  ns/op
> SecondarySupersLookup.testNegative02   11.771 ?  0.700      10.479 ?   0.357  ns/op
> SecondarySupersLookup.testNegative55   23.997 ?  1.816      16.854 ?   1.034  ns/op
> SecondarySupersLookup.testNegative60   29.598 ?  1.326      26.828 ?   0.637  ns/op
> SecondarySupersLookup.testNegative63   74.528 ?  3.157      69.431 ?   0.357  ns/op
> SecondarySupersLookup.testNegative64   75.936 ?  1.805      70.124 ?   0.397  ns/op
> 
> SecondarySupersLookup.testPositive01   15.257 ?  1.179       9.722 ?   0.326  ns/op
> SecondarySupersLookup.testPositive02   15.164 ?  1.383       9.737 ?   0.708  ns/op
> SecondarySupersLookup.testPositive03   15.166 ?  0.934       9.726 ?   0.184  ns/op
> SecondarySupersLookup.testPositive40   20.384 ?  0.530      12.805 ?   0.778  ns/op
> SecondarySupersLookup.testPositive50   15.118 ?  0.140       9.735 ?   0.555  ns/op
> SecondarySupersLookup.testPositive60   20.415 ?  3.083      11.603 ?   0.106  ns/op
> SecondarySupersLookup.testPositive63   65.478 ?  8.484      58.507 ?   2.837  ns/op
> SecondarySupersLookup.testPositive64   75.880 ?  1.047      68.667 ?   1.347  ns/op
> 
> 
> AArch64 (Apple M1)
> 
> 
> Benchmark                              Score   Error   Score   Error  Units
> SecondarySupersLookup.testNegative00   4.139 ? 0.005   2.815 ? 0.014  ns/op
> SecondarySupersLookup.testNegative01   4.071 ? 0.153   2.826 ? 0.291  ns/op
> SecondarySupersLookup.testNegative02   4.089 ? 0.752   2.817 ? 0.028  ns/...

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Next
 - Next
 - Merge branch 'master' into JDK-8337251
 - More
 - Next
 - Windows fix, maybe.
 - Update
 - Update
 - Test fix/
 - Test fix/
 - ... and 18 more: https://git.openjdk.org/jdk/compare/764d70b7...13a2d93e

-------------

Changes: https://git.openjdk.org/jdk/pull/22491/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22491&range=03
  Stats: 148 lines in 13 files changed: 139 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22491/head:pull/22491

PR: https://git.openjdk.org/jdk/pull/22491

From aph at openjdk.org  Mon Jan 27 16:13:35 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 27 Jan 2025 16:13:35 GMT
Subject: RFR: 8337251: C1: Improve Class.isInstance intrinsic [v2]
In-Reply-To: <ADGO5WDOiH7-zetRRvXnypGz0ReBp8g21aYi0j4eug4=.96bcfb3f-0862-4d15-9a6c-5f96cb3d0adc@github.com>
References: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>
 <hsA7VXvmSPMtMVeZEgZ5Tra1kAleCo8EpgRHUSMS9us=.f3d6c081-b1ab-4b92-a743-c67cc03dd4c1@github.com>
 <ADGO5WDOiH7-zetRRvXnypGz0ReBp8g21aYi0j4eug4=.96bcfb3f-0862-4d15-9a6c-5f96cb3d0adc@github.com>
Message-ID: <Ty3gocc_W7NQCf3XiyIm2pwNk1UXHQssLdz6_ympg0M=.2df85ead-65b8-4068-8e6e-96405b697645@github.com>

On Sat, 7 Dec 2024 02:06:15 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - Windows fix, maybe.
>>  - Update
>>  - Update
>>  - Test fix/
>>  - Test fix/
>>  - Fix test failure
>>  - Reorganize C1 is_instance_of stub handling
>
> src/hotspot/share/c1/c1_LIRGenerator.cpp line 1247:
> 
>> 1245:   }
>> 1246: 
>> 1247: #ifdef HAVE_PD_C1_IS_INSTANCE_OF_STUB
> 
> Is it the first occurrence of optional stub on C1? Alternatively, you could provide a default implementation on all other platforms which simply calls into `Runtime1::is_instance_of`.
> 
> Also, the macro doesn't look pretty here. `c1_Defs_*.hpp` promote a different pattern (a constant). I understand that it requires changing all `c1_Defs_*.hpp` files, but it would definitely look cleaner here.

OK. How about this one, then?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22491#discussion_r1930780683

From eastigeevich at openjdk.org  Mon Jan 27 17:50:53 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 27 Jan 2025 17:50:53 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures
In-Reply-To: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
Message-ID: <wgeNZFcTgGMVebSsJNRy7Fs3sX5rsS5LHY5Eya7JlWI=.1c064174-33b2-4d79-a199-8081573519f8@github.com>

On Fri, 24 Jan 2025 11:29:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.
> 
> While doing this change I also added some extra info about the area that we tried to reserve and commit.
> 
> A couple of G1 tests had to be tweaked.

LGTM

-------------

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23297#pullrequestreview-2576158181

From eastigeevich at openjdk.org  Mon Jan 27 18:04:57 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 27 Jan 2025 18:04:57 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures
In-Reply-To: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
Message-ID: <N_T0Ritj3klpBRdXocdfV0TgTfY3aGV6-dDnH-nBhOQ=.c759a074-b77d-4655-b92a-e1228eb2129f@github.com>

On Fri, 24 Jan 2025 11:29:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.
> 
> While doing this change I also added some extra info about the area that we tried to reserve and commit.
> 
> A couple of G1 tests had to be tweaked.

Changes requested by eastigeevich (Committer).

src/hotspot/share/memory/memoryReserver.cpp line 65:

> 63: static void log_on_large_pages_failure(char* req_addr, size_t bytes) {
> 64:   if (large_pages_requested()) {
> 65:     // Compressed oops logging.

I think we don't need this comment any more.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23297#pullrequestreview-2576189054
PR Review Comment: https://git.openjdk.org/jdk/pull/23297#discussion_r1930976317

From eastigeevich at openjdk.org  Mon Jan 27 18:04:58 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 27 Jan 2025 18:04:58 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures
In-Reply-To: <wgeNZFcTgGMVebSsJNRy7Fs3sX5rsS5LHY5Eya7JlWI=.1c064174-33b2-4d79-a199-8081573519f8@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
 <wgeNZFcTgGMVebSsJNRy7Fs3sX5rsS5LHY5Eya7JlWI=.1c064174-33b2-4d79-a199-8081573519f8@github.com>
Message-ID: <bdbAN5nCRQuH6mHj0nZp140ACDx0ViEZrk3G73nb89M=.77227e52-ad0f-4493-8b78-c96a919abdb8@github.com>

On Mon, 27 Jan 2025 17:48:12 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.
>> 
>> While doing this change I also added some extra info about the area that we tried to reserve and commit.
>> 
>> A couple of G1 tests had to be tweaked.
>
> LGTM

> Note that I used JDK-8321529, which is a bug that @eastig created a over a year ago. Evgeny do you think this is a decent fix? Or do you need something else? Is it OK if I make this change under your bug or do you want me to create a separate bug for this change?

Hi @stefank,
Thanks for fixing the issue. 
I don't think we need another bug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23297#issuecomment-2616526535

From stefank at openjdk.org  Mon Jan 27 18:19:06 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 27 Jan 2025 18:19:06 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures [v2]
In-Reply-To: <N_T0Ritj3klpBRdXocdfV0TgTfY3aGV6-dDnH-nBhOQ=.c759a074-b77d-4655-b92a-e1228eb2129f@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
 <N_T0Ritj3klpBRdXocdfV0TgTfY3aGV6-dDnH-nBhOQ=.c759a074-b77d-4655-b92a-e1228eb2129f@github.com>
Message-ID: <wZnA0WYEmwjpSB8Ul_olzbFSECJtMDbi0JcOwTjym_g=.22f1fa6c-3134-4ced-9420-d60bf8256de2@github.com>

On Mon, 27 Jan 2025 18:02:12 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update memoryReserver.cpp
>
> src/hotspot/share/memory/memoryReserver.cpp line 65:
> 
>> 63: static void log_on_large_pages_failure(char* req_addr, size_t bytes) {
>> 64:   if (large_pages_requested()) {
>> 65:     // Compressed oops logging.
> 
> I think we don't need this comment any more.

+1 I removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23297#discussion_r1930991195

From stefank at openjdk.org  Mon Jan 27 18:19:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 27 Jan 2025 18:19:04 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures [v2]
In-Reply-To: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
Message-ID: <3rvoe3fw-Qv2tyGwomaDxy2hNzfoaZuj4wUdgQzi5hM=.f8522d94-df2b-44a0-8a7f-503e7b19ce71@github.com>

> The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.
> 
> While doing this change I also added some extra info about the area that we tried to reserve and commit.
> 
> A couple of G1 tests had to be tweaked.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Update memoryReserver.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23297/files
  - new: https://git.openjdk.org/jdk/pull/23297/files/b8846d3b..d1dbe16b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23297&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23297&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23297/head:pull/23297

PR: https://git.openjdk.org/jdk/pull/23297

From stefank at openjdk.org  Mon Jan 27 18:19:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 27 Jan 2025 18:19:04 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures [v2]
In-Reply-To: <bdbAN5nCRQuH6mHj0nZp140ACDx0ViEZrk3G73nb89M=.77227e52-ad0f-4493-8b78-c96a919abdb8@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
 <wgeNZFcTgGMVebSsJNRy7Fs3sX5rsS5LHY5Eya7JlWI=.1c064174-33b2-4d79-a199-8081573519f8@github.com>
 <bdbAN5nCRQuH6mHj0nZp140ACDx0ViEZrk3G73nb89M=.77227e52-ad0f-4493-8b78-c96a919abdb8@github.com>
Message-ID: <dssD4sXFmPcm0TOm_acjCqg_Gl4xgmQtPcTfdsoWqmw=.1e4fa1f1-2a3e-4db2-b39e-0ae7617f6aa5@github.com>

On Mon, 27 Jan 2025 18:01:08 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> > Note that I used JDK-8321529, which is a bug that @eastig created a over a year ago. Evgeny do you think this is a decent fix? Or do you need something else? Is it OK if I make this change under your bug or do you want me to create a separate bug for this change?
> 
> Hi @stefank, Thanks for fixing the issue. I don't think we need another bug.

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23297#issuecomment-2616559073

From duke at openjdk.org  Mon Jan 27 18:23:43 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 27 Jan 2025 18:23:43 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA
Message-ID: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>

By using the aarch64 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

-------------

Commit messages:
 - fixing whitespace errors
 - 8348561: Add aarch64 intrinsics for ML-DSA

Changes: https://git.openjdk.org/jdk/pull/23300/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348561
  Stats: 2040 lines in 18 files changed: 1987 ins; 4 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/23300.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23300/head:pull/23300

PR: https://git.openjdk.org/jdk/pull/23300

From eastigeevich at openjdk.org  Mon Jan 27 19:15:55 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 27 Jan 2025 19:15:55 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures [v2]
In-Reply-To: <3rvoe3fw-Qv2tyGwomaDxy2hNzfoaZuj4wUdgQzi5hM=.f8522d94-df2b-44a0-8a7f-503e7b19ce71@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
 <3rvoe3fw-Qv2tyGwomaDxy2hNzfoaZuj4wUdgQzi5hM=.f8522d94-df2b-44a0-8a7f-503e7b19ce71@github.com>
Message-ID: <NjodVqw6LHgGu2gJrYdIjm0dLonWemeqlbXhBI9uR38=.5248dea3-a3ce-4c29-97fd-7ae9b8dc1b9c@github.com>

On Mon, 27 Jan 2025 18:19:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.
>> 
>> While doing this change I also added some extra info about the area that we tried to reserve and commit.
>> 
>> A couple of G1 tests had to be tweaked.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update memoryReserver.cpp

lgtm

-------------

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23297#pullrequestreview-2576340500

From kdnilsen at openjdk.org  Mon Jan 27 19:28:47 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 27 Jan 2025 19:28:47 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <tI-a6z8mlKxmghtBp4SW71IC_DZbd9P6QvhEzUNZTuY=.80947a0d-95e9-4463-8e27-3dc21d87a370@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <a5LWW1-dWl6Z4r_MRQf4xgwSHrvFVK5V766LrK3BcP0=.bf0bdf81-e774-4244-9600-4a00244c6c3e@github.com>
 <tI-a6z8mlKxmghtBp4SW71IC_DZbd9P6QvhEzUNZTuY=.80947a0d-95e9-4463-8e27-3dc21d87a370@github.com>
Message-ID: <0CQeRpNMFlkcHzWqgjuu5-39K6Abq0q_yQQbvsZiZng=.710d6f80-99f8-419c-ae41-cfa3c6b2047c@github.com>

On Tue, 21 Jan 2025 23:25:27 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 228:
>> 
>>> 226: // This avoids the need to synchronize reads of the table by the GC workers doing
>>> 227: // remset scanning, on the one hand, with the dirtying of the table by mutators
>>> 228: // and by the GC workers doing remset scans, on the other.
>> 
>> Remove "and by the the GC workers doing remset scans" from this comment, so it reads:
>> "This avoids the need to synchronize reads of the table by the GC workers doing
>> remset scanning, on the one hand, with the dirtying of the table by mutators on the other.
>
> @kdnilsen , when are the existing intergenerational pointers (represented by (a subset of) the dirty cards in the read table) transferred to the write table?

That happens during remembered set scanning.  If the remembered set scan (from the read table) finds that certain cards still hold interesting pointers, the card will be dirtied in the write table.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23170#discussion_r1931077697

From cjplummer at openjdk.org  Mon Jan 27 19:48:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Jan 2025 19:48:55 GMT
Subject: Integrated: 8348239: SA does not know about
 DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <DpsIX5P-GtJ7O2U_0H4tUk4u1gnJ4ZJL669QSRs3aAc=.d55c8190-25f3-445c-a549-29f6b0c3b258@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

This pull request has now been integrated.

Changeset: 21feef32
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21feef32803b2593b097fb225c7a4c7cd46525da
Stats:     87 lines in 6 files changed: 62 ins; 15 del; 10 mod

8348239: SA does not know about DeoptimizeObjectsALotThread

Reviewed-by: kevinw, dlong, dholmes, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/23279

From cjplummer at openjdk.org  Mon Jan 27 19:48:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Jan 2025 19:48:54 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>
Message-ID: <PnyY94znCsoSop44ZacpGiqqe7B4N8i4Rbc7wIg3pec=.85282e43-7854-4e7f-91fa-f735157ddccb@github.com>

On Fri, 24 Jan 2025 20:22:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
>> 
>> 
>>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> 
>> 
>> The following can be used to reproduce this failure. Most SA tests will fail:
>> 
>>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
>> 
>> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
>> 
>> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup comment

Thanks for the reviews David, Leonid, Dean, and Kevin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2616740973

From sviswanathan at openjdk.org  Mon Jan 27 23:29:50 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 27 Jan 2025 23:29:50 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v13]
In-Reply-To: <gbRIwc8Wau5tjAZLz2BRghtGcMjhhmHn_klmJ3nsTaI=.7da97dff-926a-498b-8640-c4b5cd997920@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <gbRIwc8Wau5tjAZLz2BRghtGcMjhhmHn_klmJ3nsTaI=.7da97dff-926a-498b-8640-c4b5cd997920@github.com>
Message-ID: <wVGy8YpAfHJYQFNMAHmUmBQnDAP9egGGJkJA7uLhmB0=.35479242-3a84-425b-ab6d-99a4a97084f9@github.com>

On Mon, 27 Jan 2025 08:35:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright header fix

test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Year should be 2024, 2025,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1931316524

From iklam at openjdk.org  Tue Jan 28 00:00:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jan 2025 00:00:47 GMT
Subject: RFR: 8330174: Protection zone for easier detection of accidental
 zero-nKlass use [v5]
In-Reply-To: <X-dKhpcm-kGXhrQC3ft0cDyTlMjZ5P26DJ0r-d51jIA=.5c88b65e-0941-4440-b520-22b5facc8f35@github.com>
References: <Kgs11PMb9VTY9RDyCsaNEcs9DzF7Tzhe5yVRYxpqMlA=.e607cf5b-5220-4902-bc7c-1c6620e25334@github.com>
 <h4SWSe9QZjelrN2veT18VjIPcjd60EDgf9cbSLe61H0=.31012b2e-054e-4f5d-a3aa-5d344f432319@github.com>
 <KSgJ-O3mIgwqlyaCaCku1Tun-znbMPELRtcNMET1Xw8=.28a36a6f-89a2-452a-b334-c94ce13b7ad4@github.com>
 <X-dKhpcm-kGXhrQC3ft0cDyTlMjZ5P26DJ0r-d51jIA=.5c88b65e-0941-4440-b520-22b5facc8f35@github.com>
Message-ID: <Mdt2z6WXJ3kOVEOyLxcXLhN_f3wtPYWa67x1cm5-pc0=.0fcbe3c5-6d97-4444-99b2-293ea976b444@github.com>

On Mon, 27 Jan 2025 09:32:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/cds/archiveBuilder.cpp line 370:
>> 
>>> 368:     // The region that will be located at the bottom of the encoding range at runtime shall have
>>> 369:     // space for a protection zone.
>>> 370:     MetaspaceShared::allocate_and_mark_protection_zone(rw_region());
>> 
>> This will add up 64KBs of space to the front of the RW region, increasing the file size. Could you try changing the `CDSFileMapRegion::_mapping_offset` of the RW region to `MetaspaceShared::core_region_alignment()` so we can avoid storing the data in the CDS file?
>
> @iklam Ugh, this is more invasive than I thought. I worked my way through the belly of `MetaspaceShared::reserve_address_space_for_archives`, fixing up things for an explicit protection zone at the beginning. 
> 
> This gets complicated because of Windows and its inability to replace memory mappings. So I need to reserve space for the protection zone as an individual ReservedSpace, including fixing `release_reserved_spaces` etc. The final splitup for the Posix variant is also getting more complex.
> 
> Could we not just deprecate the "Windows mapping and use_archive_base_addr=true path" ? Does anyone still benefit since we, by default, look for a randomized base anyway?
> 
> I will probably have to delay this work until mid-February. Unless you would be okay with me to push it in its current form and do the improvement for jsa file size later.

Since this is a diagnostic feature, I think there's no rush and it's better to do it the right way.

> This gets complicated because of Windows and its inability to replace memory mappings.

`os::protect_memory()` calls `VirtualProtect()` which can change the permission to `PAGE_NOACCESS`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23190#discussion_r1931341559

From sviswanathan at openjdk.org  Tue Jan 28 01:34:52 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 28 Jan 2025 01:34:52 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v13]
In-Reply-To: <gbRIwc8Wau5tjAZLz2BRghtGcMjhhmHn_klmJ3nsTaI=.7da97dff-926a-498b-8640-c4b5cd997920@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <gbRIwc8Wau5tjAZLz2BRghtGcMjhhmHn_klmJ3nsTaI=.7da97dff-926a-498b-8640-c4b5cd997920@github.com>
Message-ID: <KaWLkv5uFaD0aTBh1JgW_L3HWrfIrPijacsRdgK9yrI=.493b94cd-3bf9-44cc-8c46-89ca0d91dec8@github.com>

On Mon, 27 Jan 2025 08:35:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright header fix

Some more minor comments.

src/hotspot/share/opto/addnode.cpp line 1546:

> 1544: 
> 1545:   // As per IEEE 754 specification, floating point comparison consider +ve and -ve
> 1546:   // zeros as equals. Thus, performing signed integral comparison for max value

Should be "min value detection".

src/hotspot/share/opto/addnode.cpp line 1624:

> 1622:   // As per IEEE 754 specification, floating point comparison consider +ve and -ve
> 1623:   // zeros as equals. Thus, performing signed integral comparison for min value
> 1624:   // detection.

Should be "max value detection".

src/hotspot/share/opto/divnode.cpp line 848:

> 846:   // If the dividend is a constant zero
> 847:   // Note: if t1 and t2 are zero then result is NaN (JVMS page 213)
> 848:   // Test TypeF::ZERO is not sufficient as it could be negative zero

Comment should be TypeH:ZERO is not sufficient

-------------

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2576801437
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1931347845
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1931347430
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1931376932

From vlivanov at openjdk.org  Tue Jan 28 04:06:45 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 28 Jan 2025 04:06:45 GMT
Subject: RFR: 8347564: ZGC: Crash in
 DependencyContext::clean_unloading_dependents
In-Reply-To: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
References: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
Message-ID: <UusKcGKgV8pMJWOnZ62ZxwPrFqGAHdlGo47caIw_Z6k=.5c4395e8-2e4c-4cbc-9077-7585c1eaf800@github.com>

On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The proposed change here is the following:
>  1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object
>  2. Remove the Context object and its corresponding cleaner
> 
> (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose.
> 
> First what goes wrong without this patch.
> 
> Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. 
> 
> For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. 
> 
> The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection.
> 
> If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection  would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. 
> 
> For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ...

Good work, Axel. `Cleaner`-based solution to manage nmethod dependencies on `java.lang.invoke.CallSite`s does look redundant. If that's the case, then I'd expect that by the time cleanup action is invoked corresponding dependency list is empty. Is it the case in practice? 

But the original problem makes me wonder whether `Cleaner`-based approach to manage native resources is broken or not.
Dependent instance is used to avoid referent to be artificially kept alive by cleanup action. If it is not safe to access it in order to perform cleanup, how the whole approach is intended to work? Or does anything make 'CallSite` use case special?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23194#issuecomment-2617796038

From galder at openjdk.org  Tue Jan 28 06:10:49 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 28 Jan 2025 06:10:49 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <AAn1vaqU5jjKtskChE7Mvnq8Kmg8IhZ54HdPYMYs2Dc=.33d24865-8120-4e29-8760-a263c437c830@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
 <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>
 <kJr2bLvqKfxkSt5S-JVhGXW4urFdiGjw7IVo4738TEw=.adedbb2d-b06e-4b3a-9424-eaf14d15d50a@github.com>
 <KXD2Ugdm5yHXAKrzlIegsfk1XsToPLvONBT47xQ724Y=.64b04176-940d-4327-85ef-d84b7f470cec@github.com>
 <W4yiaa18WIX7OBpvZdNn6p0WUr_Ro9nMDbI4n93CxQY=.c5e1effd-58c5-4768-b778-76f9de1c70ff@github.com>
 <w6HsRaKvY1VAALkXyMUM5UjJelIDFZXv51R
 br8cv-Fg=.fbb0189d-4bba-47c1-b737-34488f829a33@github.com>
 <4NGZx_gqvc7xMcXCTef2c_ns-nMxznsB42NnlQJqX4Q=.8cdc00f9-c9a7-409a-b5c3-885d0677b952@github.com>
 <AAn1vaqU5jjKtskChE7Mvnq8Kmg8IhZ54HdPYMYs2Dc=.33d24865-8120-4e29-8760-a263c437c830@github.com>
Message-ID: <2Eoj5haSgq0ueNj4nGE-7nqR-4t0xhnmmAUAsFuNjck=.1e748c98-8c34-42c9-ae80-d460e41e3ba3@github.com>

On Mon, 20 Jan 2025 08:00:52 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 I've addressed all the comments. I've not run the `VectorReduction2` for the reasons explained in the previous comment. Happy to add more details to `MinMaxVector` if you feel it's necessary.
>
> @galderz Ah, right. I understand about the branch probability.
> 
> Hmm, maybe we should eventually change the `VectorReduction2` benchmark, or just remove the `min/max` benchmark there completely, as it depends on the random input values.
> 
> Ah, though we have a fixed `seed`, so rerunning the benchmark would at least have consistent branching characteristics. So then it could make sense to run the benchmark, we just don't know the probability. I mean I ran it before for the `in/float/double min/max`, and all of them see a solid speedup. So I would expect the same for `long`, it would be nice to at least see the numbers.
> 
> You could extend your benchmark to `float / double` as well, to make it complete. But that could also be a follow-up RFE.
> 
>>I would expect a similar thing to happen when it comes to asimd envs with max vector size >= 32 (e.g. Graviton 3). Those will see vectorization occur and improvements kick in at 100%. Other systems (e.g. Graviton 4) will see a regression at 100%. This means that your work in https://github.com/openjdk/jdk/pull/20098#discussion_r1901576209 to avoid the max vector size limitation might become more important once my PR here goes in.
> 
> So are you saying there are machines where we are now getting some regressions with your patch (2-element cases)? It would be nice to see the numbers summarized here. I'm losing the overview a little over the 50+ messages now ?

@eme64 Fair points. I'll provide a detailed summary with some final numbers after FOSDEM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2617968437

From jbhateja at openjdk.org  Tue Jan 28 06:26:11 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 28 Jan 2025 06:26:11 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v14]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <NAy6q0P-B2RugBQiH57jMl0rjmgfmQj_eCarVrpfgiE=.ec5748f5-b455-401c-a4c8-c0198498c6a5@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Updating typos in comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/4f22ed85..854fc73f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=12-13

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From aboldtch at openjdk.org  Tue Jan 28 07:26:48 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 28 Jan 2025 07:26:48 GMT
Subject: RFR: 8347564: ZGC: Crash in
 DependencyContext::clean_unloading_dependents
In-Reply-To: <UusKcGKgV8pMJWOnZ62ZxwPrFqGAHdlGo47caIw_Z6k=.5c4395e8-2e4c-4cbc-9077-7585c1eaf800@github.com>
References: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
 <UusKcGKgV8pMJWOnZ62ZxwPrFqGAHdlGo47caIw_Z6k=.5c4395e8-2e4c-4cbc-9077-7585c1eaf800@github.com>
Message-ID: <GUa7p7dOh17YjxlUk-YWmOhb-rsXFwTkEYdq2MqOmaE=.48017b77-ab5c-461b-8087-83636679f3c9@github.com>

On Tue, 28 Jan 2025 04:04:39 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Good work, Axel. `Cleaner`-based solution to manage nmethod dependencies on `java.lang.invoke.CallSite`s does look redundant. If that's the case, then I'd expect that by the time cleanup action is invoked corresponding dependency list is empty. Is it the case in practice?

For our STW collectors this should always be the case, as the cleaner will run its code after the collection where the CallSite dies, which will in turn have unlinked the nmethods.

For the concurrent collectors, because references processing is done before nmethod unlinking, we might run the cleaner code before the GC gets to the nmethod, and as such observe a none empty list. 

I've run some sanity stress tests locally with G1 and the following patch:

diff --git a/src/hotspot/share/prims/methodHandles.cpp b/src/hotspot/share/prims/methodHandles.cpp
index 97e3eae1a2f..fadcec9bd90 100644
--- a/src/hotspot/share/prims/methodHandles.cpp
+++ b/src/hotspot/share/prims/methodHandles.cpp
@@ -1330,6 +1331,7 @@ JVM_ENTRY(void, MHN_clearCallSiteContext(JNIEnv* env, jobject igcls, jobject con
     NoSafepointVerifier nsv;
     MutexLocker ml(THREAD, CodeCache_lock, Mutex::_no_safepoint_check_flag);
     DependencyContext deps = java_lang_invoke_MethodHandleNatives_CallSiteContext::vmdependencies(context());
+    guarantee(deps.is_empty(), "just checking");
     deps.remove_and_mark_for_deoptimization_all_dependents(&deopt_scope);
     // This is assumed to be an 'atomic' operation by verification.
     // So keep it under lock for now.

But I'll take it a spin through our CI as well. But if this were to occur it would mean we must have either missed adding a dependent CallSite oop to a linked nmethod, or that GC failed to unlink a nmethod with a dead oop. Neither would be very healthy. 

> But the original problem makes me wonder whether `Cleaner`-based approach to manage native resources is broken or not.

_Tangent:
`Cleaner`-based native resource management may be broken but not because of this. (It suffers from a similar problem to finalisers, namely that they are triggered at the GCs discretion, and the GC have no real insight into the cost of a "native resource" so it may never be cleaned. Trying to create scoped lifetimes, with try-with-resource should always be preferred)_

> Dependent instance is used to avoid referent to be artificially kept alive by cleanup action. If it is not safe to access it in order to perform cleanup, how the whole approach is intended to work? Or does anything make 'CallSite` use case special?

`CallSite` is special, because the GC knows about it. The reason being is that the GC must remove all nmethod dependencies when unlinking, otherwise we would have a dangling pointer and an ABA problem. When unlinking the GC runs the following code.

    for (Dependencies::DepStream deps(this); deps.next(); ) {
      if (deps.type() == Dependencies::call_site_target_value) {
        // CallSite dependencies are managed on per-CallSite instance basis.
        oop call_site = deps.argument_oop(0);
        MethodHandles::clean_dependency_context(call_site);
      }

The `call_site` in question here may or may not be dead. But regardless it will have a link to the currently unlinking nmethod, which must be removed. After unlinking the GC will phase the system (by a handshake or by the property of doing all this work in a safepoint). If it was not removed it is a dangling pointer, not only that it is a pointer we are more than likely going to reuse for a new nmethod, which will make them indistinguishable, leading to ABA.

 There is a world where we move this to java. Having some object representing the nmethod. Letting CallSites have a linked list of weak references to these objects, etc. Having thee GC solve the memory reclamation problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23194#issuecomment-2618104075

From ssarathi at openjdk.org  Tue Jan 28 08:37:35 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Tue, 28 Jan 2025 08:37:35 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters
Message-ID: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>

PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.

JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

-------------

Commit messages:
 - Renaming the Condition Registers

Changes: https://git.openjdk.org/jdk/pull/23325/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23325&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344983
  Stats: 1386 lines in 32 files changed: 0 ins; 0 del; 1386 mod
  Patch: https://git.openjdk.org/jdk/pull/23325.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23325/head:pull/23325

PR: https://git.openjdk.org/jdk/pull/23325

From amitkumar at openjdk.org  Tue Jan 28 09:09:56 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 28 Jan 2025 09:09:56 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters
In-Reply-To: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
Message-ID: <Mh-k74Jeq1wh38ZZ1GN3VZkjX4pUDm1kXbZ-we1WJV8=.e352ca27-b44d-4968-bb96-42b97b35caeb@github.com>

On Tue, 28 Jan 2025 08:31:59 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
> 
> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

Please update copyright header years as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23325#issuecomment-2618365794

From aph at openjdk.org  Tue Jan 28 09:21:50 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 28 Jan 2025 09:21:50 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters
In-Reply-To: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
Message-ID: <EkXatJZJLBKMKedIQG_BtgWU8j4za31nDoO6oRHkLl8=.48769d0a-2730-46b3-b1fd-68c72c1ebc82@github.com>

On Tue, 28 Jan 2025 08:31:59 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
> 
> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

I understand the motivation, but maybe the reason this was never done before is that it will make back-porting fixes harder. They will never apply cleanly to old versions, and will all have to be adjusted manually.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23325#issuecomment-2618394421

From cnorrbin at openjdk.org  Tue Jan 28 11:04:08 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 28 Jan 2025 11:04:08 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v17]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <vqcXhVxlyVaYAIFzp1FyLfUnB63SZz9YVTl3-o4DbPc=.88bf2e76-21d1-4535-916f-71f34386688a@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - merge fixes
 - Merge branch 'master' into rb-tree
 - readd find_enclosing_range
 - Merge branch 'master' into rb-tree
 - treap swap fix
 - const functions
 - thomas feedback
 - axel feedback
 - clarified comment
 - Improved comments
 - ... and 26 more: https://git.openjdk.org/jdk/compare/ad01dfb6...b7219a93

-------------

Changes: https://git.openjdk.org/jdk/pull/22360/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=16
  Stats: 1435 lines in 3 files changed: 1435 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From ssarathi at openjdk.org  Tue Jan 28 11:58:00 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Tue, 28 Jan 2025 11:58:00 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters [v2]
In-Reply-To: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
Message-ID: <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>

> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
> 
> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

Sorna Sarathi N has updated the pull request incrementally with one additional commit since the last revision:

  Updated the copyright header years for the edited files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23325/files
  - new: https://git.openjdk.org/jdk/pull/23325/files/74ca1f53..a0b07116

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23325&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23325&range=00-01

  Stats: 38 lines in 30 files changed: 0 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/23325.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23325/head:pull/23325

PR: https://git.openjdk.org/jdk/pull/23325

From cnorrbin at openjdk.org  Tue Jan 28 13:30:56 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 28 Jan 2025 13:30:56 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <sXLE-TKOLYwhqZ1vTdBoWHDdieshwwBp6IpcwAY7G7M=.cc915bcf-de6e-498b-b71b-78441a6b2da3@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
 <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
 <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
 <OsQblEIQ2Jhpk6r_vZM7QtLBr6ZKT8Gc1Wzf-9-Iw7E=.fce8422e-9473-4f3c-8e77-a4038f4f8684@github.com>
 <sXLE-TKOLYwhqZ1vTdBoWHDdieshwwBp6IpcwAY7G7M=.cc915bcf-de6e-498b-b71b-78441a6b2da3@github.com>
Message-ID: <-7yWYsG29O1hILQuIcNwRhTaYUOEFdaKFxAvUxKYz1E=.4ccf819f-bcfb-44e9-97d2-63ac8e2ac1cd@github.com>

On Thu, 16 Jan 2025 12:28:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Hi @jdksjolen, @caspernorrbin
>>> 
>>> sorry for the delay, work is piled up.
>>> 
>>> > It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
>>> 
>>> intrusive - I did not know this term, even though I wrote containers like this all my life, go figure :-).
>>> 
>>> Yes, that's precisely what I want.
>>> 
>>>     * I want to create/store nodes myself
>>> 
>>>     * I want to avoid copying node content; in fact, I don't want to even bother with assignment operators.
>>> 
>>>     * I want to be able to add child nodes to a node to handle duplicates if my tree allows duplicates (which is of no concern to the tree, but since these child nodes should live in the same pool, again, my wish for wanting to create nodes myself)
>>> 
>>> 
>>> All of this points to a tree where I manage the node myself. So, have a function to find a reference to an existing node by key and have a function to hand in a node for storage. Pretty much like you line it out in your example:
>>> 
>>> ```
>>> MyTree::add_my_bulky_and_possible_varsized_node(Node* n) {
>>> 	- find node n2 with key n->key
>>> 		- found? Add n as child node under n2
>>> 		- not found? add n as new node
>>> }
>>> ```
>>> 
>>> I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.
>> 
>> This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.
>> 
>> ```c++
>> struct Foo {
>>   RBNode rb; // with some K as key
>>   Foo* next;
>>   struct { /* ... */ } data;
>> };
>> 
>> void a_m_b_a_p_v_n(Foo* n) {
>>   Cursor c = tree.find_insertion_point(n);
>>   if (c.exists()) {
>>     Foo* f = Foo::cast_to_self(c.node());
>>     n->next = f->next;
>>     f->next = n->next;
>>   }
>>   tree.insert(c, n);
>> };
>> 
>> 
>> Just do that. Let's us entirely skip the headache of the rest of it, at the cost of 8 bytes.
>>  
>>> > I do want an allocator instance in the tree, beca...
>
>> > Hi @jdksjolen, 
> 
>> > 
>> > I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.
>> 
>> This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.
>> 
> 
> You misunderstood me - a linked list is exactly what I meant. That is why I talked about a "child node". I did this in metaspace: https://github.com/openjdk/jdk/blob/f64f22b360f68df68ebb875bd0ef08ba61702952/src/hotspot/share/memory/metaspace/blockTree.hpp#L89-L96
> 
> I can do that myself, as I wrote, this does not concern the tree. So for the tree we can keep things without duplicates. But for simplicity the easiest solution is for child nodes to be of the Node class itself, because then you can just swap them around and make them the leader node for this key value later. That would require a child Node to be allocated in the same pool as the "real" tree nodes, and have the same type as well. All of that can happen outside the tree. It is, however, an argument for giving the caller the ability to allocate and manage nodes himself and passing them in pre-formed for insertion.
> 
>> > > I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes.
>> > 
>> > 
>> > You lost me here
>> 
>> A static allocator either needs access to local state via a pointer on allocation, or it needs to have some form of protection against concurrent writes. This code below requires a mutex in `alloc`, because it is static.
>> 
>> 
> 
> Oh, sure. But again, not a strong argument for non-intrusiveness. In my original comment, I argued for having the ability to pass in an allocator instance into the destructor, or alternatively use a token of some sort when calling functions in a AllStatic allocator that identifies the tree.
> 
> But as I wrote, I think we don't have to choose. We can have an allocator instance as optional ctor argument, and let the tree ...

@tstuefe Did you have any more feedback on this? Would like to get this pushed soon so I can publish the intrusive variant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2618998031

From stuefe at openjdk.org  Tue Jan 28 14:15:04 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 28 Jan 2025 14:15:04 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v17]
In-Reply-To: <vqcXhVxlyVaYAIFzp1FyLfUnB63SZz9YVTl3-o4DbPc=.88bf2e76-21d1-4535-916f-71f34386688a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <vqcXhVxlyVaYAIFzp1FyLfUnB63SZz9YVTl3-o4DbPc=.88bf2e76-21d1-4535-916f-71f34386688a@github.com>
Message-ID: <nfgP4ibCGYtISbaTJQGiTRkLreAfBhF4fA6Wm2shAnc=.66fd9ef0-b2d5-4963-8e03-fd0dde324e73@github.com>

On Tue, 28 Jan 2025 11:04:08 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - merge fixes
>  - Merge branch 'master' into rb-tree
>  - readd find_enclosing_range
>  - Merge branch 'master' into rb-tree
>  - treap swap fix
>  - const functions
>  - thomas feedback
>  - axel feedback
>  - clarified comment
>  - Improved comments
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/ad01dfb6...b7219a93

Approved, good work

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2563627920

From stuefe at openjdk.org  Tue Jan 28 14:15:05 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 28 Jan 2025 14:15:05 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <sXLE-TKOLYwhqZ1vTdBoWHDdieshwwBp6IpcwAY7G7M=.cc915bcf-de6e-498b-b71b-78441a6b2da3@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
 <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
 <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
 <OsQblEIQ2Jhpk6r_vZM7QtLBr6ZKT8Gc1Wzf-9-Iw7E=.fce8422e-9473-4f3c-8e77-a4038f4f8684@github.com>
 <sXLE-TKOLYwhqZ1vTdBoWHDdieshwwBp6IpcwAY7G7M=.cc915bcf-de6e-498b-b71b-78441a6b2da3@github.com>
Message-ID: <-KpE74U1G2bdt5nXhgk2VJGp_tdxKlVIwU3SCCZn438=.e07fdfa5-aff0-4dd9-ae06-c9b931d4d20b@github.com>

On Thu, 16 Jan 2025 12:28:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Hi @jdksjolen, @caspernorrbin
>>> 
>>> sorry for the delay, work is piled up.
>>> 
>>> > It seems like you want an intrusive RBTree. That's really no problem, it just means that we have to extend the API slightly and make it so that you can avoid using an allocator.
>>> 
>>> intrusive - I did not know this term, even though I wrote containers like this all my life, go figure :-).
>>> 
>>> Yes, that's precisely what I want.
>>> 
>>>     * I want to create/store nodes myself
>>> 
>>>     * I want to avoid copying node content; in fact, I don't want to even bother with assignment operators.
>>> 
>>>     * I want to be able to add child nodes to a node to handle duplicates if my tree allows duplicates (which is of no concern to the tree, but since these child nodes should live in the same pool, again, my wish for wanting to create nodes myself)
>>> 
>>> 
>>> All of this points to a tree where I manage the node myself. So, have a function to find a reference to an existing node by key and have a function to hand in a node for storage. Pretty much like you line it out in your example:
>>> 
>>> ```
>>> MyTree::add_my_bulky_and_possible_varsized_node(Node* n) {
>>> 	- find node n2 with key n->key
>>> 		- found? Add n as child node under n2
>>> 		- not found? add n as new node
>>> }
>>> ```
>>> 
>>> I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.
>> 
>> This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.
>> 
>> ```c++
>> struct Foo {
>>   RBNode rb; // with some K as key
>>   Foo* next;
>>   struct { /* ... */ } data;
>> };
>> 
>> void a_m_b_a_p_v_n(Foo* n) {
>>   Cursor c = tree.find_insertion_point(n);
>>   if (c.exists()) {
>>     Foo* f = Foo::cast_to_self(c.node());
>>     n->next = f->next;
>>     f->next = n->next;
>>   }
>>   tree.insert(c, n);
>> };
>> 
>> 
>> Just do that. Let's us entirely skip the headache of the rest of it, at the cost of 8 bytes.
>>  
>>> > I do want an allocator instance in the tree, beca...
>
>> > Hi @jdksjolen, 
> 
>> > 
>> > I have two immediate examples where I want to use this RB tree: the reworked c2 memory statistic (in fact, I withhold the patch to wait for this RB tree to drop) and - somewhat later - the metaspace binary tree dictionary replacement. Both cases would be perfectly served with an intrusive key that allows me to handle duplicates.
>> 
>> This requires the tree to have nodes `<` strictly on the left, and `>=` strictly on the right (as opposed to `>` strictly on the right), or the opposite. I have no clue what having duplicates does to a RBTree when rebalancing. If it's that important to have duplicates, then why have them live inside the tree anyway? Just link them together with an intrusive linked list.
>> 
> 
> You misunderstood me - a linked list is exactly what I meant. That is why I talked about a "child node". I did this in metaspace: https://github.com/openjdk/jdk/blob/f64f22b360f68df68ebb875bd0ef08ba61702952/src/hotspot/share/memory/metaspace/blockTree.hpp#L89-L96
> 
> I can do that myself, as I wrote, this does not concern the tree. So for the tree we can keep things without duplicates. But for simplicity the easiest solution is for child nodes to be of the Node class itself, because then you can just swap them around and make them the leader node for this key value later. That would require a child Node to be allocated in the same pool as the "real" tree nodes, and have the same type as well. All of that can happen outside the tree. It is, however, an argument for giving the caller the ability to allocate and manage nodes himself and passing them in pre-formed for insertion.
> 
>> > > I do want an allocator instance in the tree, because then you can make very nice things such as a `IndexWithFreeList` allocator that doesn't need protection from concurrent writes.
>> > 
>> > 
>> > You lost me here
>> 
>> A static allocator either needs access to local state via a pointer on allocation, or it needs to have some form of protection against concurrent writes. This code below requires a mutex in `alloc`, because it is static.
>> 
>> 
> 
> Oh, sure. But again, not a strong argument for non-intrusiveness. In my original comment, I argued for having the ability to pass in an allocator instance into the destructor, or alternatively use a token of some sort when calling functions in a AllStatic allocator that identifies the tree.
> 
> But as I wrote, I think we don't have to choose. We can have an allocator instance as optional ctor argument, and let the tree ...

> @tstuefe Did you have any more feedback on this? Would like to get this pushed soon so I can publish the intrusive variant.

Sorry, I have not forgotten you, but am booked out with FOSDEM preparations. I can continue the review when I come back (end of next week), or the week after.

I would have liked to prod at the meat of the insertion/deletion logic more, since I remember that part being particularly fiddly. We should get this right, this needs close review.

But I don't want to hold you up, so if you feel you need to push now, go ahead. I would definitely like to look at the intrusive variant, since I expect I will use that one quite a bit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2619117723

From stuefe at openjdk.org  Tue Jan 28 14:15:06 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 28 Jan 2025 14:15:06 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v13]
In-Reply-To: <7UzEIAt_1LRqLecETD910uvyl4KaOFYBexUk9_9DLgc=.ae1be7f2-1d79-4400-9acf-cd7c58ad9f94@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <7UzEIAt_1LRqLecETD910uvyl4KaOFYBexUk9_9DLgc=.ae1be7f2-1d79-4400-9acf-cd7c58ad9f94@github.com>
Message-ID: <DDbW1NRvS-953OEugV-uQDE0c0HtKt1ukyaGc0fKfNg=.3a5425b5-2ffd-46b7-b7bf-a75ba999a31e@github.com>

On Fri, 17 Jan 2025 16:15:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - thomas feedback
>  - axel feedback

src/hotspot/share/utilities/rbTree.hpp line 76:

> 74: 
> 75:     void set_black() { _parent = _parent | 0x1; }
> 76:     void set_red() { _parent = _parent & ~0x1; }

Why not just |= and &= ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1923165338

From sroy at openjdk.org  Tue Jan 28 14:33:26 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 28 Jan 2025 14:33:26 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v15]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <4eOISOyDLMLb1xAZgEC7iHgYy_zKGbSXYC84zQb60kM=.5981ed84-efd8-486c-83df-f707da7ac6b3@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  permute vHigh,vLow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/3caf1d8c..102d1898

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=13-14

  Stats: 19 lines in 1 file changed: 10 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From cnorrbin at openjdk.org  Tue Jan 28 14:54:14 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 28 Jan 2025 14:54:14 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v12]
In-Reply-To: <-KpE74U1G2bdt5nXhgk2VJGp_tdxKlVIwU3SCCZn438=.e07fdfa5-aff0-4dd9-ae06-c9b931d4d20b@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <WNnxeDK3b5TGZtGnED3f5VPbI0tZXN0rVKlBaarUgcY=.7f48eb74-daf8-423f-b4e9-49a1436fbe6b@github.com>
 <p_56u6coCZ5o0IlHETPvWxTDOBAe1ggxFnC2Vh-FBTg=.29136950-e0b0-41e4-b519-fcfa0dc59d37@github.com>
 <Js_1d_siL72y7GiZl2V2O4lVVyv-lbuGaMX_imd1P7I=.f1a9f906-c46e-41fb-a6a5-6cd8138fd5c9@github.com>
 <-UXKHdcb2ypcIKf5nzjrl5bRAv2QDGf9ddNAusXMCLI=.dd4c0fb9-23a2-45a6-a836-77b16fd65450@github.com>
 <OsQblEIQ2Jhpk6r_vZM7QtLBr6ZKT8Gc1Wzf-9-Iw7E=.fce8422e-9473-4f3c-8e77-a4038f4f8684@github.com>
 <sXLE-TKOLYwhqZ1vTdBoWHDdieshwwBp6IpcwAY7G7M=.cc915bcf-de6e-498b-b71b-78441a6b2da3@github.com>
 <-KpE74U1G2bdt5nXhgk2VJGp_tdxKlVIwU3SCCZn438=.e07fdfa5-aff0-4dd9-ae06-c9b931d4d20b@github.com>
Message-ID: <fnTNqmrUYNSg35YhsL87ZlHEb6p0lMFTWtRryjMekJk=.4b75c730-af71-43d5-91fd-0359f8f7ff6c@github.com>

On Tue, 28 Jan 2025 14:11:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 
> Sorry, I have not forgotten you, but am booked out with FOSDEM preparations. I can continue the review when I come back (end of next week), or the week after.
> 
> I would have liked to prod at the meat of the insertion/deletion logic more, since I remember that part being particularly fiddly. We should get this right, this needs close review.
> 
> But I don't want to hold you up, so if you feel you need to push now, go ahead. I would definitely like to look at the intrusive variant, since I expect I will use that one quite a bit.

Thank you! The intrusive tree is [done](/caspernorrbin/jdk/tree/rb-tree-intrusive), waiting for this PR. It keeps the insertion/deletion logic identical, but reworks a lot of the surrounding functions. Since the tree isn't used anywhere yet, perhaps you could have a closer look at the insertion/deletion logic then? If there are any issues we can fix it there before the tree sees any real use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2619223883

From cnorrbin at openjdk.org  Tue Jan 28 14:54:13 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 28 Jan 2025 14:54:13 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v18]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <RuUweyyMxSAVzluGxC1CNj3-DdZVzvM0ERT1VVp0ArQ=.9fdc0231-4491-42da-bba4-3ef6f29d61e1@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  |& and &= when setting colors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/b7219a93..9e0631ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=16-17

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From sroy at openjdk.org  Tue Jan 28 15:11:55 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 28 Jan 2025 15:11:55 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v15]
In-Reply-To: <4eOISOyDLMLb1xAZgEC7iHgYy_zKGbSXYC84zQb60kM=.5981ed84-efd8-486c-83df-f707da7ac6b3@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <4eOISOyDLMLb1xAZgEC7iHgYy_zKGbSXYC84zQb60kM=.5981ed84-efd8-486c-83df-f707da7ac6b3@github.com>
Message-ID: <U3NEtjDu3Wl39HBh4nCYB87AMCu6HFvP4XE6v-C72Zk=.b3f1c96e-b7f0-47c7-8740-fee9379f2c0b@github.com>

On Tue, 28 Jan 2025 14:33:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   permute vHigh,vLow

==============================

   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/com/sun/crypto/provider/Cipher/AES/TestCopySafe.java
                                                         1     1     0     0   
==============================
TEST SUCCESS


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java
                                                         1     1     0     0   
==============================
TEST SUCCESS


Hi @TheRealMDoerr  the above tests pass now. Tier-2 tests are going to take time. Would it be possible for you to check the tier-2 tests, in case it takes lesser time ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2619277457

From shade at openjdk.org  Tue Jan 28 15:37:02 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 28 Jan 2025 15:37:02 GMT
Subject: RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
Message-ID: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>

We run into peculiar problem in Leyden: due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. The code buffer expansion routinely happens with late G1 barrier expansion, as `G1BarrierSetC2` does not report any estimate for stub sizes.

So a method rich in these G1 stubs would blow the initial code size estimate, force the buffer resize, and thus disqualify itself from storing C2 code in Leyden. Whoops. Fortunately, we just need to implement `G1BarrierSetC2::estimate_stub_size()` in mainline to avoid a significant part of this problem. 

I also fixed the misattribution of "stub" sizes in insn section, this part is also important to get the stub sizes right. I can do that separately, but it would only matter for ZGC without G1 stub size estimation implemented.

You can see the impact it has on Leyden here:
https://github.com/openjdk/leyden/pull/28#issuecomment-2619077625

Additional testing:
 - [ ] Linux x86_64 server fastdebug, `all`
 - [ ] Linux AArch64 server fastdebug, `all`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/23333/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23333&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348855
  Stats: 21 lines in 3 files changed: 20 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23333.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23333/head:pull/23333

PR: https://git.openjdk.org/jdk/pull/23333

From sroy at openjdk.org  Tue Jan 28 16:13:22 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 28 Jan 2025 16:13:22 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v16]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <O-JCYjacOTZlvVSYhLjJHrdR6IYDBoy49hp3j7irSDc=.434fc326-e793-4ffd-89cc-198c306cc27c@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - permute vHigh,vLow
 - indentation
 - comments
 - vsx logic change
 - spaces
 - spaces
 - update references
 - Comments and vsx check
 - restore
 -  assertion for blocks
 - ... and 27 more: https://git.openjdk.org/jdk/compare/fb066cae...24f3379a

-------------

Changes: https://git.openjdk.org/jdk/pull/20235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=15
  Stats: 183 lines in 2 files changed: 166 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From sroy at openjdk.org  Tue Jan 28 16:23:48 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 28 Jan 2025 16:23:48 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v17]
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <jlni9U-2PhbZUgr50_O7cz6jwE8GcVB7UFC1LbOUB6g=.e958f9b3-23c6-4433-8aa1-25f4b142313a@github.com>

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 - restore chnges
 - restore chnges

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20235/files
  - new: https://git.openjdk.org/jdk/pull/20235/files/24f3379a..fc2f1c30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=15-16

  Stats: 15 lines in 1 file changed: 1 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From sroy at openjdk.org  Tue Jan 28 16:40:53 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 28 Jan 2025 16:40:53 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm [v17]
In-Reply-To: <jlni9U-2PhbZUgr50_O7cz6jwE8GcVB7UFC1LbOUB6g=.e958f9b3-23c6-4433-8aa1-25f4b142313a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
 <jlni9U-2PhbZUgr50_O7cz6jwE8GcVB7UFC1LbOUB6g=.e958f9b3-23c6-4433-8aa1-25f4b142313a@github.com>
Message-ID: <VZAa5XfkONsSNkhXDpW2xgFnt48nVUzkvm3ImT4S02M=.c267675c-a227-4ad9-934d-9fa140ba3ece@github.com>

On Tue, 28 Jan 2025 16:23:48 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
>> 
>> Currently acceleration code for GHASH is missing for PPC64. 
>> 
>> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.
>
> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - restore chnges
>  - restore chnges

TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java
                                                         1     1     0     0 

TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/com/sun/crypto/provider/Cipher/AES/TestCopySafe.java
                                                         1     1     0     0

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20235#issuecomment-2619516891

From cslucas at openjdk.org  Tue Jan 28 18:37:48 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 28 Jan 2025 18:37:48 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
References: <e5SIIH1XtQ-EFSNZk2-rUzYP_HFku9C8LK_O-nVMSzI=.9d639980-5a54-41dc-989d-253669d3c392@github.com>
 <6_AoWQhldJttOIEOL1T7HSapPzE4Qn2j4WN7E-bI3rM=.2685d3d8-e47c-42a6-845b-b68f50cc568e@github.com>
Message-ID: <k1JWoseWNdq4KOByURGUWCbLdTW2m_-i_L6_Op8NZv4=.4ee6440d-4d6e-440b-bc1f-218b25093abb@github.com>

On Thu, 23 Jan 2025 05:45:43 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> In the current Generational Shenandoah implementation, the pointers to the read and write card tables are established at JVM launch time and fixed during the whole of the application execution. Because they are considered constants, they are embedded as such in JIT-compiled code. 
>> 
>> The cleaning of dirty cards in the read card table is performed during the `init-mark` pause, and our experiments show that it represents a sizable portion of that phase's duration. This pull request makes the addresses of the read and write card tables dynamic, with the end goal of reducing the duration of the `init-mark` pause by moving the cleaning of the dirty cards in the read card table to the `reset` concurrent phase.
>> 
>> The idea is quite simple. Instead of using distinct read and write card tables for the entire duration of the JVM execution, we alternate which card table serves as the read/write table during each GC cycle. In the `reset` phase we concurrently clean the cards in the the current _read_ table so that when the cycle reaches the next `init-mark` phase we have a version of the card table totally clear. In the next `init-mark` pause we swap the pointers to the base of the read and write tables. When the `init-mark` finishes the mutator threads will operate on the table just cleaned in the `reset` phase; the GC will operate on the table that just turned the new _read_ table.
>> 
>> Most of the changes in the patch account for the fact that the write card table is no longer at a fixed address.
>> 
>> The primary benefit of this change is that it eliminates the need to copy and zero the remembered set during the init-mark Safepoint. A secondary benefit is that it allows us to replace the init-mark Safepoint with an `init-mark` handshake?something we plan to work on after this PR is merged.
>> 
>> Our internal performance testing showed a significant reduction in the duration of `init-mark` pauses and no statistically significant regression due to the dynamic loading of the card table address in JIT-compiled code.
>> 
>> Functional testing was performed on Linux, macOS, Windows running on x64, AArch64, and their respective 32-bit versions. I?d appreciate it if someone with access to RISC-V (@luhenry  ?) and PowerPC (@TheRealMDoerr ?)  platforms could review and test the changes for those platforms, as I have limited access to running tests on them.
>
> Cesar Soares Lucas 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 master
>  - Addressing PR comments: some refactorings, ppc fix, off-by-one fix.
>  - Relocation of Card Tables

Anyone has any other concern / comment ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23170#issuecomment-2619780113

From vlivanov at openjdk.org  Tue Jan 28 21:10:46 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 28 Jan 2025 21:10:46 GMT
Subject: RFR: 8347564: ZGC: Crash in
 DependencyContext::clean_unloading_dependents
In-Reply-To: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
References: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
Message-ID: <fPBv6aEMxehADzNW75y5R02nsQJMy7SXQSv9gOxu7t0=.eb9ad293-b740-4aed-a80a-eb15ddce2661@github.com>

On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The proposed change here is the following:
>  1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object
>  2. Remove the Context object and its corresponding cleaner
> 
> (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose.
> 
> First what goes wrong without this patch.
> 
> Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. 
> 
> For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. 
> 
> The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection.
> 
> If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection  would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. 
> 
> For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ...

Thanks for the clarifications, Axel. The fix looks good. 

> But I'll take it a spin through our CI as well. 

Thanks!

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23194#pullrequestreview-2579417360

From sviswanathan at openjdk.org  Wed Jan 29 00:39:55 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 29 Jan 2025 00:39:55 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v14]
In-Reply-To: <NAy6q0P-B2RugBQiH57jMl0rjmgfmQj_eCarVrpfgiE=.ec5748f5-b455-401c-a4c8-c0198498c6a5@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <NAy6q0P-B2RugBQiH57jMl0rjmgfmQj_eCarVrpfgiE=.ec5748f5-b455-401c-a4c8-c0198498c6a5@github.com>
Message-ID: <a8fHXpvLDSBkJHZznAG6q3F7ElQlSZmw3ij0tg0aklY=.c78c1da8-9067-4d5f-b9c4-d21f10e34900@github.com>

On Tue, 28 Jan 2025 06:26:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating typos in comments

Some more minor comments below. Rest of the PR looks good to me.

src/hotspot/share/opto/subnode.hpp line 549:

> 547:   SqrtHFNode(Compile* C, Node* c, Node* in1) : Node(c, in1) {
> 548:     init_flags(Flag_is_expensive);
> 549:     C->add_expensive_node(this);

Do we need to set SqrtHF as expensive node? It translates to a single instruction.

src/hotspot/share/opto/type.hpp line 2031:

> 2029: 
> 2030: inline const TypeH* Type::is_half_float_constant() const {
> 2031:   assert( _base == HalfFloatCon, "Not a Float" );

Should be "Not a HalfFloat" here.

test/hotspot/jtreg/compiler/c2/irTests/ConvF2HFIdealizationTests.java line 32:

> 30: /*
> 31:  * @test
> 32:  * @bug 8338061

This should now refer to bug 8342103.

test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java line 33:

> 31: /*
> 32:  * @test
> 33:  * @bug 8336406

This should now refer to bug 8342103.

test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 27:

> 25: /**
> 26: * @test
> 27: * @bug 8308363 8336406

This should now refer to bug 8342103.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2579221309
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1932741039
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1932906990
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933045205
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933045649
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933045837

From jbhateja at openjdk.org  Wed Jan 29 06:26:41 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 29 Jan 2025 06:26:41 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v15]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <x30I_C4V5Tj8Kp1J3hOm-8-M20obWZuoR-i3dfwXN1U=.33dc854b-4631-4c2e-ac4e-38b832e60f53@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Fixing a typo error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/854fc73f..19fc6c2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=13-14

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Wed Jan 29 06:26:43 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 29 Jan 2025 06:26:43 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v14]
In-Reply-To: <a8fHXpvLDSBkJHZznAG6q3F7ElQlSZmw3ij0tg0aklY=.c78c1da8-9067-4d5f-b9c4-d21f10e34900@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <NAy6q0P-B2RugBQiH57jMl0rjmgfmQj_eCarVrpfgiE=.ec5748f5-b455-401c-a4c8-c0198498c6a5@github.com>
 <a8fHXpvLDSBkJHZznAG6q3F7ElQlSZmw3ij0tg0aklY=.c78c1da8-9067-4d5f-b9c4-d21f10e34900@github.com>
Message-ID: <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com>

On Wed, 29 Jan 2025 00:36:54 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating typos in comments
>
> Some more minor comments below. Rest of the PR looks good to me.

Hi @sviswa7 , your comments have been addressed.

> src/hotspot/share/opto/subnode.hpp line 549:
> 
>> 547:   SqrtHFNode(Compile* C, Node* c, Node* in1) : Node(c, in1) {
>> 548:     init_flags(Flag_is_expensive);
>> 549:     C->add_expensive_node(this);
> 
> Do we need to set SqrtHF as expensive node? It translates to a single instruction.

Its latency is around 15 cycles. Thus, GVN commoning, which leads to its placement onto a frequently executed control path, may be costly. In addition, it is also marked as an expensive node by ADLC to prevent rematerialization by the allocator.

> src/hotspot/share/opto/type.hpp line 2031:
> 
>> 2029: 
>> 2030: inline const TypeH* Type::is_half_float_constant() const {
>> 2031:   assert( _base == HalfFloatCon, "Not a Float" );
> 
> Should be "Not a HalfFloat" here.

Fixed this typo error.

> test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 27:
> 
>> 25: /**
>> 26: * @test
>> 27: * @bug 8308363 8336406
> 
> This should now refer to bug 8342103.

Test was added on lworld+fp16 branch and appropriately reflects the JBS entry. Same, applies to above two comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2620812050
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933322657
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933322637
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933322576

From aboldtch at openjdk.org  Wed Jan 29 06:52:51 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 29 Jan 2025 06:52:51 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v18]
In-Reply-To: <RuUweyyMxSAVzluGxC1CNj3-DdZVzvM0ERT1VVp0ArQ=.9fdc0231-4491-42da-bba4-3ef6f29d61e1@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <RuUweyyMxSAVzluGxC1CNj3-DdZVzvM0ERT1VVp0ArQ=.9fdc0231-4491-42da-bba4-3ef6f29d61e1@github.com>
Message-ID: <BVz4hpbReo_q-RU4I5m79VppZK4cn3nRVjFHiw-5G7M=.c2281d48-7b97-45ff-bea2-50a23e0b9730@github.com>

On Tue, 28 Jan 2025 14:54:13 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   |& and &= when setting colors

This looks really good now. Just a few more comments.

The parameter names should also be harmonised. At least for the public member functions. Right now both `k` and `key` is used, we should pick one (I like descriptive names in signatures, so I would pick the later, but I think the former use is more prevalent in your patch). And it should be consistent with `v`/`value`.

-------------

Changes requested by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2580086088

From aboldtch at openjdk.org  Wed Jan 29 06:52:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 29 Jan 2025 06:52:56 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v17]
In-Reply-To: <vqcXhVxlyVaYAIFzp1FyLfUnB63SZz9YVTl3-o4DbPc=.88bf2e76-21d1-4535-916f-71f34386688a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <vqcXhVxlyVaYAIFzp1FyLfUnB63SZz9YVTl3-o4DbPc=.88bf2e76-21d1-4535-916f-71f34386688a@github.com>
Message-ID: <5D_4fGDHt6xwpJJxil7XzWiwMYf6RG7VWdgbRY8HguY=.196ed28c-ee63-4e04-b58c-9f037d866b19@github.com>

On Tue, 28 Jan 2025 11:04:08 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
> 
>  - merge fixes
>  - Merge branch 'master' into rb-tree
>  - readd find_enclosing_range
>  - Merge branch 'master' into rb-tree
>  - treap swap fix
>  - const functions
>  - thomas feedback
>  - axel feedback
>  - clarified comment
>  - Improved comments
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/ad01dfb6...b7219a93

src/hotspot/share/utilities/rbTree.hpp line 79:

> 77: 
> 78:     RBNode* parent() const { return (RBNode*)(_parent & ~0x1); }
> 79:     void set_parent(RBNode* new_parent) {_parent = (_parent & 0x1) | ((uintptr_t)new_parent & ~0x1); }

When would `new_parent` not have a valid `RBNode*` pointer value? AFAICT it is only called with valid pointers. The lsb masking is unnecessary. If it is actually required from somewhere, I missed it, in which case we should use `uintptr_t`.

src/hotspot/share/utilities/rbTree.hpp line 204:

> 202:   // Finds the node with the closest key <= the given key
> 203:   // Change mode to EXCLUSIVE to not include node matching key
> 204:   RBNode* closest_leq(const K& key, BoundMode mode = INCLUSIVE) {

Having a parameter value change the behaviour to contradict the name of the function feels a little evil. Might cause confusion and bugs in the future. I would rather have one `closest(Key, Direction, BoundMode)` and/or four `closest_[ls,leq,geq,gt](Key)`.

src/hotspot/share/utilities/rbTree.hpp line 247:

> 245: 
> 246:   const RBNode* closest_leq(const K& k, BoundMode mode = INCLUSIVE) const {
> 247:     return const_cast<RBTree<K, V, COMPARATOR, ALLOCATOR>*>(this)->closest_leq(k, mode);

When it comes to `const` overloads of `accessor` like member functions I prefer that we invert the `const` cast logic. That is that it is the `const` variant that includes the implementation. And that the non-`const` variant dispatches to the `const` versions and then casts away the the `const` qualifier on the result. This ensures that the implementation does not break the `const` property of the class, and is less bug prone.

src/hotspot/share/utilities/rbTree.hpp line 251:

> 249: 
> 250:   const RBNode* closest_gt(const K& k, BoundMode mode = EXCLUSIVE) const {
> 251:     return const_cast<RBTree<K, V, COMPARATOR, ALLOCATOR>*>(this)->closest_gt(k, mode);

Same.

src/hotspot/share/utilities/rbTree.hpp line 274:

> 272: 
> 273:   const RBNode* find_node(const K& k) const {
> 274:     return const_cast<RBTree<K, V, COMPARATOR, ALLOCATOR>*>(this)->find_node(k);

Same.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933329704
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933320201
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933309763
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933321189
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933321261

From aboldtch at openjdk.org  Wed Jan 29 07:17:00 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 29 Jan 2025 07:17:00 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v18]
In-Reply-To: <RuUweyyMxSAVzluGxC1CNj3-DdZVzvM0ERT1VVp0ArQ=.9fdc0231-4491-42da-bba4-3ef6f29d61e1@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <RuUweyyMxSAVzluGxC1CNj3-DdZVzvM0ERT1VVp0ArQ=.9fdc0231-4491-42da-bba4-3ef6f29d61e1@github.com>
Message-ID: <5IrFpKnK8QwJcOK2utM4jeY5Zbk2OpMhCA3zgsHuk_c=.e6a8468f-1063-4489-afa9-ab6af149eb01@github.com>

On Tue, 28 Jan 2025 14:54:13 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   |& and &= when setting colors

src/hotspot/share/utilities/rbTree.inline.hpp line 31:

> 29: #include "utilities/powerOfTwo.hpp"
> 30: #include "utilities/rbTree.hpp"
> 31: #include <utility> // for std::swap

Can we use the `swap` from `utilities/globalDefinitions.hpp` instead? This would be the first explicit include of `<utility>` in hotspot. It is probably the path of least resistance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933365018

From azafari at openjdk.org  Wed Jan 29 08:16:11 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 29 Jan 2025 08:16:11 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v18]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <ls3qbbPjOKZ6hxxj-MKQJhLofyhIYfQM5IWbTY5ZOJY=.15bd8fbe-849e-4392-9496-faae9b76e4d7@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  merge with the new lock mechanism for NMT

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/5429e79c..692987e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=16-17

  Stats: 9 lines in 4 files changed: 7 ins; 0 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 stefank at openjdk.org  Wed Jan 29 08:38:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 29 Jan 2025 08:38:57 GMT
Subject: Integrated: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide
In-Reply-To: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
Message-ID: <CHWUfLkkLen61loL7bD5a20siGxXp1gXeYgYPsubiGA=.3a54b803-d9a1-4a1f-b36e-2859d9d0da6e@github.com>

On Tue, 21 Jan 2025 12:29:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need for HotSpot devs to include the precompiled.hpp. This is the PR to reflect that.
> 
> I know that there is some process around updating the style guide, but I can't find it, so I'm starting with a plain PR.

This pull request has now been integrated.

Changeset: 3af4cfc5
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3af4cfc52d7d72ebd93d277a7b46d3526f8f59d2
Stats:     8 lines in 2 files changed: 0 ins; 0 del; 8 mod

8348180: Remove mention of include of precompiled.hpp from the HotSpot Style Guide

Reviewed-by: dholmes, eosterlund

-------------

PR: https://git.openjdk.org/jdk/pull/23210

From stefank at openjdk.org  Wed Jan 29 08:38:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 29 Jan 2025 08:38:57 GMT
Subject: RFR: 8348180: Remove mention of include of precompiled.hpp from
 the HotSpot Style Guide [v2]
In-Reply-To: <JChUJHsXOxUFNs-FMGcSM2MsbsGjGqg31cNWsLWQqnA=.9a999154-b540-41a9-9fb7-6fb428cc9a5c@github.com>
References: <qPTKgmEW9zkgxJKu95pdQBcswZ7DgqpqrmhaJB-kG-o=.93a172a7-6942-438b-bd34-dad59beeb164@github.com>
 <JChUJHsXOxUFNs-FMGcSM2MsbsGjGqg31cNWsLWQqnA=.9a999154-b540-41a9-9fb7-6fb428cc9a5c@github.com>
Message-ID: <WTkC7A3WsyOa59DbyPAnOgGC8rLiD-x6e1QdQ_alCnI=.2c9e0970-0ceb-472f-a687-e2ee28f746e8@github.com>

On Wed, 22 Jan 2025 09:34:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> [JDK-8347909](https://bugs.openjdk.org/browse/JDK-8347909) removed the need for HotSpot devs to include the precompiled.hpp. This is the PR to reflect that.
>> 
>> I know that there is some process around updating the style guide, but I can't find it, so I'm starting with a plain PR.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update hotspot-style.md
>  - Update hotspot-style.html

Thanks all for reviewing! This has been out for review for over a week now. I think that's long enough to consider this change accepted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23210#issuecomment-2620990566

From adinn at openjdk.org  Wed Jan 29 08:54:54 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 29 Jan 2025 08:54:54 GMT
Subject: RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
In-Reply-To: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
References: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
Message-ID: <d0wjeJuDHDVFkRhvKGBh67k9c8oj5XXc7Gl_rOCaPo4=.acca8ba0-e4ff-46d0-bd0c-9beadb5bb5ca@github.com>

On Tue, 28 Jan 2025 14:01:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We run into peculiar problem in Leyden: due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. The code buffer expansion routinely happens with late G1 barrier expansion, as `G1BarrierSetC2` does not report any estimate for stub sizes.
> 
> So a method rich in these G1 stubs would blow the initial code size estimate, force the buffer resize, and thus disqualify itself from storing C2 code in Leyden. Whoops. Fortunately, we just need to implement `G1BarrierSetC2::estimate_stub_size()` in mainline to avoid a significant part of this problem. 
> 
> I also fixed the misattribution of "stub" sizes in insn section, this part is also important to get the stub sizes right. I can do that separately, but it would only matter for ZGC without G1 stub size estimation implemented.
> 
> You can see the impact it has on Leyden here:
> https://github.com/openjdk/leyden/pull/28#issuecomment-2619077625
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Looks good modulo the nit over excess slop.

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 550:

> 548: 
> 549:   // Add slop to avoid expansion during emit_stubs.
> 550:   return size + PhaseOutput::MAX_inst_size;

Is this needed? `init_buffer` already bumps `code_req` up by `MAX_inst_size` immediately after calling `bs->estimate_stub_size()` and that headroom is maintained at each instruction emit.

-------------

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23333#pullrequestreview-2580365098
PR Review Comment: https://git.openjdk.org/jdk/pull/23333#discussion_r1933482064

From cnorrbin at openjdk.org  Wed Jan 29 10:11:36 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 29 Jan 2025 10:11:36 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v19]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <f2dV9-ZK_4uRkJvVrUB650vmyuwHyGKL_m_8y_KgAw0=.20423d89-38ca-44e5-b5e3-1d7e8a2637b7@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  axel feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/9e0631ab..d4d60fff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=17-18

  Stats: 70 lines in 2 files changed: 26 ins; 6 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From cnorrbin at openjdk.org  Wed Jan 29 10:11:40 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 29 Jan 2025 10:11:40 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v17]
In-Reply-To: <5D_4fGDHt6xwpJJxil7XzWiwMYf6RG7VWdgbRY8HguY=.196ed28c-ee63-4e04-b58c-9f037d866b19@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <vqcXhVxlyVaYAIFzp1FyLfUnB63SZz9YVTl3-o4DbPc=.88bf2e76-21d1-4535-916f-71f34386688a@github.com>
 <5D_4fGDHt6xwpJJxil7XzWiwMYf6RG7VWdgbRY8HguY=.196ed28c-ee63-4e04-b58c-9f037d866b19@github.com>
Message-ID: <L-Tu6DQJNO_7IDFfoB3vpVXqcrZoIyS_xKVu9QaysdA=.d30d269a-0e51-4d59-a78a-8576457271b8@github.com>

On Wed, 29 Jan 2025 06:04:44 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
>> 
>>  - merge fixes
>>  - Merge branch 'master' into rb-tree
>>  - readd find_enclosing_range
>>  - Merge branch 'master' into rb-tree
>>  - treap swap fix
>>  - const functions
>>  - thomas feedback
>>  - axel feedback
>>  - clarified comment
>>  - Improved comments
>>  - ... and 26 more: https://git.openjdk.org/jdk/compare/ad01dfb6...b7219a93
>
> src/hotspot/share/utilities/rbTree.hpp line 247:
> 
>> 245: 
>> 246:   const RBNode* closest_leq(const K& k, BoundMode mode = INCLUSIVE) const {
>> 247:     return const_cast<RBTree<K, V, COMPARATOR, ALLOCATOR>*>(this)->closest_leq(k, mode);
> 
> When it comes to `const` overloads of `accessor` like member functions I prefer that we invert the `const` cast logic. That is that it is the `const` variant that includes the implementation. And that the non-`const` variant dispatches to the `const` versions and then casts away the the `const` qualifier on the result. This ensures that the implementation does not break the `const` property of the class, and is less bug prone.

Swapped them around to have the non-const depend on the const version

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933594842

From shade at openjdk.org  Wed Jan 29 10:11:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 29 Jan 2025 10:11:51 GMT
Subject: RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
In-Reply-To: <d0wjeJuDHDVFkRhvKGBh67k9c8oj5XXc7Gl_rOCaPo4=.acca8ba0-e4ff-46d0-bd0c-9beadb5bb5ca@github.com>
References: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
 <d0wjeJuDHDVFkRhvKGBh67k9c8oj5XXc7Gl_rOCaPo4=.acca8ba0-e4ff-46d0-bd0c-9beadb5bb5ca@github.com>
Message-ID: <AKhJ2Kq6XUZMtd5FlZ12RX7UhH7eXC8JeFcLB_dx6Do=.f2b380b9-224b-4f68-bbf2-5b41930ea670@github.com>

On Wed, 29 Jan 2025 08:51:10 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> We run into peculiar problem in Leyden: due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. The code buffer expansion routinely happens with late G1 barrier expansion, as `G1BarrierSetC2` does not report any estimate for stub sizes.
>> 
>> So a method rich in these G1 stubs would blow the initial code size estimate, force the buffer resize, and thus disqualify itself from storing C2 code in Leyden. Whoops. Fortunately, we just need to implement `G1BarrierSetC2::estimate_stub_size()` in mainline to avoid a significant part of this problem. 
>> 
>> I also fixed the misattribution of "stub" sizes in insn section, this part is also important to get the stub sizes right. I can do that separately, but it would only matter for ZGC without G1 stub size estimation implemented.
>> 
>> You can see the impact it has on Leyden here:
>> https://github.com/openjdk/leyden/pull/28#issuecomment-2619077625
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 550:
> 
>> 548: 
>> 549:   // Add slop to avoid expansion during emit_stubs.
>> 550:   return size + PhaseOutput::MAX_inst_size;
> 
> Is this needed? `init_buffer` already bumps `code_req` up by `MAX_inst_size` immediately after calling `bs->estimate_stub_size()` and that headroom is maintained at each instruction emit.

Yes, I think so. Leyden experiments show this is needed. The slop added in `init_buffer` is going to be taken by normal code itself. This particular addition matches `maybe_expand_to_ensure_remaining(PhaseOutput::MAX_inst_size)` in `G1BarrierSetC2::emit_stubs` just below it. In other words, `emit_stubs` would always maintain `MAX_inst_size` remaining capacity, and that would happen after the normal code is emitted. So we need this slop addition here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23333#discussion_r1933595140

From cnorrbin at openjdk.org  Wed Jan 29 10:13:56 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 29 Jan 2025 10:13:56 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v17]
In-Reply-To: <5D_4fGDHt6xwpJJxil7XzWiwMYf6RG7VWdgbRY8HguY=.196ed28c-ee63-4e04-b58c-9f037d866b19@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <vqcXhVxlyVaYAIFzp1FyLfUnB63SZz9YVTl3-o4DbPc=.88bf2e76-21d1-4535-916f-71f34386688a@github.com>
 <5D_4fGDHt6xwpJJxil7XzWiwMYf6RG7VWdgbRY8HguY=.196ed28c-ee63-4e04-b58c-9f037d866b19@github.com>
Message-ID: <-He-nW7_CFzvevnfItJ1FABk9tejMSCBaR47r2HGUtw=.2a06fc69-999c-4b6b-9c70-6b896f24096e@github.com>

On Wed, 29 Jan 2025 06:19:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
>> 
>>  - merge fixes
>>  - Merge branch 'master' into rb-tree
>>  - readd find_enclosing_range
>>  - Merge branch 'master' into rb-tree
>>  - treap swap fix
>>  - const functions
>>  - thomas feedback
>>  - axel feedback
>>  - clarified comment
>>  - Improved comments
>>  - ... and 26 more: https://git.openjdk.org/jdk/compare/ad01dfb6...b7219a93
>
> src/hotspot/share/utilities/rbTree.hpp line 204:
> 
>> 202:   // Finds the node with the closest key <= the given key
>> 203:   // Change mode to EXCLUSIVE to not include node matching key
>> 204:   RBNode* closest_leq(const K& key, BoundMode mode = INCLUSIVE) {
> 
> Having a parameter value change the behaviour to contradict the name of the function feels a little evil. Might cause confusion and bugs in the future. I would rather have one `closest(Key, Direction, BoundMode)` and/or four `closest_[ls,leq,geq,gt](Key)`.

I kept it simple and separated them into separate functions. These are re-done more nicely with cursors in the intrusive version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933599964

From cnorrbin at openjdk.org  Wed Jan 29 10:17:01 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 29 Jan 2025 10:17:01 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v17]
In-Reply-To: <5D_4fGDHt6xwpJJxil7XzWiwMYf6RG7VWdgbRY8HguY=.196ed28c-ee63-4e04-b58c-9f037d866b19@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <vqcXhVxlyVaYAIFzp1FyLfUnB63SZz9YVTl3-o4DbPc=.88bf2e76-21d1-4535-916f-71f34386688a@github.com>
 <5D_4fGDHt6xwpJJxil7XzWiwMYf6RG7VWdgbRY8HguY=.196ed28c-ee63-4e04-b58c-9f037d866b19@github.com>
Message-ID: <yBVT0hMMrYze7ocVx8OzGMVeePWQnd7rcwq0HE9fTMc=.c3786427-de6a-4727-8410-944af6345058@github.com>

On Wed, 29 Jan 2025 06:30:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:
>> 
>>  - merge fixes
>>  - Merge branch 'master' into rb-tree
>>  - readd find_enclosing_range
>>  - Merge branch 'master' into rb-tree
>>  - treap swap fix
>>  - const functions
>>  - thomas feedback
>>  - axel feedback
>>  - clarified comment
>>  - Improved comments
>>  - ... and 26 more: https://git.openjdk.org/jdk/compare/ad01dfb6...b7219a93
>
> src/hotspot/share/utilities/rbTree.hpp line 79:
> 
>> 77: 
>> 78:     RBNode* parent() const { return (RBNode*)(_parent & ~0x1); }
>> 79:     void set_parent(RBNode* new_parent) {_parent = (_parent & 0x1) | ((uintptr_t)new_parent & ~0x1); }
> 
> When would `new_parent` not have a valid `RBNode*` pointer value? AFAICT it is only called with valid pointers. The lsb masking is unnecessary. If it is actually required from somewhere, I missed it, in which case we should use `uintptr_t`.

You're right, the masking here does nothing. I removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1933603794

From adinn at openjdk.org  Wed Jan 29 11:57:47 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 29 Jan 2025 11:57:47 GMT
Subject: RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
In-Reply-To: <AKhJ2Kq6XUZMtd5FlZ12RX7UhH7eXC8JeFcLB_dx6Do=.f2b380b9-224b-4f68-bbf2-5b41930ea670@github.com>
References: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
 <d0wjeJuDHDVFkRhvKGBh67k9c8oj5XXc7Gl_rOCaPo4=.acca8ba0-e4ff-46d0-bd0c-9beadb5bb5ca@github.com>
 <AKhJ2Kq6XUZMtd5FlZ12RX7UhH7eXC8JeFcLB_dx6Do=.f2b380b9-224b-4f68-bbf2-5b41930ea670@github.com>
Message-ID: <pUgafdQYp8VYq3VqlrCSpMYZBhlTxsgWepsqxTuKkZQ=.e91717fe-fc3c-42e4-9abf-f93a3350b528@github.com>

On Wed, 29 Jan 2025 10:08:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 550:
>> 
>>> 548: 
>>> 549:   // Add slop to avoid expansion during emit_stubs.
>>> 550:   return size + PhaseOutput::MAX_inst_size;
>> 
>> Is this needed? `init_buffer` already bumps `code_req` up by `MAX_inst_size` immediately after calling `bs->estimate_stub_size()` and that headroom is maintained at each instruction emit.
>
> Yes, I think so. Leyden experiments show this is needed. AFAICS, the `MAX_inst_size` added in `init_buffer` is going to be taken by normal code itself, so then when we'll go to final stub emit with `G1BarrierSetC2::emit_stubs`, we will encounter `maybe_expand_to_ensure_remaining(MAX_inst_size)`, but the part of `MAX_inst_size` would already be eaten, and this will force expansion.
> 
> In other words, if we maintain `MAX_inst_size` window when emitting stubs in `G1BarrierSetC2::emit_stubs`, we need to include that in estimate.

Ok, good to go then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23333#discussion_r1933749743

From aboldtch at openjdk.org  Wed Jan 29 12:46:02 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 29 Jan 2025 12:46:02 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v19]
In-Reply-To: <f2dV9-ZK_4uRkJvVrUB650vmyuwHyGKL_m_8y_KgAw0=.20423d89-38ca-44e5-b5e3-1d7e8a2637b7@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <f2dV9-ZK_4uRkJvVrUB650vmyuwHyGKL_m_8y_KgAw0=.20423d89-38ca-44e5-b5e3-1d7e8a2637b7@github.com>
Message-ID: <fknH3qF6EurAIUVtP7DuSRd1vCq9Yy1Alc0JsVGFbec=.78e1608d-b2a6-44da-99e2-0423f794797a@github.com>

On Wed, 29 Jan 2025 10:11:36 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   axel feedback

lgtm.

-------------

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2580923563

From duke at openjdk.org  Wed Jan 29 16:59:59 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 29 Jan 2025 16:59:59 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v18]
In-Reply-To: <ls3qbbPjOKZ6hxxj-MKQJhLofyhIYfQM5IWbTY5ZOJY=.15bd8fbe-849e-4392-9496-faae9b76e4d7@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <ls3qbbPjOKZ6hxxj-MKQJhLofyhIYfQM5IWbTY5ZOJY=.15bd8fbe-849e-4392-9496-faae9b76e4d7@github.com>
Message-ID: <c2dmuzlHlglQS39N3OzfdA3U0ioO3x5MlOuxazBZ4NY=.6a98366f-ce3e-4536-92e6-68581ecd201d@github.com>

On Wed, 29 Jan 2025 08:16:11 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>>  - Adding a runtime flag for selecting the old or new version can be added later.
>>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge with the new lock mechanism for NMT

src/hotspot/os/windows/os_windows.cpp line 3642:

> 3640:       log_warning(os)("bad release: [" PTR_FORMAT "-" PTR_FORMAT "): %s", p2i(start), p2i(end), err);
> 3641: #ifdef ASSERT
> 3642:       os::print_memory_mappings((char*)start, bytes, tty);

I think this will cause lock rank conflicts if you leave it in.  Please see [here](https://github.com/openjdk/jdk/pull/22745#discussion_r1890345578) and [here](https://github.com/openjdk/jdk/pull/22745#discussion_r1894197615) for more context.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1934257490

From sviswanathan at openjdk.org  Wed Jan 29 17:06:53 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 29 Jan 2025 17:06:53 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v15]
In-Reply-To: <x30I_C4V5Tj8Kp1J3hOm-8-M20obWZuoR-i3dfwXN1U=.33dc854b-4631-4c2e-ac4e-38b832e60f53@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <x30I_C4V5Tj8Kp1J3hOm-8-M20obWZuoR-i3dfwXN1U=.33dc854b-4631-4c2e-ac4e-38b832e60f53@github.com>
Message-ID: <2mwDB7u60CMOcPcuaaWxn9XblgXILZtgOvNwQqQyBno=.0f042b54-c6b5-4bbe-bd7a-23792b7774f9@github.com>

On Wed, 29 Jan 2025 06:26:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing a typo error

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2581694270

From adinn at openjdk.org  Wed Jan 29 17:18:37 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 29 Jan 2025 17:18:37 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v14]
In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
Message-ID: <2NESd0o8NjT6F7Q3CYKiM7WYRx8cvNW3LgeL4Jt3Rl4=.ea23dd39-11d5-4921-8543-593808cd79e0@github.com>

> Implementation of JDK-8343767

Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits:

 - bump up compiler blob size to allow for large code cache segment/alignment sizes
 - merge
 - update copyrights
 - remove unreferenced local var
 - allow repeated entries rather than stubs
 - correct error in stub routines fill test
 - remove unused ppc stub
 - fix errors in s390 arraycopy code
 - correct errors in stubgen blob sizes
 - merge
 - ... and 58 more: https://git.openjdk.org/jdk/compare/51cce6e6...cc85c18a

-------------

Changes: https://git.openjdk.org/jdk/pull/21957/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=13
  Stats: 7098 lines in 57 files changed: 4053 ins; 1642 del; 1403 mod
  Patch: https://git.openjdk.org/jdk/pull/21957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957

PR: https://git.openjdk.org/jdk/pull/21957

From adinn at openjdk.org  Wed Jan 29 17:23:54 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 29 Jan 2025 17:23:54 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <14uBUhX_V0bQgetjK4ojSYJeJYRcM1jBMV60Hk8VaRQ=.5b5144d6-c077-4e15-b9a7-7a25858bbfd8@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
 <14uBUhX_V0bQgetjK4ojSYJeJYRcM1jBMV60Hk8VaRQ=.5b5144d6-c077-4e15-b9a7-7a25858bbfd8@github.com>
Message-ID: <2-Cadd8Ra9OJBUfrsJZdnKk7EgPEZ-LFoA_XM-dr1aY=.cdd26dce-de81-4973-bd30-550469676567@github.com>

On Thu, 16 Jan 2025 22:15:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyrights
>
> I see compiler/arguments/TestCodeEntryAlignment.java failures on x64.
> 
> 
> #  Internal Error (.../src/hotspot/share/asm/codeBuffer.hpp:200), pid=1218011, tid=1218066
> #  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007f52b412a000 <= 0x00007f52b413e141 <= 0x00007f52b413e140
> 
> Command Line: -XX:+UnlockExperimentalVMOptions -XX:CodeCacheSegmentSize=1024 -XX:CodeEntryAlignment=1024 compiler.arguments.TestCodeEntryAlignment run
> 
> Current thread (0x00007f52c422b220):  JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=1218066, stack(0x00007f52a4f9b000,0x00007f52a509b000) (1024K)]
> 
> V  [libjvm.so+0x68c7b0]  Assembler::vmovdqu(Address, XMMRegister)+0x250  (codeBuffer.hpp:200)
> V  [libjvm.so+0x1390ed3]  MacroAssembler::vmovdqu(Address, XMMRegister)+0x73  (macroAssembler_x86.cpp:2663)
> V  [libjvm.so+0x176f4d5]  StubGenerator::generate_base64_encodeBlock()+0x955  (stubGenerator_x86_64.cpp:2081)
> V  [libjvm.so+0x1777c7d]  StubGenerator::generate_compiler_stubs()+0x5cd  (stubGenerator_x86_64.cpp:4296)
> V  [libjvm.so+0x17795e8]  StubGenerator_generate(CodeBuffer*, StubGenBlobId)+0xe8  (stubGenerator_x86_64.cpp:4421)
> V  [libjvm.so+0x17d2ff8]  initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*) [clone .constprop.0]+0xe8  (stubRoutines.cpp:233)
> V  [libjvm.so+0x17d55fc]  compiler_stubs_init(bool)+0x9c  (stubRoutines.cpp:264)
> ...

@iwanowww @TheRealMDoerr The x86 failure happens when the test sets code cache segment size and alignment both to 1024. There are so many stubs in the compiler blob on x86_64 that this requires an extra 8000 bytes to be added to the current blob size. The slop for this case is only 900 bytes but the test is a fairly unrealistic scenario. With both values set to 512 we have over 13000 bytes of slop. So, I think I have added enough for realistic purposes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2622315592

From ccheung at openjdk.org  Wed Jan 29 18:00:48 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 29 Jan 2025 18:00:48 GMT
Subject: RFR: 8348349: Refactor CDSConfig::is_dumping_heap() [v2]
In-Reply-To: <9oFUK6ektKeH7tMcXqYPS_jCn6TsNTal_JPUAhioZrg=.3241f2d3-49d1-4ba7-8aeb-e266da61a026@github.com>
References: <aJSxWYbphwjmduPtneuham3ICMNxPNl_n45g5uZhNLw=.d3cef46f-715d-4586-8cb0-fbe99fa118ee@github.com>
 <9oFUK6ektKeH7tMcXqYPS_jCn6TsNTal_JPUAhioZrg=.3241f2d3-49d1-4ba7-8aeb-e266da61a026@github.com>
Message-ID: <XpP-95cxaY6mlQOnAX72D4uRedOypnIvkjurcDcTHOY=.19997be8-afe1-42db-a40d-505de96cff90@github.com>

On Mon, 27 Jan 2025 05:51:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small clean up:
>> 
>> `HeapShared::can_write()` and `CDSConfig::is_dumping_heap()` are both for deciding whether CDS should dump heap objects. I removed the former and consolidated all the logic to the latter.
>> 
>> I also updated the logging message in case heap objects cannot be dumped.
>> 
>> I also updated VMProps to clarify what `vmCDSCanWriteArchivedJavaHeap()` means.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @matias9927 comment

LGTM

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23249#pullrequestreview-2581823665

From kvn at openjdk.org  Wed Jan 29 19:17:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 29 Jan 2025 19:17:46 GMT
Subject: RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
In-Reply-To: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
References: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
Message-ID: <aJZKddcKRnccXC9E4Nro7nMDRActte7a-SHTnGo7zBI=.8628d81d-c84a-4a73-bfaa-f0fd21f1d3b9@github.com>

On Tue, 28 Jan 2025 14:01:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We run into peculiar problem in Leyden: due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. The code buffer expansion routinely happens with late G1 barrier expansion, as `G1BarrierSetC2` does not report any estimate for stub sizes.
> 
> So a method rich in these G1 stubs would blow the initial code size estimate, force the buffer resize, and thus disqualify itself from storing C2 code in Leyden. Whoops. Fortunately, we just need to implement `G1BarrierSetC2::estimate_stub_size()` in mainline to avoid a significant part of this problem. 
> 
> I also fixed the misattribution of "stub" sizes in insn section, this part is also important to get the stub sizes right. I can do that separately, but it would only matter for ZGC without G1 stub size estimation implemented.
> 
> You can see the impact it has on Leyden here:
> https://github.com/openjdk/leyden/pull/28#issuecomment-2619077625
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23333#pullrequestreview-2581990668

From zgu at openjdk.org  Wed Jan 29 22:04:55 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 29 Jan 2025 22:04:55 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
Message-ID: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>

Please review this trivial change that improves output readability.

-------------

Commit messages:
 - 8349003: NativeCallStack::print_on() output is unreadable

Changes: https://git.openjdk.org/jdk/pull/23359/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23359&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349003
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23359/head:pull/23359

PR: https://git.openjdk.org/jdk/pull/23359

From dholmes at openjdk.org  Thu Jan 30 02:51:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Jan 2025 02:51:10 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures [v2]
In-Reply-To: <3rvoe3fw-Qv2tyGwomaDxy2hNzfoaZuj4wUdgQzi5hM=.f8522d94-df2b-44a0-8a7f-503e7b19ce71@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
 <3rvoe3fw-Qv2tyGwomaDxy2hNzfoaZuj4wUdgQzi5hM=.f8522d94-df2b-44a0-8a7f-503e7b19ce71@github.com>
Message-ID: <kQ_gF-5pbuIxVWxBDsVCnt0em0h3cy3JsuaDG2RRhWk=.c511a9d6-bf29-434a-876d-e2f95de345d5@github.com>

On Mon, 27 Jan 2025 18:19:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.
>> 
>> While doing this change I also added some extra info about the area that we tried to reserve and commit.
>> 
>> A couple of G1 tests had to be tweaked.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update memoryReserver.cpp

In the context of where this code was originally added ([JDK-8265268](https://bugs.openjdk.org/browse/JDK-8265268)), in `virtualSpace.cpp` the use of `log_debug(gc, heap, coops)` was consistent with, and formed part of the tracing for, all the memory logging in that code. I don't disagree that you might want to more generically enable this logging, but it will now be missing from that established logging path. It doesn't affect me either way, but people who use that logging may have a stronger opinion.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23297#pullrequestreview-2582809252

From ssubramaniam at openjdk.org  Thu Jan 30 04:49:22 2025
From: ssubramaniam at openjdk.org (Satyen Subramaniam)
Date: Thu, 30 Jan 2025 04:49:22 GMT
Subject: RFR: 8348610: GenShen: TestShenandoahEvacuationInformationEvent failed
 with setRegions >= regionsFreed: expected 1 >= 57
Message-ID: <M-8yf6fmPVUPLubCfG83quv9jTAHkqhcrgy_dHy288M=.70835c1f-be6c-4ff7-b2a1-1eb2b96ba69f@github.com>

Renaming `ShenandoahEvacuationInformation.freedRegions` to `ShenandoahEvacuationInformation.freeRegions` for clarity, and fixing incorrect assertion in  TestShenandoahEvacuationInformationEvent.cpp

Tested with tier 1, tier 2, and tier 3 tests.

-------------

Commit messages:
 - Adjusting ShenandoahEvacuationInformation event and test assertions

Changes: https://git.openjdk.org/jdk/pull/23362/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23362&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348610
  Stats: 15 lines in 5 files changed: 2 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/23362.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23362/head:pull/23362

PR: https://git.openjdk.org/jdk/pull/23362

From vlivanov at openjdk.org  Thu Jan 30 06:15:58 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 30 Jan 2025 06:15:58 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v14]
In-Reply-To: <2NESd0o8NjT6F7Q3CYKiM7WYRx8cvNW3LgeL4Jt3Rl4=.ea23dd39-11d5-4921-8543-593808cd79e0@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <2NESd0o8NjT6F7Q3CYKiM7WYRx8cvNW3LgeL4Jt3Rl4=.ea23dd39-11d5-4921-8543-593808cd79e0@github.com>
Message-ID: <hcrHV1JGaVti1PsFvPR5vroZB_BwrAPOi69l-5jHKz0=.acae052f-29d2-4386-bbd8-86034c9d04d6@github.com>

On Wed, 29 Jan 2025 17:18:37 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits:
> 
>  - bump up compiler blob size to allow for large code cache segment/alignment sizes
>  - merge
>  - update copyrights
>  - remove unreferenced local var
>  - allow repeated entries rather than stubs
>  - correct error in stub routines fill test
>  - remove unused ppc stub
>  - fix errors in s390 arraycopy code
>  - correct errors in stubgen blob sizes
>  - merge
>  - ... and 58 more: https://git.openjdk.org/jdk/compare/51cce6e6...cc85c18a

Looks good. 

Testing results (hs-tier1 - hs-tier4) are clean.

Marked as reviewed by vlivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21957#pullrequestreview-2583002679
PR Review: https://git.openjdk.org/jdk/pull/21957#pullrequestreview-2583003078

From dholmes at openjdk.org  Thu Jan 30 06:38:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Jan 2025 06:38:45 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
Message-ID: <Ra1nEYRZH2gCWlg7KagLb8PJ5huiYhIsIBImBhhYT7U=.2c706a97-51c8-4861-b963-bcd16005ad74@github.com>

On Wed, 29 Jan 2025 22:00:08 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial change that improves output readability.

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/utilities/nativeCallStack.cpp line 118:

> 116:     out->cr();
> 117:   }
> 118:   out->cr();

Do you need the `cr()` after the loop now? Guess it is a matter of personal preference depending on the context in which this gets printed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23359#pullrequestreview-2583029495
PR Review Comment: https://git.openjdk.org/jdk/pull/23359#discussion_r1935077246

From stuefe at openjdk.org  Thu Jan 30 07:28:50 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Jan 2025 07:28:50 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
Message-ID: <aCuS8RIwBMgkf7DIEvEN6zKYjRpE4XtAlAf655N76q0=.63376c4a-8993-4739-8481-2c945ece8027@github.com>

On Wed, 29 Jan 2025 22:00:08 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial change that improves output readability.

I don't understand, where did we break this? Did I break this with [8333994](https://github.com/openjdk/jdk/pull/19655/files#top)?

If so, why did NMT tests not fall all over the place? They should have catched such a regression.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2623733529

From aboldtch at openjdk.org  Thu Jan 30 08:17:48 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 30 Jan 2025 08:17:48 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <aCuS8RIwBMgkf7DIEvEN6zKYjRpE4XtAlAf655N76q0=.63376c4a-8993-4739-8481-2c945ece8027@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <aCuS8RIwBMgkf7DIEvEN6zKYjRpE4XtAlAf655N76q0=.63376c4a-8993-4739-8481-2c945ece8027@github.com>
Message-ID: <RaaVebgtuyKofSqWkt1CyYNUmOBLz7f1vZGHJcWRiE4=.975ac9b6-2be9-4b4d-9cea-5840eabb113c@github.com>

On Thu, 30 Jan 2025 07:25:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this trivial change that improves output readability.
>
> I don't understand, where did we break this? Did I break this with [8333994](https://github.com/openjdk/jdk/pull/19655/files#top)?
> 
> If so, why did NMT tests not fall all over the place? They should have catched such a regression.

I reported this last year https://bugs.openjdk.org/browse/JDK-8344603 and the runtime triaged and assigned it to you @tstuefe . But I guess something fell through the cracks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2623810180

From aboldtch at openjdk.org  Thu Jan 30 08:35:53 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 30 Jan 2025 08:35:53 GMT
Subject: RFR: 8347564: ZGC: Crash in
 DependencyContext::clean_unloading_dependents
In-Reply-To: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
References: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
Message-ID: <HjNyHno2LP2jlAj_B24yCUToMQecc1uXfiKjuJWkQV0=.7c0147bb-36b9-4231-8cb5-27f5ed63f528@github.com>

On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The proposed change here is the following:
>  1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object
>  2. Remove the Context object and its corresponding cleaner
> 
> (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose.
> 
> First what goes wrong without this patch.
> 
> Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. 
> 
> For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. 
> 
> The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection.
> 
> If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection  would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. 
> 
> For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ...

Ran tier1 through tier8 with G1 and the guarantee that the dependency list is empty, and it is indeed the case. 
Thanks for all the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23194#issuecomment-2623840786

From aboldtch at openjdk.org  Thu Jan 30 08:35:54 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 30 Jan 2025 08:35:54 GMT
Subject: Integrated: 8347564: ZGC: Crash in
 DependencyContext::clean_unloading_dependents
In-Reply-To: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
References: <rt-jfKa-walf0P8ZrdQYQvZwTf7S9wE26_--fEQVC2Y=.9aba3fc8-47a0-4f77-967d-89d22e65a2b6@github.com>
Message-ID: <owsFYiVg5_OC_keOWc2VItG5fXW_Dr72kZiN1UknvZk=.b9d05d8d-6671-4447-99ed-033b157a483b@github.com>

On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The proposed change here is the following:
>  1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object
>  2. Remove the Context object and its corresponding cleaner
> 
> (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose.
> 
> First what goes wrong without this patch.
> 
> Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. 
> 
> For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. 
> 
> The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection.
> 
> If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection  would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. 
> 
> For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ...

This pull request has now been integrated.

Changeset: 14136f8b
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14136f8b1106137317393bc2ab0a2db0d212f8d8
Stats:     168 lines in 13 files changed: 8 ins; 143 del; 17 mod

8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents

Reviewed-by: eosterlund, stefank, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/23194

From cnorrbin at openjdk.org  Thu Jan 30 09:09:53 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 30 Jan 2025 09:09:53 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v19]
In-Reply-To: <f2dV9-ZK_4uRkJvVrUB650vmyuwHyGKL_m_8y_KgAw0=.20423d89-38ca-44e5-b5e3-1d7e8a2637b7@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <f2dV9-ZK_4uRkJvVrUB650vmyuwHyGKL_m_8y_KgAw0=.20423d89-38ca-44e5-b5e3-1d7e8a2637b7@github.com>
Message-ID: <QvttMbVUwxFQo6xGwnBnkamLiifWh8dRpkywuVwUiKw=.9aa34e69-373f-4399-913f-1852535bb908@github.com>

On Wed, 29 Jan 2025 10:11:36 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   axel feedback

Thank you everyone for taking the time to review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2623908630

From duke at openjdk.org  Thu Jan 30 09:09:54 2025
From: duke at openjdk.org (duke)
Date: Thu, 30 Jan 2025 09:09:54 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v19]
In-Reply-To: <f2dV9-ZK_4uRkJvVrUB650vmyuwHyGKL_m_8y_KgAw0=.20423d89-38ca-44e5-b5e3-1d7e8a2637b7@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <f2dV9-ZK_4uRkJvVrUB650vmyuwHyGKL_m_8y_KgAw0=.20423d89-38ca-44e5-b5e3-1d7e8a2637b7@github.com>
Message-ID: <XKMV9F65BDgfysFH5fpUlAEjeOiRDoCf0LYFrJAK5v0=.7183177c-3f0b-4993-81bf-3108c38fcc48@github.com>

On Wed, 29 Jan 2025 10:11:36 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   axel feedback

@caspernorrbin 
Your change (at version d4d60fff0bb217c1dfef890d6785f12e563990c5) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2623910028

From azafari at openjdk.org  Thu Jan 30 09:42:56 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Jan 2025 09:42:56 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v18]
In-Reply-To: <c2dmuzlHlglQS39N3OzfdA3U0ioO3x5MlOuxazBZ4NY=.6a98366f-ce3e-4536-92e6-68581ecd201d@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <ls3qbbPjOKZ6hxxj-MKQJhLofyhIYfQM5IWbTY5ZOJY=.15bd8fbe-849e-4392-9496-faae9b76e4d7@github.com>
 <c2dmuzlHlglQS39N3OzfdA3U0ioO3x5MlOuxazBZ4NY=.6a98366f-ce3e-4536-92e6-68581ecd201d@github.com>
Message-ID: <ZQ_usFs0RGqvqfdqz-9X6azkPzEQpsldwzju9AdTSPs=.7cd5ab21-7245-4d8e-8f36-a1ce67be3406@github.com>

On Wed, 29 Jan 2025 16:57:09 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge with the new lock mechanism for NMT
>
> src/hotspot/os/windows/os_windows.cpp line 3642:
> 
>> 3640:       log_warning(os)("bad release: [" PTR_FORMAT "-" PTR_FORMAT "): %s", p2i(start), p2i(end), err);
>> 3641: #ifdef ASSERT
>> 3642:       os::print_memory_mappings((char*)start, bytes, tty);
> 
> I think this will cause lock rank conflicts if you leave it in.  Please see [here](https://github.com/openjdk/jdk/pull/22745#discussion_r1890345578) and [here](https://github.com/openjdk/jdk/pull/22745#discussion_r1894197615) for more context.

Thanks. This is a mistake during merge, no intention to write so. Removed to look like the PR you referred.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1935298542

From stefank at openjdk.org  Thu Jan 30 09:47:49 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 30 Jan 2025 09:47:49 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures [v2]
In-Reply-To: <3rvoe3fw-Qv2tyGwomaDxy2hNzfoaZuj4wUdgQzi5hM=.f8522d94-df2b-44a0-8a7f-503e7b19ce71@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
 <3rvoe3fw-Qv2tyGwomaDxy2hNzfoaZuj4wUdgQzi5hM=.f8522d94-df2b-44a0-8a7f-503e7b19ce71@github.com>
Message-ID: <ygBYzruPYYStAXzh04cAxGbbPp1pkSni9XGSb5IECno=.e08993c6-7b19-412b-b3e8-e0fa6a841d83@github.com>

On Mon, 27 Jan 2025 18:19:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The code path that we use to reserve memory is generic and used by various paths in the JVM, but we log messages about failures to reserve large pages on the 'gc, heap, coops' tag set. This is confusing, so I propose to log this on 'os, map' instead. We already use that tag set to log memory reservation, so I think that's a decent tag set to use.
>> 
>> While doing this change I also added some extra info about the area that we tried to reserve and commit.
>> 
>> A couple of G1 tests had to be tweaked.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update memoryReserver.cpp

So, at one point it was consistent but then that deteriorated and we started to log to gc+heap+oops for things that are not related to the heap or the compressed oops. 

If anyone has an opinion about this logging then please participate in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23297#issuecomment-2623995304

From epeter at openjdk.org  Thu Jan 30 10:01:52 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 Jan 2025 10:01:52 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v14]
In-Reply-To: <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <NAy6q0P-B2RugBQiH57jMl0rjmgfmQj_eCarVrpfgiE=.ec5748f5-b455-401c-a4c8-c0198498c6a5@github.com>
 <a8fHXpvLDSBkJHZznAG6q3F7ElQlSZmw3ij0tg0aklY=.c78c1da8-9067-4d5f-b9c4-d21f10e34900@github.com>
 <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com>
Message-ID: <DwcfNCNlfTAYC0tFjs_u00fM46buINM_-z0m-ZDO74E=.5ef2c989-cd7c-4260-9fb4-19fdbcc3535f@github.com>

On Wed, 29 Jan 2025 06:23:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Some more minor comments below. Rest of the PR looks good to me.
>
> Hi @sviswa7 , your comments have been addressed.

The updates look good, thanks @jatin-bhateja !

Running one more round of testing to verify copyright etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2624028178

From shade at openjdk.org  Thu Jan 30 10:49:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Jan 2025 10:49:47 GMT
Subject: RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
In-Reply-To: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
References: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
Message-ID: <Dcl7fdefN2Xu64O9ZLS2VEzg_P1UaaNe9mtz6twpz6I=.bee6219f-5a69-4571-91c9-5c365935b9b4@github.com>

On Tue, 28 Jan 2025 14:01:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We run into peculiar problem in Leyden: due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. The code buffer expansion routinely happens with late G1 barrier expansion, as `G1BarrierSetC2` does not report any estimate for stub sizes.
> 
> So a method rich in these G1 stubs would blow the initial code size estimate, force the buffer resize, and thus disqualify itself from storing C2 code in Leyden. Whoops. Fortunately, we just need to implement `G1BarrierSetC2::estimate_stub_size()` in mainline to avoid a significant part of this problem. 
> 
> I also fixed the misattribution of "stub" sizes in insn section, this part is also important to get the stub sizes right. I can do that separately, but it would only matter for ZGC without G1 stub size estimation implemented.
> 
> You can see the impact it has on Leyden here:
> https://github.com/openjdk/leyden/pull/28#issuecomment-2619077625
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

On hold.

Testing more Leyden stuff, I realized there is a major problem with this patch. The `estimate_stub_size` is called when the initial buffer is created. But C2 G1 stubs are not generated at that point, because they would only emerge once Matcher starts to work through the instructions code. So I think the effect we are seeing on Leyden is due to addition of `MAX_insn_size` slop to stub size estimate. The compute stub size is very often just zero. 

It looks to me  `BarrierSetC2::estimate_stub_size` itself is kinda useless.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23333#issuecomment-2624140301

From stuefe at openjdk.org  Thu Jan 30 10:49:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Jan 2025 10:49:48 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <aCuS8RIwBMgkf7DIEvEN6zKYjRpE4XtAlAf655N76q0=.63376c4a-8993-4739-8481-2c945ece8027@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <aCuS8RIwBMgkf7DIEvEN6zKYjRpE4XtAlAf655N76q0=.63376c4a-8993-4739-8481-2c945ece8027@github.com>
Message-ID: <ftFmghmoTK2vF9L4Ie4k4dC4O-EpSXkKoJEhhY9PAq4=.23fbb0c9-48c8-4adb-8c1b-73ef388e8742@github.com>

On Thu, 30 Jan 2025 07:25:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this trivial change that improves output readability.
>
> I don't understand, where did we break this? Did I break this with [8333994](https://github.com/openjdk/jdk/pull/19655/files#top)?
> 
> If so, why did NMT tests not fall all over the place? They should have catched such a regression.

> I reported this last year https://bugs.openjdk.org/browse/JDK-8344603 and the runtime triaged and assigned it to you @tstuefe . But I guess something fell through the cracks.

Oh, I missed that one completely :-( No, you are right, that is a bug that needs fixing. Weird that it only shows up at some output lines. @zhengyu123 by adding a single cr, looking at https://bugs.openjdk.org/browse/JDK-8344603, would we not now show multiple newlines in some places?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2624139021

From jbhateja at openjdk.org  Thu Jan 30 11:03:43 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 30 Jan 2025 11:03:43 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v16]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <EC2coajO2bsqpsjUFgjuf-YXj23ENZeLj2ABtq4Sd74=.1e290b04-fcfc-4aaa-b80d-60cdbb0a529a@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Update test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java
  
  Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/19fc6c2d..8207c9ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From epeter at openjdk.org  Thu Jan 30 11:03:45 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 Jan 2025 11:03:45 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v15]
In-Reply-To: <x30I_C4V5Tj8Kp1J3hOm-8-M20obWZuoR-i3dfwXN1U=.33dc854b-4631-4c2e-ac4e-38b832e60f53@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <x30I_C4V5Tj8Kp1J3hOm-8-M20obWZuoR-i3dfwXN1U=.33dc854b-4631-4c2e-ac4e-38b832e60f53@github.com>
Message-ID: <RVk9eWq6JPrjacWkdvmI3nStAB_V6ZjXdCBbS275WkY=.81961f83-b6fe-49fc-a098-50cf8e75b8c4@github.com>

On Wed, 29 Jan 2025 06:26:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing a typo error

`[2025-01-30T10:01:50,247Z] BAD COPYRIGHT: ...test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java`

There is yet another `vector` that snuck in later:


19c19
<  * Please contact Oracle, 500 Oracle Parkway, Redwood ShovectorRes, CA 94065 USA
---
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA

test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 19:

> 17:  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> 18:  *
> 19:  * Please contact Oracle, 500 Oracle Parkway, Redwood ShovectorRes, CA 94065 USA

Suggestion:

 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2624164650
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1935412209

From epeter at openjdk.org  Thu Jan 30 11:08:55 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 30 Jan 2025 11:08:55 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v14]
In-Reply-To: <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <NAy6q0P-B2RugBQiH57jMl0rjmgfmQj_eCarVrpfgiE=.ec5748f5-b455-401c-a4c8-c0198498c6a5@github.com>
 <a8fHXpvLDSBkJHZznAG6q3F7ElQlSZmw3ij0tg0aklY=.c78c1da8-9067-4d5f-b9c4-d21f10e34900@github.com>
 <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com>
Message-ID: <cv1BmytLxAu6wh3wfYQCcK_EpRNe6_YUvXEq_zq927w=.46de6ca6-d3a2-4074-9d5f-9dcf847d6055@github.com>

On Wed, 29 Jan 2025 06:23:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Some more minor comments below. Rest of the PR looks good to me.
>
> Hi @sviswa7 , your comments have been addressed.

@jatin-bhateja Launched testing again ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2624183368

From azafari at openjdk.org  Thu Jan 30 11:30:39 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Jan 2025 11:30:39 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v19]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <djMbcqXrWtXmzrU-6IypdvOvJAgq-YM5xwdak9FKerg=.371fb937-b64d-42f0-b05d-d8ddacb472c9@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:

 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - merge with the new lock mechanism for NMT
 - merge with master
 - one small fix for SSIZE_FORMAT
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - undo overlapping checks.
 - size_t format fixed.
 - fix for debug prints
 - added overlap checks.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - ... and 54 more: https://git.openjdk.org/jdk/compare/fb0f2d25...c0670b64

-------------

Changes: https://git.openjdk.org/jdk/pull/20425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=18
  Stats: 3388 lines in 50 files changed: 1535 ins; 1583 del; 270 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 adinn at openjdk.org  Thu Jan 30 11:49:57 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 30 Jan 2025 11:49:57 GMT
Subject: Integrated: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations
In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
Message-ID: <m6K06tRk8Cpi1y4uWEdlXKLOZlHSN9hML9n_2V9yosU=.94e28f80-9bc2-4a5c-aad5-d5631ad86774@github.com>

On Thu, 7 Nov 2024 14:54:32 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Implementation of JDK-8343767

This pull request has now been integrated.

Changeset: a937f6db
Author:    Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a937f6db30ab55b98dae25d5b6d041cf4b7b7291
Stats:     7098 lines in 57 files changed: 4053 ins; 1642 del; 1403 mod

8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations

Reviewed-by: vlivanov, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/21957

From shade at openjdk.org  Thu Jan 30 11:58:04 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Jan 2025 11:58:04 GMT
Subject: RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
 [v2]
In-Reply-To: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
References: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
Message-ID: <X72PzFC3lFrjPOBYkK4-yf54BpTv4ZB9IOXO_XyEf7U=.aeb576ae-870a-44de-aab8-cfd495bc6984@github.com>

> We run into peculiar problem in Leyden: due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. The code buffer expansion routinely happens with late G1 barrier expansion, as `G1BarrierSetC2` does not report any estimate for stub sizes.
> 
> So a method rich in these G1 stubs would blow the initial code size estimate, force the buffer resize, and thus disqualify itself from storing C2 code in Leyden. Whoops. Fortunately, we just need to implement `G1BarrierSetC2::estimate_stub_size()` in mainline to avoid a significant part of this problem. 
> 
> I also fixed the misattribution of "stub" sizes in insn section, this part is also important to get the stub sizes right. I can do that separately, but it would only matter for ZGC without G1 stub size estimation implemented.
> 
> You can see the impact it has on Leyden here:
> https://github.com/openjdk/leyden/pull/28#issuecomment-2619077625
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Revert Leyden-specific additions, plainly estimate the stubs size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23333/files
  - new: https://git.openjdk.org/jdk/pull/23333/files/bec7c5c1..41950b7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23333&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23333&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23333.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23333/head:pull/23333

PR: https://git.openjdk.org/jdk/pull/23333

From ayang at openjdk.org  Thu Jan 30 12:18:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Jan 2025 12:18:55 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring memory
 leading to OOME
Message-ID: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>

Here is an attempt to simplify GCLocker implementation for Serial and Parallel.

GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.

The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.

Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.

Test: tier1-8

-------------

Commit messages:
 - gclocker

Changes: https://git.openjdk.org/jdk/pull/23367/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8192647
  Stats: 936 lines in 37 files changed: 36 ins; 804 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/23367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23367/head:pull/23367

PR: https://git.openjdk.org/jdk/pull/23367

From cnorrbin at openjdk.org  Thu Jan 30 12:37:00 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 30 Jan 2025 12:37:00 GMT
Subject: Integrated: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a
 utility data structure
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <tjlz-x0RJiBjsbsMSWi_ayblbwH5A-M5fkmBrIJAH3w=.47162cca-0296-4008-9f9f-39b1ae1e483a@github.com>

On Mon, 25 Nov 2024 13:11:52 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

This pull request has now been integrated.

Changeset: 2efb6aaa
Author:    Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2efb6aaadb0df50b5cc4b2495d988802f9dbff50
Stats:     1455 lines in 3 files changed: 1455 ins; 0 del; 0 mod

8345314: Add a red?black tree as a utility data structure

Reviewed-by: aboldtch, jsjolen, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/22360

From fyang at openjdk.org  Thu Jan 30 12:53:58 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 30 Jan 2025 12:53:58 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <2-Cadd8Ra9OJBUfrsJZdnKk7EgPEZ-LFoA_XM-dr1aY=.cdd26dce-de81-4973-bd30-550469676567@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
 <14uBUhX_V0bQgetjK4ojSYJeJYRcM1jBMV60Hk8VaRQ=.5b5144d6-c077-4e15-b9a7-7a25858bbfd8@github.com>
 <2-Cadd8Ra9OJBUfrsJZdnKk7EgPEZ-LFoA_XM-dr1aY=.cdd26dce-de81-4973-bd30-550469676567@github.com>
Message-ID: <nQwJev1P0RcrpXHw-8JGVckcP8oPGfAG8phu51tD0Bs=.6e44a5ed-83e3-491a-a32b-3fe7e59d0a03@github.com>

On Wed, 29 Jan 2025 17:21:17 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> I see compiler/arguments/TestCodeEntryAlignment.java failures on x64.
>> 
>> 
>> #  Internal Error (.../src/hotspot/share/asm/codeBuffer.hpp:200), pid=1218011, tid=1218066
>> #  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007f52b412a000 <= 0x00007f52b413e141 <= 0x00007f52b413e140
>> 
>> Command Line: -XX:+UnlockExperimentalVMOptions -XX:CodeCacheSegmentSize=1024 -XX:CodeEntryAlignment=1024 compiler.arguments.TestCodeEntryAlignment run
>> 
>> Current thread (0x00007f52c422b220):  JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=1218066, stack(0x00007f52a4f9b000,0x00007f52a509b000) (1024K)]
>> 
>> V  [libjvm.so+0x68c7b0]  Assembler::vmovdqu(Address, XMMRegister)+0x250  (codeBuffer.hpp:200)
>> V  [libjvm.so+0x1390ed3]  MacroAssembler::vmovdqu(Address, XMMRegister)+0x73  (macroAssembler_x86.cpp:2663)
>> V  [libjvm.so+0x176f4d5]  StubGenerator::generate_base64_encodeBlock()+0x955  (stubGenerator_x86_64.cpp:2081)
>> V  [libjvm.so+0x1777c7d]  StubGenerator::generate_compiler_stubs()+0x5cd  (stubGenerator_x86_64.cpp:4296)
>> V  [libjvm.so+0x17795e8]  StubGenerator_generate(CodeBuffer*, StubGenBlobId)+0xe8  (stubGenerator_x86_64.cpp:4421)
>> V  [libjvm.so+0x17d2ff8]  initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*) [clone .constprop.0]+0xe8  (stubRoutines.cpp:233)
>> V  [libjvm.so+0x17d55fc]  compiler_stubs_init(bool)+0x9c  (stubRoutines.cpp:264)
>> ...
>
> @iwanowww @TheRealMDoerr The x86 failure happens when the test sets code cache segment size and alignment both to 1024. There are so many stubs in the compiler blob on x86_64 that this requires an extra 8000 bytes to be added to the current blob size. The slop for this case is only 900 bytes but the test is a fairly unrealistic scenario. With both values set to 512 we have over 13000 bytes of slop. So, I think I have added enough for realistic purposes.

@adinn : Witnessed build errors after this change. Seems that this PR needs rebase before merging. It's strange that the bot didn't catch the merge conflicts in files like `src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp` or `src/hotspot/cpu/riscv/stubGenerator_riscv.cpp`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2624430632

From azafari at openjdk.org  Thu Jan 30 12:55:35 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Jan 2025 12:55:35 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v20]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <L4yFoBPU9oMDmk0pcmA6nlF1kNTkeS_k43xcOlTnENk=.6e796b22-6ca5-47a5-a0f3-20ecc4fa7641@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  fix in shendoahCardTable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/c0670b64..a0d133f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=18-19

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 eastigeevich at openjdk.org  Thu Jan 30 13:41:48 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 30 Jan 2025 13:41:48 GMT
Subject: RFR: 8321529: log_on_large_pages_failure reports log_debug(gc,
 heap, coops) for ReservedCodeSpace failures [v2]
In-Reply-To: <kQ_gF-5pbuIxVWxBDsVCnt0em0h3cy3JsuaDG2RRhWk=.c511a9d6-bf29-434a-876d-e2f95de345d5@github.com>
References: <dIUMem2TPD_KDqr-cWWrbaMwVvIdfje2COBo6j3NXnw=.3d969c58-def6-4c6a-8ca6-a34adff0ac3b@github.com>
 <3rvoe3fw-Qv2tyGwomaDxy2hNzfoaZuj4wUdgQzi5hM=.f8522d94-df2b-44a0-8a7f-503e7b19ce71@github.com>
 <kQ_gF-5pbuIxVWxBDsVCnt0em0h3cy3JsuaDG2RRhWk=.c511a9d6-bf29-434a-876d-e2f95de345d5@github.com>
Message-ID: <ncMqG9WsqFWgHKOds3IdQQrZnLug3bwwfUE6OAFYiec=.8a828962-acaf-47c4-8f22-7b424cdc1e14@github.com>

On Thu, 30 Jan 2025 02:47:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update memoryReserver.cpp
>
> In the context of where this code was originally added ([JDK-8265268](https://bugs.openjdk.org/browse/JDK-8265268)), in `virtualSpace.cpp` the use of `log_debug(gc, heap, coops)` was consistent with, and formed part of the tracing for, all the memory logging in that code. I don't disagree that you might want to more generically enable this logging, but it will now be missing from that established logging path. It doesn't affect me either way, but people who use that logging may have a stronger opinion.

Hi @dholmes-ora,

Looking into the history, I found the code was added in the context of [JDK-8152896](https://bugs.openjdk.org/browse/JDK-8152896).

The original logging was:
```c++
void ReservedSpace::initialize(size_t size, size_t alignment, bool large,
                               char* requested_address,
                               bool executable) {
...
      // failed; try to reserve regular memory below
      if (UseLargePages && (!FLAG_IS_DEFAULT(UseLargePages) ||
                            !FLAG_IS_DEFAULT(LargePageSizeInBytes))) {
        if (PrintCompressedOopsMode) {
          tty->cr();
          tty->print_cr("Reserve regular memory without large pages.");
        }
      }


It was added by the fix of [JDK-6947341](https://bugs.openjdk.org/browse/JDK-6947341).
The logging was intended for the Java heap.
IMO, the code is missing a check of `executable` not to print the message for CodeCache.

To get functionality close to the original and not to print the message for CodeCache we can do:
```c++
63: static void log_on_large_pages_failure(char* req_addr, size_t bytes, bool executable) {
  if (large_pages_requested()) {
    if (executable) {
      log_debug(codecache)("Reserve regular memory without large pages "
                         RANGEFMT, RANGEFMTARGS(req_addr, bytes));
    } else {
      log_debug(gc, heap, coops)("Reserve regular memory without large pages "
                         RANGEFMT, RANGEFMTARGS(req_addr, bytes));
    }
    // JVM style warning that we did not succeed in using large pages.
    char msg[128];
    jio_snprintf(msg, sizeof(msg), "Failed to reserve and commit memory using large pages. "
                                   "req_addr: " PTR_FORMAT " bytes: %zu",
                                   req_addr, bytes);
    warning("%s", msg);
  }

188: log_on_large_pages_failure(requested_address, size, executable);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23297#issuecomment-2624545576

From zgu at openjdk.org  Thu Jan 30 13:42:48 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 30 Jan 2025 13:42:48 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <ftFmghmoTK2vF9L4Ie4k4dC4O-EpSXkKoJEhhY9PAq4=.23fbb0c9-48c8-4adb-8c1b-73ef388e8742@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <aCuS8RIwBMgkf7DIEvEN6zKYjRpE4XtAlAf655N76q0=.63376c4a-8993-4739-8481-2c945ece8027@github.com>
 <ftFmghmoTK2vF9L4Ie4k4dC4O-EpSXkKoJEhhY9PAq4=.23fbb0c9-48c8-4adb-8c1b-73ef388e8742@github.com>
Message-ID: <sLPdzC4Xn9hYbkOhEWGrlskKMIIa13yy6fnVhJ4drlk=.3a4a6c9e-72ce-464e-a808-66919036715f@github.com>

On Thu, 30 Jan 2025 10:46:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I reported this last year https://bugs.openjdk.org/browse/JDK-8344603 and the runtime triaged and assigned it to you @tstuefe . But I guess something fell through the cracks.
> 
> Oh, I missed that one completely :-( No, you are right, that is a bug that needs fixing. Weird that it only shows up at some output lines. @zhengyu123 by adding a single cr, looking at https://bugs.openjdk.org/browse/JDK-8344603, would we not now show multiple newlines in some places?

  Now you use `NativeCallStackPrinter::print_stack()` for NMT reporting and it does line break [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/nmt/nativeCallStackPrinter.cpp#L52)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2624547890

From adinn at openjdk.org  Thu Jan 30 13:48:58 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 30 Jan 2025 13:48:58 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <nQwJev1P0RcrpXHw-8JGVckcP8oPGfAG8phu51tD0Bs=.6e44a5ed-83e3-491a-a32b-3fe7e59d0a03@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
 <14uBUhX_V0bQgetjK4ojSYJeJYRcM1jBMV60Hk8VaRQ=.5b5144d6-c077-4e15-b9a7-7a25858bbfd8@github.com>
 <2-Cadd8Ra9OJBUfrsJZdnKk7EgPEZ-LFoA_XM-dr1aY=.cdd26dce-de81-4973-bd30-550469676567@github.com>
 <nQwJev1P0RcrpXHw-8JGVckcP8oPGfAG8phu51tD0Bs=.6e44a5ed-83e3-491a-a32b-3fe7e59d0a03@github.com>
Message-ID: <hDkBKXnyiyDqtay2txsm-dwLcT4mcnxTbUNKs-SQeUA=.400a5764-f2a9-4532-880b-c22bd626737d@github.com>

On Thu, 30 Jan 2025 12:50:29 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> @iwanowww @TheRealMDoerr The x86 failure happens when the test sets code cache segment size and alignment both to 1024. There are so many stubs in the compiler blob on x86_64 that this requires an extra 8000 bytes to be added to the current blob size. The slop for this case is only 900 bytes but the test is a fairly unrealistic scenario. With both values set to 512 we have over 13000 bytes of slop. So, I think I have added enough for realistic purposes.
>
> @adinn : Witnessed build errors after this change. Seems that this PR needs rebase before merging. It's strange that the bot didn't catch the merge conflicts in files like `src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp` or `src/hotspot/cpu/riscv/stubGenerator_riscv.cpp`.

@RealFYang Thanks for notifying this do quickly. I'm not sure how the bots didn't catch this either. Most of the conflicts were in copyright headers so would not be caught by the testing. There were two unresolved merge conflicts in the ppc and riscv code which also crept in and were not detected by github actions.

I have opened [JDK-8349070](https://bugs.openjdk.org/browse/JDK-8349070) and will push a PR to fix it asap.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2624549335

From mdoerr at openjdk.org  Thu Jan 30 13:49:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Jan 2025 13:49:02 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v14]
In-Reply-To: <2NESd0o8NjT6F7Q3CYKiM7WYRx8cvNW3LgeL4Jt3Rl4=.ea23dd39-11d5-4921-8543-593808cd79e0@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <2NESd0o8NjT6F7Q3CYKiM7WYRx8cvNW3LgeL4Jt3Rl4=.ea23dd39-11d5-4921-8543-593808cd79e0@github.com>
Message-ID: <mXDb4T6U-IjTmykok-bYzUwl6KTvML2FPW4uBgDrBsk=.e1a3f5ad-26a0-47e7-8536-f4e183379519@github.com>

On Wed, 29 Jan 2025 17:18:37 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits:
> 
>  - bump up compiler blob size to allow for large code cache segment/alignment sizes
>  - merge
>  - update copyrights
>  - remove unreferenced local var
>  - allow repeated entries rather than stubs
>  - correct error in stub routines fill test
>  - remove unused ppc stub
>  - fix errors in s390 arraycopy code
>  - correct errors in stubgen blob sizes
>  - merge
>  - ... and 58 more: https://git.openjdk.org/jdk/compare/51cce6e6...cc85c18a

PPC64 build is also broken:
stubGenerator_ppc.cpp:4602:1: error: version control conflict marker in file

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2624555165

From adinn at openjdk.org  Thu Jan 30 13:49:02 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 30 Jan 2025 13:49:02 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v14]
In-Reply-To: <mXDb4T6U-IjTmykok-bYzUwl6KTvML2FPW4uBgDrBsk=.e1a3f5ad-26a0-47e7-8536-f4e183379519@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <2NESd0o8NjT6F7Q3CYKiM7WYRx8cvNW3LgeL4Jt3Rl4=.ea23dd39-11d5-4921-8543-593808cd79e0@github.com>
 <mXDb4T6U-IjTmykok-bYzUwl6KTvML2FPW4uBgDrBsk=.e1a3f5ad-26a0-47e7-8536-f4e183379519@github.com>
Message-ID: <IQV-QAEvjKYYacNHgd69MNRUyIu7nlAVJ0VzMnBgR_A=.9d5d6c7d-f458-40d2-bd21-eeb03bb1b5ac@github.com>

On Thu, 30 Jan 2025 13:43:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits:
>> 
>>  - bump up compiler blob size to allow for large code cache segment/alignment sizes
>>  - merge
>>  - update copyrights
>>  - remove unreferenced local var
>>  - allow repeated entries rather than stubs
>>  - correct error in stub routines fill test
>>  - remove unused ppc stub
>>  - fix errors in s390 arraycopy code
>>  - correct errors in stubgen blob sizes
>>  - merge
>>  - ... and 58 more: https://git.openjdk.org/jdk/compare/51cce6e6...cc85c18a
>
> PPC64 build is also broken:
> stubGenerator_ppc.cpp:4602:1: error: version control conflict marker in file

@TheRealMDoerr Yes, I also spotted that thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2624562982

From mdoerr at openjdk.org  Thu Jan 30 13:59:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Jan 2025 13:59:51 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters [v2]
In-Reply-To: <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
 <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>
Message-ID: <u22ZEqlFawsy-vDmtIpkemPPjk5-tBEs0KQM2m9aqxY=.69304507-4703-4cbd-93b2-b191894f37ab@github.com>

On Tue, 28 Jan 2025 11:58:00 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

>> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
>> 
>> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)
>
> Sorna Sarathi N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the copyright header years for the edited files

Thanks for cleaning this up! LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23325#pullrequestreview-2583984594

From adinn at openjdk.org  Thu Jan 30 14:02:11 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 30 Jan 2025 14:02:11 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v13]
In-Reply-To: <nQwJev1P0RcrpXHw-8JGVckcP8oPGfAG8phu51tD0Bs=.6e44a5ed-83e3-491a-a32b-3fe7e59d0a03@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <7_qpH8rYuo_3B5J0y06Fa6pu1IxiWwyAeV5sNrqj9gE=.c16a8b2f-2abd-49ec-b85a-b1d7a80b5412@github.com>
 <14uBUhX_V0bQgetjK4ojSYJeJYRcM1jBMV60Hk8VaRQ=.5b5144d6-c077-4e15-b9a7-7a25858bbfd8@github.com>
 <2-Cadd8Ra9OJBUfrsJZdnKk7EgPEZ-LFoA_XM-dr1aY=.cdd26dce-de81-4973-bd30-550469676567@github.com>
 <nQwJev1P0RcrpXHw-8JGVckcP8oPGfAG8phu51tD0Bs=.6e44a5ed-83e3-491a-a32b-3fe7e59d0a03@github.com>
Message-ID: <aJl5zuET2DplAajUTaC4EWoSeTMl1ZwRJDsAFCo0Is8=.49d0a88b-7221-471e-ae25-d6ae0d50cb2b@github.com>

On Thu, 30 Jan 2025 12:50:29 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> @iwanowww @TheRealMDoerr The x86 failure happens when the test sets code cache segment size and alignment both to 1024. There are so many stubs in the compiler blob on x86_64 that this requires an extra 8000 bytes to be added to the current blob size. The slop for this case is only 900 bytes but the test is a fairly unrealistic scenario. With both values set to 512 we have over 13000 bytes of slop. So, I think I have added enough for realistic purposes.
>
> @adinn : Witnessed build errors after this change. Seems that this PR needs rebase before merging. It's strange that the bot didn't catch the merge conflicts in files like `src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp` or `src/hotspot/cpu/riscv/stubGenerator_riscv.cpp`.

@RealFYang @TheRealMDoerr
Please verify fix prepared in [PR 23368](https://github.com/openjdk/jdk/pull/23368) on riscv/ppc. GHA for the pR should also confirm it is ok.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2624591895

From mdoerr at openjdk.org  Thu Jan 30 14:03:58 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Jan 2025 14:03:58 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters
In-Reply-To: <EkXatJZJLBKMKedIQG_BtgWU8j4za31nDoO6oRHkLl8=.48769d0a-2730-46b3-b1fd-68c72c1ebc82@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
 <EkXatJZJLBKMKedIQG_BtgWU8j4za31nDoO6oRHkLl8=.48769d0a-2730-46b3-b1fd-68c72c1ebc82@github.com>
Message-ID: <sh_CidCyHycW2LF0Hn8XZhxnACJI4YGpGQMNYMxDp58=.66e2fec3-1ae4-401e-a81d-99ed6e94bd57@github.com>

On Tue, 28 Jan 2025 09:19:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I understand the motivation, but maybe the reason this was never done before is that it will make back-porting fixes harder. They will never apply cleanly to old versions, and will all have to be adjusted manually.

Right. The number of assembler code backports seems to be not that high. I think JDK25 is a good release to clean this up.

Please note that the PR needs a git merge.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23325#issuecomment-2624598272

From zgu at openjdk.org  Thu Jan 30 14:15:33 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 30 Jan 2025 14:15:33 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
 [v2]
In-Reply-To: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
Message-ID: <HTAfVXPDgP8JJ6-MOj49KX5y3ScqOe2SByBNELHd1zg=.61d90a0e-812f-428a-80d1-422573d30759@github.com>

> Please review this trivial change that improves output readability.

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  David's comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23359/files
  - new: https://git.openjdk.org/jdk/pull/23359/files/2cd05aea..4467820a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23359&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23359&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23359.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23359/head:pull/23359

PR: https://git.openjdk.org/jdk/pull/23359

From stuefe at openjdk.org  Thu Jan 30 14:15:33 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Jan 2025 14:15:33 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
Message-ID: <fpOiijBj1rno1NGH1HXeiZMEtIjO7TAPXgbeX9BTdGo=.40ceb39d-9ae6-4084-bae6-8228c820a685@github.com>

On Wed, 29 Jan 2025 22:00:08 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial change that improves output readability.

Ah, now I remember.

I introduced the `NativeCallStackPrinter` for when you need to print many stacks (e.g. in NMT reporting) and want to have source output. Since reading ELF files is costly and can significantly slow down printing, I now cache retrieved source information by PC. That cache needs a lifetime, hence the `NativeCallStackPrinter`. The CR was removed from `NativeCallStack::print_frame`, since in case of the `NativeCallStackPrinter`, the text may be succeeded by source file info that has to appear on the same line.

So we have two call chains: 
1 `NativeCallStackPrinter::print_stack()` -> `NativeCallStack::print_frame()`, after which source file info is printed, after which CR is added
2 `NativeCallStack::print_stack()` -> `NativeCallStack::print_frame()` which now misses the CR

I think the patch is okay. But I wonder whether we should use, up in the NMT reporter code, an instance of `NativeCallStackPrinter` instead. Since we do this many times and it may also benefit from sped-up source lookup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2624625670

From zgu at openjdk.org  Thu Jan 30 14:15:33 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 30 Jan 2025 14:15:33 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
 [v2]
In-Reply-To: <Ra1nEYRZH2gCWlg7KagLb8PJ5huiYhIsIBImBhhYT7U=.2c706a97-51c8-4861-b963-bcd16005ad74@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <Ra1nEYRZH2gCWlg7KagLb8PJ5huiYhIsIBImBhhYT7U=.2c706a97-51c8-4861-b963-bcd16005ad74@github.com>
Message-ID: <7ewiu2vEs8UF2IIyPVRp1Ot6cw6AdalfODPA9_i4f6c=.d034f227-cf6f-41f1-9472-c5b40a2f1283@github.com>

On Thu, 30 Jan 2025 06:35:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   David's comment
>
> src/hotspot/share/utilities/nativeCallStack.cpp line 118:
> 
>> 116:     out->cr();
>> 117:   }
>> 118:   out->cr();
> 
> Do you need the `cr()` after the loop now? Guess it is a matter of personal preference depending on the context in which this gets printed.

Good point. Let's restore to pre [JDK-8333994](https://bugs.openjdk.org/browse/JDK-8333994) behavior, where it does not have `cr()` after the loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23359#discussion_r1935678731

From stuefe at openjdk.org  Thu Jan 30 14:23:50 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Jan 2025 14:23:50 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
 [v2]
In-Reply-To: <HTAfVXPDgP8JJ6-MOj49KX5y3ScqOe2SByBNELHd1zg=.61d90a0e-812f-428a-80d1-422573d30759@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <HTAfVXPDgP8JJ6-MOj49KX5y3ScqOe2SByBNELHd1zg=.61d90a0e-812f-428a-80d1-422573d30759@github.com>
Message-ID: <JdKGR5itSfYREGyNdnSpT_8u8IjaWRC-_rI3ZFYXO7o=.28139073-1400-4b75-bf6b-e54141d8d057@github.com>

On Thu, 30 Jan 2025 14:15:33 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this trivial change that improves output readability.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's comment

Thanks @zhengyu123 for fixing this.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23359#pullrequestreview-2584049380

From zgu at openjdk.org  Thu Jan 30 14:30:48 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 30 Jan 2025 14:30:48 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <fpOiijBj1rno1NGH1HXeiZMEtIjO7TAPXgbeX9BTdGo=.40ceb39d-9ae6-4084-bae6-8228c820a685@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <fpOiijBj1rno1NGH1HXeiZMEtIjO7TAPXgbeX9BTdGo=.40ceb39d-9ae6-4084-bae6-8228c820a685@github.com>
Message-ID: <OAno9NlipE6-Sbd9I2hDGJG2SqW50Jqen3hQ0CfX6qw=.457161a4-48a3-47a1-a1b9-87b883f86e37@github.com>

On Thu, 30 Jan 2025 14:12:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Ah, now I remember.
> 
> I introduced the `NativeCallStackPrinter` for when you need to print many stacks (e.g. in NMT reporting) and want to have source output. Since reading ELF files is costly and can significantly slow down printing, I now cache retrieved source information by PC. That cache needs a lifetime, hence the `NativeCallStackPrinter`. The CR was removed from `NativeCallStack::print_frame`, since in case of the `NativeCallStackPrinter`, the text may be succeeded by source file info that has to appear on the same line.
> 
> So we have two call chains: 1 `NativeCallStackPrinter::print_stack()` -> `NativeCallStack::print_frame()`, after which source file info is printed, after which CR is added 2 `NativeCallStack::print_stack()` -> `NativeCallStack::print_frame()` which now misses the CR
> 
> I think the patch is okay. But I wonder whether we should use, up in the NMT reporter code, an instance of `NativeCallStackPrinter` instead. Since we do this many times and it may also benefit from sped-up source lookup.

I use `NativeCallStack` for debugging purpose a lot,  `print_on()` method is very handy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2624663798

From zgu at openjdk.org  Thu Jan 30 14:30:48 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 30 Jan 2025 14:30:48 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <OAno9NlipE6-Sbd9I2hDGJG2SqW50Jqen3hQ0CfX6qw=.457161a4-48a3-47a1-a1b9-87b883f86e37@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <fpOiijBj1rno1NGH1HXeiZMEtIjO7TAPXgbeX9BTdGo=.40ceb39d-9ae6-4084-bae6-8228c820a685@github.com>
 <OAno9NlipE6-Sbd9I2hDGJG2SqW50Jqen3hQ0CfX6qw=.457161a4-48a3-47a1-a1b9-87b883f86e37@github.com>
Message-ID: <X096n7_Yl2eSC2LrZraeb9Gai5pa_adpJs83LGIlQeE=.bc04b1de-f559-44e1-a4cb-bdd35b3cf629@github.com>

On Thu, 30 Jan 2025 14:27:44 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Ah, now I remember.
> 
> I introduced the `NativeCallStackPrinter` for when you need to print many stacks (e.g. in NMT reporting) and want to have source output. Since reading ELF files is costly and can significantly slow down printing, I now cache retrieved source information by PC. That cache needs a lifetime, hence the `NativeCallStackPrinter`. The CR was removed from `NativeCallStack::print_frame`, since in case of the `NativeCallStackPrinter`, the text may be succeeded by source file info that has to appear on the same line.
> 
> So we have two call chains: 1 `NativeCallStackPrinter::print_stack()` -> `NativeCallStack::print_frame()`, after which source file info is printed, after which CR is added 2 `NativeCallStack::print_stack()` -> `NativeCallStack::print_frame()` which now misses the CR
> 
> I think the patch is okay. But I wonder whether we should use, up in the NMT reporter code, an instance of `NativeCallStackPrinter` instead. Since we do this many times and it may also benefit from sped-up source lookup.

I use `NativeCallStack` for debugging purpose a lot,  `print_on()` method is very handy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2624664223

From stuefe at openjdk.org  Thu Jan 30 15:03:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 30 Jan 2025 15:03:51 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <X096n7_Yl2eSC2LrZraeb9Gai5pa_adpJs83LGIlQeE=.bc04b1de-f559-44e1-a4cb-bdd35b3cf629@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <fpOiijBj1rno1NGH1HXeiZMEtIjO7TAPXgbeX9BTdGo=.40ceb39d-9ae6-4084-bae6-8228c820a685@github.com>
 <OAno9NlipE6-Sbd9I2hDGJG2SqW50Jqen3hQ0CfX6qw=.457161a4-48a3-47a1-a1b9-87b883f86e37@github.com>
 <X096n7_Yl2eSC2LrZraeb9Gai5pa_adpJs83LGIlQeE=.bc04b1de-f559-44e1-a4cb-bdd35b3cf629@github.com>
Message-ID: <UbO2bXzU5CGDcPm_g7yF48mJ4iYsKKXKOxwmTUIbED0=.351a06f5-6b90-4515-b57f-08d074d9fa5f@github.com>

On Thu, 30 Jan 2025 14:27:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > Ah, now I remember.
> > I introduced the `NativeCallStackPrinter` for when you need to print many stacks (e.g. in NMT reporting) and want to have source output. Since reading ELF files is costly and can significantly slow down printing, I now cache retrieved source information by PC. That cache needs a lifetime, hence the `NativeCallStackPrinter`. The CR was removed from `NativeCallStack::print_frame`, since in case of the `NativeCallStackPrinter`, the text may be succeeded by source file info that has to appear on the same line.
> > So we have two call chains: 1 `NativeCallStackPrinter::print_stack()` -> `NativeCallStack::print_frame()`, after which source file info is printed, after which CR is added 2 `NativeCallStack::print_stack()` -> `NativeCallStack::print_frame()` which now misses the CR
> > I think the patch is okay. But I wonder whether we should use, up in the NMT reporter code, an instance of `NativeCallStackPrinter` instead. Since we do this many times and it may also benefit from sped-up source lookup.
> 
> I use `NativeCallStack` for debugging purpose a lot, `print_on()` method is very handy.

Yeah I use it too :-)

We have an open issue somewhere to make its stack depth configurable via command line, btw. But nobody got around to implement it yet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2624736408

From rrich at openjdk.org  Thu Jan 30 15:10:53 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 30 Jan 2025 15:10:53 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters [v2]
In-Reply-To: <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
 <hd_vCcaIiX2plrEKgzUvvxm4G0SavqhFJXp7Lob20lY=.3080491c-ac82-48d3-88d8-7bdda2bb080c@github.com>
Message-ID: <GnwpvZbY36xYDAHgMhbhmrTpxjeiDuP0GDX1S6fqt_k=.4d5d9089-a209-41f7-8ede-917da0d410fc@github.com>

On Tue, 28 Jan 2025 11:58:00 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

>> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
>> 
>> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)
>
> Sorna Sarathi N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the copyright header years for the edited files

Looks good!
Thanks, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23325#pullrequestreview-2584180313

From shade at openjdk.org  Thu Jan 30 15:47:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Jan 2025 15:47:05 GMT
Subject: RFR: 8348855: G1: Implement G1BarrierSetC2::estimate_stub_size
 [v2]
In-Reply-To: <X72PzFC3lFrjPOBYkK4-yf54BpTv4ZB9IOXO_XyEf7U=.aeb576ae-870a-44de-aab8-cfd495bc6984@github.com>
References: <Ou9qn7o2z_ekeRfcs5p4tKklF19elnyanUqw0aNm1nQ=.2a9627cd-fafe-4313-b641-879156fab349@github.com>
 <X72PzFC3lFrjPOBYkK4-yf54BpTv4ZB9IOXO_XyEf7U=.aeb576ae-870a-44de-aab8-cfd495bc6984@github.com>
Message-ID: <9OydOuAfCPjCBMM9nXoGUIXDTfHD_Pb9KECxzws5AdE=.01745e92-6829-4861-8ce7-926b912a28f9@github.com>

On Thu, 30 Jan 2025 11:58:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We run into peculiar problem in Leyden: due to current prototype limitation, we cannot yet store the generated code that has the expanded code buffer. The code buffer expansion routinely happens with late G1 barrier expansion, as `G1BarrierSetC2` does not report any estimate for stub sizes.
>> 
>> So a method rich in these G1 stubs would blow the initial code size estimate, force the buffer resize, and thus disqualify itself from storing C2 code in Leyden. Whoops. Fortunately, we just need to implement `G1BarrierSetC2::estimate_stub_size()` in mainline to avoid a significant part of this problem. 
>> 
>> I also fixed the misattribution of "stub" sizes in insn section, this part is also important to get the stub sizes right. I can do that separately, but it would only matter for ZGC without G1 stub size estimation implemented.
>> 
>> You can see the impact it has on Leyden here:
>> https://github.com/openjdk/leyden/pull/28#issuecomment-2619077625
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Leyden-specific additions, plainly estimate the stubs size

Ooof. I added this assert on top of this PR:


diff --git a/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp b/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
index 2edc827401d..cadb7988214 100644
--- a/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
+++ b/src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
@@ -546,6 +546,11 @@ int G1BarrierSetC2::estimate_stub_size() const {
     size += cb.insts_size();
   }
 
+  if (size > 0) {
+    ResourceMark rm;
+    fatal("Non-zero C2 G1 stubs in %s", C->method()->name()->as_klass_external_name());
+  }
+
   return size;
 }


...ran `tier{1,2,3}` and hit it exactly zero times.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23333#issuecomment-2624856901

From duke at openjdk.org  Thu Jan 30 16:14:27 2025
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 30 Jan 2025 16:14:27 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v2]
In-Reply-To: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
Message-ID: <hEbWLMmT-NemgtAzFnQaJcpsD72ILyj6MMABAH6kBQY=.3e4995f2-d6d2-49ea-ac19-9a241333aeac@github.com>

> By using the aarch64 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  Use SHA3Parallel for matrix generation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23300/files
  - new: https://git.openjdk.org/jdk/pull/23300/files/eb7cc430..36151635

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23300&range=00-01

  Stats: 81 lines in 1 file changed: 49 ins; 5 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/23300.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23300/head:pull/23300

PR: https://git.openjdk.org/jdk/pull/23300

From zgu at openjdk.org  Thu Jan 30 16:16:59 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 30 Jan 2025 16:16:59 GMT
Subject: RFR: 8349003: NativeCallStack::print_on() output is unreadable
 [v2]
In-Reply-To: <HTAfVXPDgP8JJ6-MOj49KX5y3ScqOe2SByBNELHd1zg=.61d90a0e-812f-428a-80d1-422573d30759@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
 <HTAfVXPDgP8JJ6-MOj49KX5y3ScqOe2SByBNELHd1zg=.61d90a0e-812f-428a-80d1-422573d30759@github.com>
Message-ID: <RZy7-gAUvkFaMVV0fBz6yIv4daCSSEsuqcXaoj2BW6I=.222ffac8-7bb3-46ac-a86c-6a6c7a2a2b12@github.com>

On Thu, 30 Jan 2025 14:15:33 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this trivial change that improves output readability.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   David's comment

Thanks, @dholmes-ora @tstuefe

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23359#issuecomment-2624936434

From zgu at openjdk.org  Thu Jan 30 16:16:59 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 30 Jan 2025 16:16:59 GMT
Subject: Integrated: 8349003: NativeCallStack::print_on() output is unreadable
In-Reply-To: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
References: <msJkWt9qxN1RyMNCS8t4CJSHTO8qBglomje7_Q5srZs=.bb0df0b8-b506-4acf-a175-0010ae842d68@github.com>
Message-ID: <yQMwdl6u99P_I3a0mt69D2oG2owerAJgy93KE2e60Y4=.6492f78a-6cf4-4af8-91f5-1a3ab924f257@github.com>

On Wed, 29 Jan 2025 22:00:08 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial change that improves output readability.

This pull request has now been integrated.

Changeset: 0cae8880
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cae888046e0b014e2222d16ef9f830cecf8f8dd
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8349003: NativeCallStack::print_on() output is unreadable

Reviewed-by: stuefe, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/23359

From adinn at openjdk.org  Thu Jan 30 16:26:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 30 Jan 2025 16:26:46 GMT
Subject: RFR: 8348561: Add aarch64 intrinsics for ML-DSA [v2]
In-Reply-To: <hEbWLMmT-NemgtAzFnQaJcpsD72ILyj6MMABAH6kBQY=.3e4995f2-d6d2-49ea-ac19-9a241333aeac@github.com>
References: <hB4pg2SogrHkUlaqOt5ZD-LcayzrD400sJUEkANQDyo=.031d2ad5-8f8c-4a3b-b7b8-fb19ea8f35b4@github.com>
 <hEbWLMmT-NemgtAzFnQaJcpsD72ILyj6MMABAH6kBQY=.3e4995f2-d6d2-49ea-ac19-9a241333aeac@github.com>
Message-ID: <7UgNYEuTu6rj7queOgM9xIy-6kQMdACrZiDLtlniMYw=.dff6f18b-1236-43b1-8280-2bce9160f32a@github.com>

On Thu, 30 Jan 2025 16:14:27 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> By using the aarch64 vector registers the speed of the computation of the ML-DSA algorithms (key generation, document signing, signature verification) can be approximately doubled.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SHA3Parallel for matrix generation

@ferakocz I'm afraid you lucked out on getting your change committed before my reorganization of the stub generation code. If you are unsure of how to do the merge so your new stub is declared and generated following the new model (see the doc comments in stubDeclarations.hpp for details) let me know and I'll be happy to help you sort it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23300#issuecomment-2624962113

From iklam at openjdk.org  Thu Jan 30 16:47:13 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 30 Jan 2025 16:47:13 GMT
Subject: [jdk24] RFR: 8349009: JVM fails to start when AOTClassLinking is used
 with unverifiable old classes
Message-ID: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>

Hi all,

This pull request contains a backport of commit [1ac2d6e0](https://github.com/openjdk/jdk/commit/1ac2d6e0fb3d503241af1a44c9ed65837c63b646) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Ioi Lam on 30 Jan 2025 and was reviewed by John R Rose and Vladimir Kozlov.

Thanks!

-------------

Commit messages:
 - Backport 1ac2d6e0fb3d503241af1a44c9ed65837c63b646

Changes: https://git.openjdk.org/jdk/pull/23372/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23372&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349009
  Stats: 157 lines in 5 files changed: 153 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23372.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23372/head:pull/23372

PR: https://git.openjdk.org/jdk/pull/23372

From wkemper at openjdk.org  Thu Jan 30 16:53:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Jan 2025 16:53:47 GMT
Subject: RFR: 8348610: GenShen: TestShenandoahEvacuationInformationEvent
 failed with setRegions >= regionsFreed: expected 1 >= 57
In-Reply-To: <M-8yf6fmPVUPLubCfG83quv9jTAHkqhcrgy_dHy288M=.70835c1f-be6c-4ff7-b2a1-1eb2b96ba69f@github.com>
References: <M-8yf6fmPVUPLubCfG83quv9jTAHkqhcrgy_dHy288M=.70835c1f-be6c-4ff7-b2a1-1eb2b96ba69f@github.com>
Message-ID: <P_PEuiuQ7mz_gQ5XYawYVr2NO-sG2EoLVyzcmrBKW4M=.55aab6c5-48d5-4171-a6e2-05d3c2dd474b@github.com>

On Thu, 30 Jan 2025 04:43:59 GMT, Satyen Subramaniam <ssubramaniam at openjdk.org> wrote:

> Renaming `ShenandoahEvacuationInformation.freedRegions` to `ShenandoahEvacuationInformation.freeRegions` for clarity, and fixing incorrect assertion in  TestShenandoahEvacuationInformationEvent.cpp
> 
> Tested with tier 1, tier 2, and tier 3 tests.

LGTM. Thank you!

-------------

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23362#pullrequestreview-2584475570

From kvn at openjdk.org  Thu Jan 30 17:31:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 30 Jan 2025 17:31:55 GMT
Subject: [jdk24] RFR: 8349009: JVM fails to start when AOTClassLinking is
 used with unverifiable old classes
In-Reply-To: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
References: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
Message-ID: <U7eP4krWhTYb4cej-nfZmW59GUif8rVrG2aZMm_KmkQ=.2c338d6d-6bd7-4350-bdd8-3836b784b928@github.com>

On Thu, 30 Jan 2025 16:35:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1ac2d6e0](https://github.com/openjdk/jdk/commit/1ac2d6e0fb3d503241af1a44c9ed65837c63b646) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 30 Jan 2025 and was reviewed by John R Rose and Vladimir Kozlov.
> 
> Thanks!

Backport looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23372#pullrequestreview-2584569290

From shade at openjdk.org  Thu Jan 30 19:09:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 30 Jan 2025 19:09:49 GMT
Subject: [jdk24] RFR: 8349009: JVM fails to start when AOTClassLinking is
 used with unverifiable old classes
In-Reply-To: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
References: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
Message-ID: <PIaNHKPFvGe7HPjicbMp0dPJvLz7Y00flG1NjAXPxfg=.a1cf56e2-bdea-4dc2-8e77-1f9f7c30c76a@github.com>

On Thu, 30 Jan 2025 16:35:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1ac2d6e0](https://github.com/openjdk/jdk/commit/1ac2d6e0fb3d503241af1a44c9ed65837c63b646) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 30 Jan 2025 and was reviewed by John R Rose and Vladimir Kozlov.
> 
> Thanks!

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23372#pullrequestreview-2584771022

From jrose at openjdk.org  Fri Jan 31 02:15:46 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 31 Jan 2025 02:15:46 GMT
Subject: [jdk24] RFR: 8349009: JVM fails to start when AOTClassLinking is
 used with unverifiable old classes
In-Reply-To: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
References: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
Message-ID: <_VfO82y0ch_SFe0MKfr3ZuYRsh9xZEX5oKQQxSn-JzQ=.72f538fd-3f98-41ac-a4f4-195852b358a5@github.com>

On Thu, 30 Jan 2025 16:35:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1ac2d6e0](https://github.com/openjdk/jdk/commit/1ac2d6e0fb3d503241af1a44c9ed65837c63b646) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 30 Jan 2025 and was reviewed by John R Rose and Vladimir Kozlov.
> 
> Thanks!

Marked as reviewed by jrose (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23372#pullrequestreview-2585518464

From rrich at openjdk.org  Fri Jan 31 09:12:47 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 31 Jan 2025 09:12:47 GMT
Subject: RFR: 8344983: [PPC64] Rename ConditionRegisters [v3]
In-Reply-To: <s5bBTa-RbK7FIaP0V4kJipsQ_uFnKJsNkWoWl_7BBXA=.399ea57f-69ab-4bc3-8557-f4b260ea8276@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
 <s5bBTa-RbK7FIaP0V4kJipsQ_uFnKJsNkWoWl_7BBXA=.399ea57f-69ab-4bc3-8557-f4b260ea8276@github.com>
Message-ID: <Rpp8h-Fxr-GqJz2avPDfCdXOeEJwxxhUEZETNb0gaWQ=.cc85a53d-c0be-45b9-9d55-d1cc56edc4ca@github.com>

On Fri, 31 Jan 2025 07:01:46 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

>> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
>> 
>> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)
>
> Sorna Sarathi N 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 master
>  - Updated the copyright header years for the edited files
>  - Renaming the Condition Registers

Still good.
Thanks, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23325#pullrequestreview-2586058488

From kcr at openjdk.org  Fri Jan 31 13:49:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 31 Jan 2025 13:49:53 GMT
Subject: [jdk24] RFR: 8345405: Add JMH showing the regression in 8341649
In-Reply-To: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>
References: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>
Message-ID: <YRpfGBsCmPzRoDg7NTZuQ48r_UNpey1nxupKiunU3l4=.ff9513ed-8888-4f0d-ae69-3a5a63437ecb@github.com>

On Wed, 11 Dec 2024 17:10:55 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> 8345405: Add JMH showing the regression in 8341649

@ericcaspole Do you intend to integrate this backport PR to `jdk24`? It either needs to be integrated or closed before the end of RDP2 (Feb 6th).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22686#issuecomment-2627396239

From stefank at openjdk.org  Fri Jan 31 14:03:24 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 31 Jan 2025 14:03:24 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include ordering
Message-ID: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>

The HotSpot Style Guide has a section about source files and includes. The style used for includes have mostly been introduced by scripts when includeDB was replaced, but also when various other enhancements to our includes were made. Some of the introduced styles were never written down in the style guide.

I propose a couple of changes to the HotSpot Style Guide to reflect some of these implicit styles that we have. While updating the text I also took the liberty to order the items in an order that I felt was good.

Note that JDK-8323158 contains a few more suggestions, but I've only addressed the items that I think can be accepted without much contention. Either I extract the items that have not been address into a new RFE, or I create a new RFE for this PR.

There a some small whitespace tweaks that I made so that the .md and .html had a similar layout.

-------------

Commit messages:
 - 8323158: HotSpot Style Guide should specify more include ordering

Changes: https://git.openjdk.org/jdk/pull/23388/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23388&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323158
  Stats: 46 lines in 2 files changed: 28 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23388/head:pull/23388

PR: https://git.openjdk.org/jdk/pull/23388

From ssarathi at openjdk.org  Fri Jan 31 14:08:52 2025
From: ssarathi at openjdk.org (Sorna Sarathi N)
Date: Fri, 31 Jan 2025 14:08:52 GMT
Subject: Integrated: 8344983: [PPC64] Rename ConditionRegisters
In-Reply-To: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
References: <XAlsMfL4Cxg4stXrWzDJRdRgaBatCHxDyBby8XmAe6w=.ab39f4a7-c407-4834-9ac2-33fe892e98c4@github.com>
Message-ID: <HiFWlNd2dLnqGAFfgA-54tr2v2bgKAfx2MOEqpNKWdo=.06ab16c3-16b0-438f-aa9a-d7bc7cfded46@github.com>

On Tue, 28 Jan 2025 08:31:59 GMT, Sorna Sarathi N <ssarathi at openjdk.org> wrote:

> PPC64 currently uses the names CCR0 to CCR7 for Condition Registers. This PR renames them as CR0 to CR7 matching the ISA. Build(release debug level) and testing are successful.
> 
> JBS Issue: [JDK-8344983](https://bugs.openjdk.org/browse/JDK-8344983)

This pull request has now been integrated.

Changeset: a414a591
Author:    Sorna Sarathi N <ssarathi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a414a591dd8d66f1500cd69dd65baa6ba4224c2a
Stats:     1415 lines in 32 files changed: 0 ins; 0 del; 1415 mod

8344983: [PPC64] Rename ConditionRegisters

Reviewed-by: rrich, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/23325

From ecaspole at openjdk.org  Fri Jan 31 15:09:58 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 31 Jan 2025 15:09:58 GMT
Subject: [jdk24] Integrated: 8345405: Add JMH showing the regression in 8341649
In-Reply-To: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>
References: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>
Message-ID: <Vv6NNxFXaezVph4x2kyyiL7-QtIJ_OHt9eL-0tLILkE=.062374f6-4e38-428b-8c10-8292799c65eb@github.com>

On Wed, 11 Dec 2024 17:10:55 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> 8345405: Add JMH showing the regression in 8341649

This pull request has now been integrated.

Changeset: 926455d6
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/926455d6c532f0f671a335fb07352507a986d82f
Stats:     175 lines in 1 file changed: 175 ins; 0 del; 0 mod

8345405: Add JMH showing the regression in 8341649

Reviewed-by: coleenp
Backport-of: 35c00532a1dd2a6df5fc3d5173ca692517675d38

-------------

PR: https://git.openjdk.org/jdk/pull/22686

From ecaspole at openjdk.org  Fri Jan 31 15:09:57 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 31 Jan 2025 15:09:57 GMT
Subject: [jdk24] RFR: 8345405: Add JMH showing the regression in 8341649
In-Reply-To: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>
References: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>
Message-ID: <lHBdTCT_OIX3yZws26FYP_PVWcKkH6ThqFr6lmUSuq4=.5e96642c-a4a4-4b8b-8a03-f4fa79ecc343@github.com>

On Wed, 11 Dec 2024 17:10:55 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> 8345405: Add JMH showing the regression in 8341649

Thanks for the reminder.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22686#issuecomment-2627567636

From coleenp at openjdk.org  Fri Jan 31 16:43:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 31 Jan 2025 16:43:56 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
Message-ID: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>

This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
Tested with tier1-4.

-------------

Commit messages:
 - Fix the test.
 - 8349145: Make Class.getProtectionDomain() non-native

Changes: https://git.openjdk.org/jdk/pull/23396/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23396&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349145
  Stats: 57 lines in 8 files changed: 10 ins; 33 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23396/head:pull/23396

PR: https://git.openjdk.org/jdk/pull/23396

From liach at openjdk.org  Fri Jan 31 16:59:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Jan 2025 16:59:46 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <SOWXVHkeYjR8PkoJydN2M9rD5R6_yB464izVGrjBcEo=.c3cbd9b0-0a45-4fdb-bc71-ce348f73af86@github.com>

On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

Marked as reviewed by liach (Reviewer).

src/java.base/share/classes/java/lang/System.java line 2150:

> 2148:             }
> 2149: 
> 2150:             public ProtectionDomain protectionDomain(Class<?> c) {

This accessor has become pointless since the functinoal removal of SM, but it would be out of scope for this PR.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23396#pullrequestreview-2587285757
PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1937604899

From shade at openjdk.org  Fri Jan 31 17:08:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 31 Jan 2025 17:08:49 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <g2Cl2ACu9JAP6fLusOy-2EroQg-w3ARVt5vo1RVSUEU=.3a302417-0def-468c-baff-a08a70788a65@github.com>

On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

One thing to think about: does this mean `protectionDomain` is now discoverable by reflection? Should it be? Should it be filtered?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627825448

From liach at openjdk.org  Fri Jan 31 17:19:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 31 Jan 2025 17:19:46 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <zRpwtZISfIFpzcZoLgwa3a2z44ueh4y96fymapzxJvI=.507e6771-bf36-4c2a-b21f-0f60c2ae179c@github.com>

On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

Reflection filtering was mostly a legacy measure to avoid write and read access to fields via reflection that can't hide in the VM. Now the access control of modules should be sufficient to block writes (and if java.lang is compromised, we can consider the whole VM compromised); we already grant free reads with the functional removal of SM. (The explicit move of `signers` did not filter that field, too)

On a side note, if we filter more than 2 fields in `jdk.internal.reflect.Reflection`, we had better filter all fields. The filter is initialized very early in the bootstrap process, before `JavaLangAccess` is ready, so early that it couldn't access string hash code computation required for regular immutable sets.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627839902

From coleenp at openjdk.org  Fri Jan 31 17:19:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 31 Jan 2025 17:19:47 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <g2Cl2ACu9JAP6fLusOy-2EroQg-w3ARVt5vo1RVSUEU=.3a302417-0def-468c-baff-a08a70788a65@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <g2Cl2ACu9JAP6fLusOy-2EroQg-w3ARVt5vo1RVSUEU=.3a302417-0def-468c-baff-a08a70788a65@github.com>
Message-ID: <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com>

On Fri, 31 Jan 2025 17:06:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> One thing to think about: does this mean protectionDomain is now discoverable by reflection? Should it be? Should it be filtered?

We hid it in the past so it wouldn't be discoverable, but with the removal of the security manager, there doesn't seem to be a reason for hiding it.  @seanjmullan can you confirm?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627840788

From alanb at openjdk.org  Fri Jan 31 17:19:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Jan 2025 17:19:47 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <g2Cl2ACu9JAP6fLusOy-2EroQg-w3ARVt5vo1RVSUEU=.3a302417-0def-468c-baff-a08a70788a65@github.com>
 <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com>
Message-ID: <CwM8SNDCb2lAp3epYLGb2mAUGHdBqO_esyT6Nqfr_0k=.c195988f-9bdc-465d-8b31-5611f85c1fd8@github.com>

On Fri, 31 Jan 2025 17:14:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> One thing to think about: does this mean `protectionDomain` is now discoverable by reflection? Should it be? Should it be filtered?

Class::getProtectionDomain is a public API so anyone looking for it doesn't need reflection, but maybe you are thinking of something else?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627845207

From coleenp at openjdk.org  Fri Jan 31 17:19:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 31 Jan 2025 17:19:49 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <SOWXVHkeYjR8PkoJydN2M9rD5R6_yB464izVGrjBcEo=.c3cbd9b0-0a45-4fdb-bc71-ce348f73af86@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <SOWXVHkeYjR8PkoJydN2M9rD5R6_yB464izVGrjBcEo=.c3cbd9b0-0a45-4fdb-bc71-ce348f73af86@github.com>
Message-ID: <MvwTuFPKF_B6HWF6_L5yI06NvxTfLDKWoRufYKEU_8w=.a313ab4e-1ff8-4a03-a768-f43e8c38f993@github.com>

On Fri, 31 Jan 2025 16:51:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> src/java.base/share/classes/java/lang/System.java line 2150:
> 
>> 2148:             }
>> 2149: 
>> 2150:             public ProtectionDomain protectionDomain(Class<?> c) {
> 
> This accessor has become pointless since the functinoal removal of SM, but it would be out of scope for this PR.

Thanks for looking at this.  I didn't want to change this with this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1937633847

From shade at openjdk.org  Fri Jan 31 17:24:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 31 Jan 2025 17:24:44 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <CwM8SNDCb2lAp3epYLGb2mAUGHdBqO_esyT6Nqfr_0k=.c195988f-9bdc-465d-8b31-5611f85c1fd8@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
 <g2Cl2ACu9JAP6fLusOy-2EroQg-w3ARVt5vo1RVSUEU=.3a302417-0def-468c-baff-a08a70788a65@github.com>
 <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com>
 <CwM8SNDCb2lAp3epYLGb2mAUGHdBqO_esyT6Nqfr_0k=.c195988f-9bdc-465d-8b31-5611f85c1fd8@github.com>
Message-ID: <fNDc9c4ZXdKqu4pI1y1NFpeoCknVW3oLvQQZsO4hkLM=.3b5e9cc3-eae8-4bc4-9511-4f782e40e51f@github.com>

On Fri, 31 Jan 2025 17:17:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > One thing to think about: does this mean `protectionDomain` is now discoverable by reflection? Should it be? Should it be filtered?
> 
> Class::getProtectionDomain is a public API so anyone looking for it doesn't need reflection, but maybe you are thinking of something else?

I am thinking if anything new happens if we can reflect the field, `setAccessible(true)` it, and overwrite it. I guess the normal protection rules disallow the `setAccessible` part, but it does not hurt to think and confirm this is still enough and good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627854782

From coleenp at openjdk.org  Fri Jan 31 17:33:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 31 Jan 2025 17:33:45 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <lZQb7P2VzkoGfig68F_YvJctCYq-OgNawcYpQpHz3oU=.d497ae9a-3d6a-441c-b57b-9bb367459e05@github.com>

On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

I was thinking of what happens if you use setAccessible(true) on this field.  At worst we could add it to the filter of fields that we don't allow setAccessible(true) on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627869508

From coleenp at openjdk.org  Fri Jan 31 19:19:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 31 Jan 2025 19:19:29 GMT
Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v2]
In-Reply-To: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
References: <BIBEhf6NCOLj3gkLU3W93LuxcpjSy1nEkZkEntdf07c=.7996326b-0ab1-4b04-8afc-0626abd65ed3@github.com>
Message-ID: <DLz7qglb7NYgAu0cShw86w-kHMxdVLhpDrFo9MNu7_U=.c9fd80ff-e3d8-4afd-973c-fdbab78f5877@github.com>

> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix two tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23396/files
  - new: https://git.openjdk.org/jdk/pull/23396/files/ca88c32f..d7aafbaf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23396&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23396&range=00-01

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23396/head:pull/23396

PR: https://git.openjdk.org/jdk/pull/23396

From kvn at openjdk.org  Fri Jan 31 19:48:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 31 Jan 2025 19:48:53 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering
In-Reply-To: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
Message-ID: <AkMkxHu2S7wxmcoGl7ZYkM_zfSn6ou6xMfncNo8Y5Tk=.707eded0-ba85-48bf-b631-4ae973065a16@github.com>

On Fri, 31 Jan 2025 13:56:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The HotSpot Style Guide has a section about source files and includes. The style used for includes have mostly been introduced by scripts when includeDB was replaced, but also when various other enhancements to our includes were made. Some of the introduced styles were never written down in the style guide.
> 
> I propose a couple of changes to the HotSpot Style Guide to reflect some of these implicit styles that we have. While updating the text I also took the liberty to order the items in an order that I felt was good.
> 
> Note that JDK-8323158 contains a few more suggestions, but I've only addressed the items that I think can be accepted without much contention. Either I extract the items that have not been address into a new RFE, or I create a new RFE for this PR.
> 
> There a some small whitespace tweaks that I made so that the .md and .html had a similar layout.

Looks reasonable.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23388#pullrequestreview-2587698393

From kbarrett at openjdk.org  Fri Jan 31 22:20:00 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 31 Jan 2025 22:20:00 GMT
Subject: RFR: 8323158: HotSpot Style Guide should specify more include
 ordering
In-Reply-To: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
References: <yfIFGrLZzz60dTpVXmMo3Q4uHMauBdW5YGryOBp3XqA=.043555cd-8a6e-46bb-83b1-8355ff55b669@github.com>
Message-ID: <6z2iiGxab2SeDXBb9AXHfXh-qSV3dmGnVzMmVMLGlyo=.bd9e5fcf-cade-4d41-a704-29439ae69b1d@github.com>

On Fri, 31 Jan 2025 13:56:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The HotSpot Style Guide has a section about source files and includes. The style used for includes have mostly been introduced by scripts when includeDB was replaced, but also when various other enhancements to our includes were made. Some of the introduced styles were never written down in the style guide.
> 
> I propose a couple of changes to the HotSpot Style Guide to reflect some of these implicit styles that we have. While updating the text I also took the liberty to order the items in an order that I felt was good.
> 
> Note that JDK-8323158 contains a few more suggestions, but I've only addressed the items that I think can be accepted without much contention. Either I extract the items that have not been address into a new RFE, or I create a new RFE for this PR.
> 
> There a some small whitespace tweaks that I made so that the .md and .html had a similar layout.

Just a couple of minor wording nits.  Otherwise looks good to me.

doc/hotspot-style.md line 158:

> 156: 
> 157: * All .inline.hpp files should include their corresponding .hpp file as
> 158: the first include line with blank line separating it from the rest of the

s/with blank line/with a blank line/

doc/hotspot-style.md line 167:

> 165: * Use include guards for .hpp and .inline.hpp files. The name of the defined
> 166: guard should be derived from the full search path of the file relative to the
> 167: hotspot source directory. The define should be all upper case with all paths

s/define/guard/ ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23388#pullrequestreview-2587973246
PR Review Comment: https://git.openjdk.org/jdk/pull/23388#discussion_r1938039285
PR Review Comment: https://git.openjdk.org/jdk/pull/23388#discussion_r1938040703

From iklam at openjdk.org  Fri Jan 31 23:10:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 31 Jan 2025 23:10:53 GMT
Subject: [jdk24] RFR: 8349009: JVM fails to start when AOTClassLinking is
 used with unverifiable old classes
In-Reply-To: <_VfO82y0ch_SFe0MKfr3ZuYRsh9xZEX5oKQQxSn-JzQ=.72f538fd-3f98-41ac-a4f4-195852b358a5@github.com>
References: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
 <_VfO82y0ch_SFe0MKfr3ZuYRsh9xZEX5oKQQxSn-JzQ=.72f538fd-3f98-41ac-a4f4-195852b358a5@github.com>
Message-ID: <F293G__R8OYAiWQqEt4sgn1HFy4dka3Qs8bBL0PURNs=.60120ad3-8f5d-4219-805d-3f3e8aeddafa@github.com>

On Fri, 31 Jan 2025 02:13:02 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [1ac2d6e0](https://github.com/openjdk/jdk/commit/1ac2d6e0fb3d503241af1a44c9ed65837c63b646) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Ioi Lam on 30 Jan 2025 and was reviewed by John R Rose and Vladimir Kozlov.
>> 
>> Thanks!
>
> Marked as reviewed by jrose (Reviewer).

Thanks @rose00 @shipilev @vnkozlov for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23372#issuecomment-2628544924

From iklam at openjdk.org  Fri Jan 31 23:10:54 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 31 Jan 2025 23:10:54 GMT
Subject: [jdk24] Integrated: 8349009: JVM fails to start when AOTClassLinking
 is used with unverifiable old classes
In-Reply-To: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
References: <1sL51f90aATV6Q3hTGCGrzjYYDKbVPv7ESHhFdK6Whk=.3d468e14-7585-4ae8-9ac4-a91696657585@github.com>
Message-ID: <1QlquyJ5aZwO2o85_fCUZkR0x30o9M__VCmMyJratBU=.807c4f3e-8dcf-438f-bb28-a963af60570d@github.com>

On Thu, 30 Jan 2025 16:35:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1ac2d6e0](https://github.com/openjdk/jdk/commit/1ac2d6e0fb3d503241af1a44c9ed65837c63b646) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 30 Jan 2025 and was reviewed by John R Rose and Vladimir Kozlov.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 89c46f11
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89c46f11f8adb0d45f3e2465b5e915dcad666ad9
Stats:     157 lines in 5 files changed: 153 ins; 0 del; 4 mod

8349009: JVM fails to start when AOTClassLinking is used with unverifiable old classes

Reviewed-by: kvn, shade, jrose
Backport-of: 1ac2d6e0fb3d503241af1a44c9ed65837c63b646

-------------

PR: https://git.openjdk.org/jdk/pull/23372