Integrated: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack?

[Jan Kratochvil]

On Sat, 22 Jun 2024 13:58:32 GMT, Jan Kratochvil  
wrote:

> fastdebug:
> 
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error 
> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>  pid=878152, tid=878158
> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
> #
> # JRE version:  (24.0) (fastdebug build )
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 
> 24-internal-adhoc.azul.openjdk-git, mixed mode, tiered, compressed oops, 
> compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x1d20658]  constantPoolHandle::constantPoolHandle(Thread*, 
> ConstantPool*)+0x268

This pull request has now been integrated.

Changeset: b4df380f
Author:Jan Kratochvil 
Committer: Kim Barrett 
URL:   
https://git.openjdk.org/jdk/commit/b4df380f1a4587247a843fe28ae041265f7cfc29
Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod

8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) 
failed: not on stack?

Reviewed-by: kbarrett, stuefe, erikj

-

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

Re: RFR: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? [v6]

[duke]

On Thu, 27 Jun 2024 01:34:36 GMT, Jan Kratochvil  
wrote:

>> fastdebug:
>> 
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error 
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>>  pid=878152, tid=878158
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> #
>> # JRE version:  (24.0) (fastdebug build )
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 
>> 24-internal-adhoc.azul.openjdk-git, mixed mode, tiered, compressed oops, 
>> compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x1d20658]  constantPoolHandle::constantPoolHandle(Thread*, 
>> ConstantPool*)+0x268
>
> Jan Kratochvil has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   New comment about MSVC having the option off by default

@jankratochvil 
Your change (at version 08153d9cf2ab8d0721fc1f257f9d662de4814212) is now ready 
to be sponsored by a Committer.

-

PR Comment: https://git.openjdk.org/jdk/pull/19843#issuecomment-2195795680

Re: RFR: 8329816: Add SLEEF version 3.6.1

[Mikael Vidstedt]

On Mon, 24 Jun 2024 13:30:35 GMT, Hamlin Li  wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to 
>> optimize vector math operations by leveraging the SLEEF library. For legal 
>> reasons the actual contribution of the SLEEF files needs to be handled 
>> separately. This enhancement adds the relevant files, enabling the rest of 
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> In case you need it and avoid to generate yourself, I've generated sleef 
> inline header of 3.6.1 for riscv, it's at 
> https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe88198988d31a4

@Hamlin-Li I have generated the header files (two aarch64 and the new one for 
riscv64) using SLEEF 3.6.1. Please make sure they match your expectations!

-

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2195728763

Re: RFR: 8329816: Add SLEEF version 3.6.1 [v3]

[Mikael Vidstedt]

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to 
> optimize vector math operations by leveraging the SLEEF library. For legal 
> reasons the actual contribution of the SLEEF files needs to be handled 
> separately. This enhancement adds the relevant files, enabling the rest of 
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.

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

  Update README to include RISC-V

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/19185/files
  - new: https://git.openjdk.org/jdk/pull/19185/files/b29de559..8a08ffa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=19185=02
 - incr: https://webrevs.openjdk.org/?repo=jdk=19185=01-02

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

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

Re: RFR: 8329816: Add SLEEF version 3.6.1 [v2]

[Magnus Ihse Bursie]

On Thu, 23 May 2024 12:49:42 GMT, Hamlin Li  wrote:

>> Okay, suffix works fine too. But the files currently in the patch is named 
>> e.g. `sleefinline_advsimd.h`, which does not indicate any platform at all. 
>> Is it a generic file, and the platform specific ones are still missing from 
>> this PR?
>
> I think both `sleefinline_advsimd.h` and `sleefinline_sve.h` are specific for 
> arm.
> In the future, on riscv the corresponding file name will be 
> `sleefinline_rvvm1.h`.
> 
> Only `misc.h` is a generic file shared among platforms.

Oh, you mean that the `sve` suffix signals that it is for ARM. I thought you 
were talking about having a name like `sleefinline_aarch64.h`.

Sure, if the only files generated by sleef are ever .h files, the logic for 
chosing which to include can be done entirely by `#ifdef`s in the source code. 
But if there ever needs to be different .c or .cpp files to include in the 
build, the build system needs to be able to determine automatically if they 
should be included or included, and that can only be made if the path or the 
file name includes the CPU moniker. 

Personally, I think it would show good alignment with the prevailing norms in 
the JDK to also use this way of naming files for .h files. But I confess that 
for .h files it is more a matter of style, rather than a necessity from the 
build system.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1611964018

Re: RFR: 8329816: Add SLEEF version 3.6.1 [v2]

[Hamlin Li]

On Thu, 23 May 2024 16:06:42 GMT, Magnus Ihse Bursie  wrote:

>> I think both `sleefinline_advsimd.h` and `sleefinline_sve.h` are specific 
>> for arm.
>> In the future, on riscv the corresponding file name will be 
>> `sleefinline_rvvm1.h`.
>> 
>> Only `misc.h` is a generic file shared among platforms.
>
> Oh, you mean that the `sve` suffix signals that it is for ARM. I thought you 
> were talking about having a name like `sleefinline_aarch64.h`.
> 
> Sure, if the only files generated by sleef are ever .h files, the logic for 
> chosing which to include can be done entirely by `#ifdef`s in the source 
> code. But if there ever needs to be different .c or .cpp files to include in 
> the build, the build system needs to be able to determine automatically if 
> they should be included or included, and that can only be made if the path or 
> the file name includes the CPU moniker. 
> 
> Personally, I think it would show good alignment with the prevailing norms in 
> the JDK to also use this way of naming files for .h files. But I confess that 
> for .h files it is more a matter of style, rather than a necessity from the 
> build system.

Thanks for the information. I think the files from sleef will be .h headers 
only. I'm also fine to align with prevailing norms in the JDK, it's always good 
to do so.

Just a reminder for us in the future discussion of 
https://github.com/openjdk/jdk/pull/18605, maybe we should consider this dir or 
file naming norms (e.g. currently there are vector_math_sve.c and 
vector_math_neon.c under src/jdk.incubator.vector/linux/native/libvectormath), 
as there will be more files related to different platforms added in the future, 
e.g. riscv64.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1612933942

Re: RFR: 8329816: Add SLEEF version 3.6.1 [v2]

[Hamlin Li]

On Thu, 23 May 2024 10:40:26 GMT, Magnus Ihse Bursie  wrote:

>>> So you'd need a different copy of sleef for each platform?
>> 
>> I think it's one or more.
>> 
>>> The files you have put in linux/native/libvectormath, what platform are 
>>> they for? Should we not put them in a platform-specific subdirectory?
>> 
>> we could, but not necessary, as long as they have different suffixes, and 
>> normally that suffixes indicate what platform it's for.
>
> Okay, suffix works fine too. But the files currently in the patch is named 
> e.g. `sleefinline_advsimd.h`, which does not indicate any platform at all. Is 
> it a generic file, and the platform specific ones are still missing from this 
> PR?

I think both `sleefinline_advsimd.h` and `sleefinline_sve.h` are specific for 
arm.
In the future, on riscv the corresponding file name will be 
`sleefinline_rvvm1.h`.

Only `misc.h` is a generic file shared among platforms.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1611636701

Re: RFR: 8329816: Add SLEEF version 3.6.1 [v2]

[Magnus Ihse Bursie]

On Wed, 22 May 2024 09:39:43 GMT, Hamlin Li  wrote:

>> make/devkit/createSleef.sh line 32:
>> 
>>> 30: #
>>> 31: #   1. cd 
>>> 32: #   2. bash /make/devkit/createSleef.sh aarch64-gcc.cmake 
>>> /devkit
>> 
>> So you'd need a different copy of sleef for each platform? The files you 
>> have put in `linux/native/libvectormath`, what platform are they for? Should 
>> we not put them in a platform-specific subdirectory?
>
>> So you'd need a different copy of sleef for each platform?
> 
> I think it's one or more.
> 
>> The files you have put in linux/native/libvectormath, what platform are they 
>> for? Should we not put them in a platform-specific subdirectory?
> 
> we could, but not necessary, as long as they have different suffixes, and 
> normally that suffixes indicate what platform it's for.

Okay, suffix works fine too. But the files currently in the patch is named e.g. 
`sleefinline_advsimd.h`, which does not indicate any platform at all. Is it a 
generic file, and the platform specific ones are still missing from this PR?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1611448592

Re: RFR: 8329816: Add SLEEF version 3.6.1 [v2]

[Hamlin Li]

On Wed, 22 May 2024 09:31:27 GMT, Magnus Ihse Bursie  wrote:

> So you'd need a different copy of sleef for each platform?

I think it's one or more.

> The files you have put in linux/native/libvectormath, what platform are they 
> for? Should we not put them in a platform-specific subdirectory?

we could, but not necessary, as long as they have different suffixes, and 
normally that suffixes indicate what platform it's for.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1609635623

Re: RFR: 8329816: Add SLEEF version 3.6.1 [v2]

[Magnus Ihse Bursie]

On Thu, 27 Jun 2024 21:56:19 GMT, Mikael Vidstedt  wrote:

>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to 
>> optimize vector math operations by leveraging the SLEEF library. For legal 
>> reasons the actual contribution of the SLEEF files needs to be handled 
>> separately. This enhancement adds the relevant files, enabling the rest of 
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.
>
> Mikael Vidstedt 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:
> 
>  - Add SLEEF version 3.6.1
>  - Merge branch 'master' into 8329816-sleef
>  - 8329816: Add SLEEF version 3.6

make/devkit/createSleef.sh line 32:

> 30: #
> 31: #   1. cd 
> 32: #   2. bash /make/devkit/createSleef.sh aarch64-gcc.cmake 
> /devkit

So you'd need a different copy of sleef for each platform? The files you have 
put in `linux/native/libvectormath`, what platform are they for? Should we not 
put them in a platform-specific subdirectory?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1609623756

Re: RFR: 8329816: Add SLEEF version 3.6.1

[Hamlin Li]

On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt  wrote:

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to 
> optimize vector math operations by leveraging the SLEEF library. For legal 
> reasons the actual contribution of the SLEEF files needs to be handled 
> separately. This enhancement adds the relevant files, enabling the rest of 
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.

In case you need it and avoid to generate yourself, I've generated sleef inline 
header of 3.6.1 for riscv, it's at 
https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe88198988d31a4

-

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2186590880

Re: RFR: 8329816: Add SLEEF version 3.6.1

[Magnus Ihse Bursie]

On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt  wrote:

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to 
> optimize vector math operations by leveraging the SLEEF library. For legal 
> reasons the actual contribution of the SLEEF files needs to be handled 
> separately. This enhancement adds the relevant files, enabling the rest of 
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.

I understand that you want to avoid renaming files, if they are imported. That 
is a good point. Moving them to an arch subdirectory does not seem like much 
additional hassle (there's apparently still a lot of manual work involved in 
upgrading the source from the third party upstream), and might help readers 
that are not deeply familiar with these platforms. But then again, if we only 
talk about header files, it is not strictly needed, so if you don't want to do 
it, then skip it.

-

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2128971931

Re: RFR: 8329816: Add SLEEF version 3.6.1

[Mikael Vidstedt]

On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt  wrote:

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to 
> optimize vector math operations by leveraging the SLEEF library. For legal 
> reasons the actual contribution of the SLEEF files needs to be handled 
> separately. This enhancement adds the relevant files, enabling the rest of 
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.

I, too, envision that we'll be importing header files (only). That said, I'd 
very much prefer *not* to rename them as part of the import. If anything I 
could see us have architecture specific directories in which we place the 
respective files (and a common directory for `misc.h`), but it's not 
immediately clear to me that it's worth it given that the files are used in 
such a narrow context in the JDK.

-

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2128767164

Re: RFR: 8329816: Add SLEEF version 3.6.1 [v2]

[Mikael Vidstedt]

> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to 
> optimize vector math operations by leveraging the SLEEF library. For legal 
> reasons the actual contribution of the SLEEF files needs to be handled 
> separately. This enhancement adds the relevant files, enabling the rest of 
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward.

Mikael Vidstedt 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:

 - Add SLEEF version 3.6.1
 - Merge branch 'master' into 8329816-sleef
 - 8329816: Add SLEEF version 3.6

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/19185/files
  - new: https://git.openjdk.org/jdk/pull/19185/files/b02efa6b..b29de559

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=19185=01
 - incr: https://webrevs.openjdk.org/?repo=jdk=19185=00-01

  Stats: 160121 lines in 2836 files changed: 111602 ins; 34872 del; 13647 mod
  Patch: https://git.openjdk.org/jdk/pull/19185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19185/head:pull/19185

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

Re: RFR: 8329816: Add SLEEF version 3.6.1

[Hamlin Li]

On Fri, 17 May 2024 16:45:19 GMT, Mikael Vidstedt  wrote:

> Thank you Hamlin. I'll try to keep my eyes open for the announcement of the 
> upcoming SLEEF release but do feel free to notify me if you see it first!

Thank you @vidmik , sure, I will do it.

> I, too, envision that we'll be importing header files (only). That said, I'd 
> very much prefer *not* to rename them as part of the import. If anything I 
> could see us have architecture specific directories in which we place the 
> respective files (and a common directory for `misc.h`), but it's not 
> immediately clear to me that it's worth it given that the files are used in 
> such a narrow context in the JDK.

Hi @vidmik,
Sleef 3.6.1 was just released, 
https://github.com/shibatch/sleef/releases/tag/3.6.1, which includes the fixes 
https://github.com/shibatch/sleef/pull/536, 
https://github.com/shibatch/sleef/pull/537 which fixed the performance issue.

-

PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2119823702
PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2159052520

Re: RFR: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? [v6]

[Erik Joelsson]

On Thu, 27 Jun 2024 01:34:36 GMT, Jan Kratochvil  
wrote:

>> fastdebug:
>> 
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error 
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>>  pid=878152, tid=878158
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> #
>> # JRE version:  (24.0) (fastdebug build )
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 
>> 24-internal-adhoc.azul.openjdk-git, mixed mode, tiered, compressed oops, 
>> compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x1d20658]  constantPoolHandle::constantPoolHandle(Thread*, 
>> ConstantPool*)+0x268
>
> Jan Kratochvil has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   New comment about MSVC having the option off by default

Marked as reviewed by erikj (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/19843#pullrequestreview-2146461767

Integrated: 8334895: OpenJDK fails to configure on linux aarch64 when CDS is disabled after JDK-8331942

[Vladimir Petko]

On Mon, 24 Jun 2024 22:22:38 GMT, Vladimir Petko  wrote:

> This PR sets COMPATIBLE_CDS_ALIGNMENT_DEFAULT to auto for aarch64. 
> This allows to avoid configure error on arm64:
> 
> $ sh configure --disable-jvm-feature-cds
> ...
> checking if CDS archive is available... no (CDS is disabled)
> checking if a default CDS archive should be generated... disabled, from 
> default 'auto'
> checking if CDS archive is available... no (CDS is disabled)
> checking if compatible cds region alignment enabled... enabled, default
> configure: error: Option --enable-compatible-cds-alignment is not available
> configure exiting with result code 1
> 
> after applying the change:
> 
> $ sh configure --disable-jvm-feature-cds
> ...
> checking if the CDS classlist generation should be enabled... disabled, from 
> default 'auto'
> checking if any translations should be excluded... no
> checking if static man pages should be copied... enabled, default
> checking if CDS archive is available... no (CDS is disabled)
> checking if a default CDS archive should be generated... disabled, from 
> default 'auto'
> checking if CDS archive is available... no (CDS is disabled)
> checking if compatible cds region alignment enabled... disabled, from default 
> 'auto'
> checking for number of cores... 4
> checking for memory size... 7943 MB
> checking for appropriate number of jobs to run in parallel... 4
> checking whether to use javac server... enabled, default
> checking flags for boot jdk java command ...  -Duser.language=en 
> -Duser.country=US  -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces 
> -XX:SharedArchiveFile=/build/magic/arm64/jdk/build/linux-aarch64-server-release/configure-support/classes.jsa
>  -Xshare:auto 
> checking flags for boot jdk java command for big workloads...  -Xms64M 
> -Xmx1600M
> checking flags for bootcycle boot jdk java command for big workloads... 
> -Xms64M -Xmx1600M
> checking flags for boot jdk java command for small workloads...  
> -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1
> checking for --enable-icecc... disabled, default
> checking if precompiled headers are available... yes
> checking for --enable-precompiled-headers... enabled, from default 'auto'
> checking for ccache... [not found]
> checking if ccache is available... no, ccache binary missing or not executable
> checking if ccache is enabled... disabled, default
> checking if build directory is on local disk... yes
> configure: creating 
> /build/magic/arm64/jdk/build/linux-aarch64-server-release/configure-support/config.status
> config.status: creating 
> /build/magic/arm64/jdk/build/linux-aarch64-server-release/spec.gmk
> config.status: creating...

This pull request has now been integrated.

Changeset: 3b1ca986
Author:Vladimir Petko 
Committer: Erik Joelsson 
URL:   
https://git.openjdk.org/jdk/commit/3b1ca986427d3a69c9e167b9b4c07d1b83bc264d
Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8334895: OpenJDK fails to configure on linux aarch64 when CDS is disabled after 
JDK-8331942

Reviewed-by: erikj

-

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

Integrated: 8309634: Resolve CONSTANT_MethodRef at CDS dump time

[Ioi Lam]

On Mon, 24 Jun 2024 17:21:18 GMT, Ioi Lam  wrote:

> Resolve `CONSTANT_MethodRef` entries during CDS dump time to improve start-up 
> performance.
> 
> - This PR uses the same framework introduced in #19355 and just added 
> handling for methods.
> - Support for getstatic/putstatic/invokestatic will be done separately in 
> [JDK-8334898](https://bugs.openjdk.org/browse/JDK-8334898)

This pull request has now been integrated.

Changeset: c35e58a5
Author:Ioi Lam 
URL:   
https://git.openjdk.org/jdk/commit/c35e58a5adf06e25a3b482e2be384af95a84f11a
Stats: 354 lines in 13 files changed: 312 ins; 6 del; 36 mod

8309634: Resolve CONSTANT_MethodRef at CDS dump time

Reviewed-by: matsaave, ccheung

-

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

Re: RFR: 8309634: Resolve CONSTANT_MethodRef at CDS dump time [v3]

[Ioi Lam]

On Wed, 26 Jun 2024 18:17:00 GMT, Matias Saavedra Silva  
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 five additional commits 
>> since the last revision:
>> 
>>  - Merge branch 'master' into 8309634-resolve-methods-at-dumptime
>>  - Merge branch 'master' into 8309634-resolve-methods-at-dumptime
>>  - @calvinccheung and @matias9927 comments
>>  - Fixed whitespaces
>>  - 8309634: Resolve CONSTANT_MethodRef at CDS dump time
>
> Thanks for the updates!

Thanks @matias9927 and @calvinccheung for the review.

-

PR Comment: https://git.openjdk.org/jdk/pull/19866#issuecomment-2195587619

Re: RFR: 8309634: Resolve CONSTANT_MethodRef at CDS dump time [v3]

[Ioi Lam]

> Resolve `CONSTANT_MethodRef` entries during CDS dump time to improve start-up 
> performance.
> 
> - This PR uses the same framework introduced in #19355 and just added 
> handling for methods.
> - Support for getstatic/putstatic/invokestatic will be done separately in 
> [JDK-8334898](https://bugs.openjdk.org/browse/JDK-8334898)

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 five additional commits since the last 
revision:

 - Merge branch 'master' into 8309634-resolve-methods-at-dumptime
 - Merge branch 'master' into 8309634-resolve-methods-at-dumptime
 - @calvinccheung and @matias9927 comments
 - Fixed whitespaces
 - 8309634: Resolve CONSTANT_MethodRef at CDS dump time

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/19866/files
  - new: https://git.openjdk.org/jdk/pull/19866/files/fd039bef..368621a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=19866=02
 - incr: https://webrevs.openjdk.org/?repo=jdk=19866=01-02

  Stats: 5646 lines in 136 files changed: 3442 ins; 1560 del; 644 mod
  Patch: https://git.openjdk.org/jdk/pull/19866.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19866/head:pull/19866

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

Re: RFR: 8334031: Generated JfrNativeSettings seems off

[duke]

On Tue, 25 Jun 2024 18:55:14 GMT, Robert Toyonaga  wrote:

> This PR changes GenerateJfrFiles.java so that the generated 
> `JfrNativeSettings` union does not include JFR structs.`JfrNativeSettings` is 
> meant to hold the settings for JFR events, but previously also included JFR 
> structs such as MetaspaceSizes, StackFrame, CopyFailed, 
> G1EvacuationStatistics, ObjectSpace, VirtualSpace. These are not events, but 
> instead are JFR `Type`s, and so do not have settings such as stacktraces or 
> thresholds.
> 
> The inclusion of JFR structs in `JfrNativeSettings` was problematic because 
> it could cause a displacement between event ID and`JfrNativeSettings` array 
> index (each index is meant to correspond with a specific event ID).
> 
> Testing:
> - jdk/jdk/jfr
> - tier1

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

-

PR Comment: https://git.openjdk.org/jdk/pull/19891#issuecomment-2194650765

Re: RFR: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? [v4]

[duke]

On Mon, 24 Jun 2024 14:11:35 GMT, Jan Kratochvil  
wrote:

>> fastdebug:
>> 
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error 
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>>  pid=878152, tid=878158
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> #
>> # JRE version:  (24.0) (fastdebug build )
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 
>> 24-internal-adhoc.azul.openjdk-git, mixed mode, tiered, compressed oops, 
>> compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x1d20658]  constantPoolHandle::constantPoolHandle(Thread*, 
>> ConstantPool*)+0x268
>
> Jan Kratochvil has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix a typo
>- bugreported by Thomas Stuefe

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

-

PR Comment: https://git.openjdk.org/jdk/pull/19843#issuecomment-2186725333

Re: RFR: 8334895: OpenJDK fails to configure on linux aarch64 when CDS is disabled after JDK-8331942 [v3]

[duke]

On Tue, 25 Jun 2024 19:30:26 GMT, Vladimir Petko  wrote:

>> This PR sets COMPATIBLE_CDS_ALIGNMENT_DEFAULT to auto for aarch64. 
>> This allows to avoid configure error on arm64:
>> 
>> $ sh configure --disable-jvm-feature-cds
>> ...
>> checking if CDS archive is available... no (CDS is disabled)
>> checking if a default CDS archive should be generated... disabled, from 
>> default 'auto'
>> checking if CDS archive is available... no (CDS is disabled)
>> checking if compatible cds region alignment enabled... enabled, default
>> configure: error: Option --enable-compatible-cds-alignment is not available
>> configure exiting with result code 1
>> 
>> after applying the change:
>> 
>> $ sh configure --disable-jvm-feature-cds
>> ...
>> checking if the CDS classlist generation should be enabled... disabled, from 
>> default 'auto'
>> checking if any translations should be excluded... no
>> checking if static man pages should be copied... enabled, default
>> checking if CDS archive is available... no (CDS is disabled)
>> checking if a default CDS archive should be generated... disabled, from 
>> default 'auto'
>> checking if CDS archive is available... no (CDS is disabled)
>> checking if compatible cds region alignment enabled... disabled, from 
>> default 'auto'
>> checking for number of cores... 4
>> checking for memory size... 7943 MB
>> checking for appropriate number of jobs to run in parallel... 4
>> checking whether to use javac server... enabled, default
>> checking flags for boot jdk java command ...  -Duser.language=en 
>> -Duser.country=US  -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces 
>> -XX:SharedArchiveFile=/build/magic/arm64/jdk/build/linux-aarch64-server-release/configure-support/classes.jsa
>>  -Xshare:auto 
>> checking flags for boot jdk java command for big workloads...  -Xms64M 
>> -Xmx1600M
>> checking flags for bootcycle boot jdk java command for big workloads... 
>> -Xms64M -Xmx1600M
>> checking flags for boot jdk java command for small workloads...  
>> -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1
>> checking for --enable-icecc... disabled, default
>> checking if precompiled headers are available... yes
>> checking for --enable-precompiled-headers... enabled, from default 'auto'
>> checking for ccache... [not found]
>> checking if ccache is available... no, ccache binary missing or not 
>> executable
>> checking if ccache is enabled... disabled, default
>> checking if build directory is on local disk... yes
>> configure: creating 
>> /build/magic/arm64/jdk/build/linux-aarch64-server-release/configure-support/config.status
>> config.status: creating /build/mag...
>
> Vladimir Petko has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   fix typo in the description

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

-

PR Comment: https://git.openjdk.org/jdk/pull/19869#issuecomment-2191037866

Re: RFR: 8309634: Resolve CONSTANT_MethodRef at CDS dump time [v2]

[Calvin Cheung]

On Wed, 26 Jun 2024 03:11:41 GMT, Ioi Lam  wrote:

>> Resolve `CONSTANT_MethodRef` entries during CDS dump time to improve 
>> start-up performance.
>> 
>> - This PR uses the same framework introduced in #19355 and just added 
>> handling for methods.
>> - Support for getstatic/putstatic/invokestatic will be done separately in 
>> [JDK-8334898](https://bugs.openjdk.org/browse/JDK-8334898)
>
> 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 four additional commits since the 
> last revision:
> 
>  - Merge branch 'master' into 8309634-resolve-methods-at-dumptime
>  - @calvinccheung and @matias9927 comments
>  - Fixed whitespaces
>  - 8309634: Resolve CONSTANT_MethodRef at CDS dump time

Updates look good.

-

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19866#pullrequestreview-2145900266

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v6]

[Hamlin Li]

On Thu, 27 Jun 2024 11:53:38 GMT, Fei Gao  wrote:

>> in progress...
>
> Hi @Hamlin-Li , thanks for your work.
> 
> I tried to run benchmarks, 
> [FloatMaxVector](https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/FloatMaxVector.java#L1068)
>  and 
> [DoubleMaxVector](https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/DoubleMaxVector.java#L1068),
>  on different aarch64 machines.
> 
> Here is the data I got for `TANH`, with args `-i 5 -f 3 -wi 3 -foe true 
> -jvmArgs -Xms4g -Xmx4g -XX:+AlwaysPreTouch -XX:ObjectAlignmentInBytes=16`:
> 
> 
> // NEON machine
> Benchmark (size)   Mode Cnt  Units Perf gain
> DoubleMaxVector.TANH   1024thrpt15   ops/ms -38%
> FloatMaxVector.TANH1024thrpt15   ops/ms -26%
> 
> 
> 
> // 128-bit sve machine (TANH also implemented with NEON)
> Benchmark (size)   Mode Cnt  Units Perf gain
> DoubleMaxVector.TANH   1024thrpt15ops/ms-19%
> FloatMaxVector.TANH1024thrpt15ops/ms~00%
> 
> 
> The performance of vector stubs for `TANH` looks not quite stable on 
> different NEON machines. Since this pr does not provide `TANH` interface on 
> sve machines for [the performance 
> regression](https://github.com/openjdk/jdk/pull/16234/commits/2a7730d6acbac80438a43d1502cff6a476f8b5b5#diff-9112056f732229b18fec48fb0b20a3fe824de49d0abd41fbdb4202cfe70ad114R8521-R8525),
>  how about also disabling it on NEON for the same reason? WDYT? 
> 
> Thanks.

@fg1417 Thanks for testing. Sure, I can do that based on your test result, I 
will restart work on it after https://github.com/openjdk/jdk/pull/19185 is 
integrated.

@theRealAph I lost my previous vm, so currently I only generate the header 
files, but did not test performance since last time, I don't remember I had 
special vm options passed in at that time.

-

PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2195132669

Re: Is anyone able to build the JDK on Windows using VirtualBox to host Ubuntu?

[erik . joelsson]

Hello Anil,

Building in a VM on a laptop should be doable, but given how resource 
intensive the JDK build is, you could run into problems like you 
describe. You are most likely to get the best build performance running 
natively on the machine and OS you have, so my recommendation is to 
build for Windows in your case. If you still prefer to build for Linux, 
I think the best option is to use WSL. See doc/building.md for 
instructions on how to build for Linux in WSL. To build for Windows, I 
recommend installing Cygwin as the most straightforward and well tested 
option for a POSIX support layer on Windows. Once installed, you won't 
need to run any Windows commands as Cygwin emulates a Linux/Unix 
environment. Again see doc/building.md for instructions on how to 
install a build environment on Windows.


/Erik

On 6/27/24 04:51, Anil wrote:
I want to try out a small contribution to the JDK and want to build 
the JDK first.

I have a Windows 11 laptop.

I am not comfortable with the Windows commands and someone mentioned 
in this forum that most of the building is done on Linux.
So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was 
getting black screens and freezing. I downgraded the Ubuntu to 222.04 
and still got black screens. I don't know why this is happening.

Any advice appreciated.
Anil

On Tue, Jun 18, 2024, 7:25 PM Anil <1dropafl...@gmail.com> wrote:

Hello,
I want to try out a small contribution to the JDK and wanted to
build the JDK first,
before I change the code.
I forked and cloned the jdk following the instructions at The
OpenJDK Developers' Guide – OpenJDK Developers’ Guide


I am on Windows 11.
These instructions are given on the page but I am unsure which of
these to execute since I have already forked and cloned the git repo

|$ wget

https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz
$ tar xzf openjdk-16_linux-x64_bin.tar.gz $ sudo apt-get install
autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev
libxrandr-dev libxtst-dev libxt-dev libcups2-dev
libfontconfig1-dev libasound2-dev $ cd jdk $ sh ./configure
--with-boot-jdk=$HOME/jdk-16/ $ make images|


Do I still need to do the wget?
Also, I wondered if I should use book jdk-17 instead of jdk-16 as
in the instructions above.
thanks,
Anil

Re: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v9]

[Jan Lahoda]

On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee  wrote:

>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find 
>> code that accesses native functionality. Currently this includes `native` 
>> method declarations, and methods marked with `@Restricted`.
>> 
>> The tool accepts a list of class path and module path entries through 
>> `--class-path` and `--module-path`, and a set of root modules through 
>> `--add-modules`, as well as an optional target release with `--release`.
>> 
>> The default mode is for the tool to report all uses of `@Restricted` 
>> methods, and `native` method declaration in a tree-like structure:
>> 
>> 
>> app.jar (ALL-UNNAMED):
>>   main.Main:
>> main.Main::main(String[])void references restricted methods:
>>   java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment
>> main.Main::m()void is a native method declaration
>> 
>> 
>> The `--print-native-access` option can be used print out all the module 
>> names of modules doing native access in a comma separated list. For class 
>> path code, this will print out `ALL-UNNAMED`.
>> 
>> Testing: 
>> - `langtools_jnativescan` tests.
>> - Running the tool over jextract's libclang bindings, which use the FFM API, 
>> and thus has a lot of references to `@Restricted` methods.
>> - tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   de-dupe on path, not module name

Looks good to me.

-

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2145411864

Re: RFR: 8334031: Generated JfrNativeSettings seems off

[Robert Toyonaga]

On Wed, 26 Jun 2024 18:52:40 GMT, Erik Gahlin  wrote:

>> This PR changes GenerateJfrFiles.java so that the generated 
>> `JfrNativeSettings` union does not include JFR structs.`JfrNativeSettings` 
>> is meant to hold the settings for JFR events, but previously also included 
>> JFR structs such as MetaspaceSizes, StackFrame, CopyFailed, 
>> G1EvacuationStatistics, ObjectSpace, VirtualSpace. These are not events, but 
>> instead are JFR `Type`s, and so do not have settings such as stacktraces or 
>> thresholds.
>> 
>> The inclusion of JFR structs in `JfrNativeSettings` was problematic because 
>> it could cause a displacement between event ID and`JfrNativeSettings` array 
>> index (each index is meant to correspond with a specific event ID).
>> 
>> Testing:
>> - jdk/jdk/jfr
>> - tier1
>
> What drives the settings system is Java where the event name is linked to the 
> ID, not the enum, e.g. 
> 
>jdk.jfr.internal.JVM.setEnabled(eventTypeId, enabled);
> 
> If the type IDs are assigned in the order they appear in metadata.xml, then 
> there will (or can) be holes. If GenerateJfrFiles.java makes sure native 
> event types are processed first and then structs, we should be fine.

Thank you for the review @egahlin !

-

PR Comment: https://git.openjdk.org/jdk/pull/19891#issuecomment-2194648286

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v6]

[Fei Gao]

On Thu, 6 Jun 2024 07:52:02 GMT, Hamlin Li  wrote:

>> Hamlin Li has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   update header files for arm
>
> in progress...

Hi @Hamlin-Li , thanks for your work.

I tried to run benchmarks, 
[FloatMaxVector](https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/FloatMaxVector.java#L1068)
 and 
[DoubleMaxVector](https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/DoubleMaxVector.java#L1068),
 on different aarch64 machines.

Here is the data I got for `TANH`, with args `-i 5 -f 3 -wi 3 -foe true 
-jvmArgs -Xms4g -Xmx4g -XX:+AlwaysPreTouch -XX:ObjectAlignmentInBytes=16`:


// NEON machine
Benchmark (size)   Mode Cnt  Units Perf gain
DoubleMaxVector.TANH   1024thrpt15   ops/ms -38%
FloatMaxVector.TANH1024thrpt15   ops/ms -26%



// 128-bit sve machine (TANH also implemented with NEON)
Benchmark (size)   Mode Cnt  Units Perf gain
DoubleMaxVector.TANH   1024thrpt15ops/ms-19%
FloatMaxVector.TANH1024thrpt15ops/ms~00%


The performance of vector stubs for `TANH` looks not quite stable on different 
NEON machines. Since this pr does not provide `TANH` interface on sve machines 
for [the performance 
regression](https://github.com/openjdk/jdk/pull/16234/commits/2a7730d6acbac80438a43d1502cff6a476f8b5b5#diff-9112056f732229b18fec48fb0b20a3fe824de49d0abd41fbdb4202cfe70ad114R8521-R8525),
 how about also disabling it on NEON for the same reason? WDYT? 

Thanks.

-

PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2194480996

Is anyone able to build the JDK on Windows using VirtualBox to host Ubuntu?

[Anil]

I want to try out a small contribution to the JDK and want to build the JDK
first.
I have a Windows 11 laptop.

I am not comfortable with the Windows commands and someone mentioned in
this forum that most of the building is done on Linux.
So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was getting
black screens and freezing. I downgraded the Ubuntu to 222.04 and still got
black screens. I don't know why this is happening.
Any advice appreciated.
Anil

On Tue, Jun 18, 2024, 7:25 PM Anil <1dropafl...@gmail.com> wrote:

> Hello,
> I want to try out a small contribution to the JDK and wanted to
> build the JDK first,
> before I change the code.
> I forked and cloned the jdk following the instructions at The OpenJDK
> Developers' Guide – OpenJDK Developers’ Guide
> 
>
> I am on Windows 11.
> These instructions are given on the page but I am unsure which of these to
> execute since I have already forked and cloned the git repo
>
> $ wget 
> https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz
> $ tar xzf openjdk-16_linux-x64_bin.tar.gz
> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev 
> libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev 
> libfontconfig1-dev libasound2-dev
> $ cd jdk
> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/
> $ make images
>
>
> Do I still need to do the wget?
> Also, I wondered if I should use book jdk-17 instead of jdk-16 as in the
> instructions above.
> thanks,
> Anil
>
>

Re: RFR: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? [v6]

[Kim Barrett]

On Thu, 27 Jun 2024 01:34:36 GMT, Jan Kratochvil  
wrote:

>> fastdebug:
>> 
>> 
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error 
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>>  pid=878152, tid=878158
>> #  assert(_thread->is_in_live_stack((address)this)) failed: not on stack?
>> #
>> # JRE version:  (24.0) (fastdebug build )
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 
>> 24-internal-adhoc.azul.openjdk-git, mixed mode, tiered, compressed oops, 
>> compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x1d20658]  constantPoolHandle::constantPoolHandle(Thread*, 
>> ConstantPool*)+0x268
>
> Jan Kratochvil has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   New comment about MSVC having the option off by default

Looks good.

-

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19843#pullrequestreview-2144736037

Re: RFR: 8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack? [v5]

[Kim Barrett]

On Thu, 27 Jun 2024 01:48:23 GMT, Jan Kratochvil  
wrote:

>> make/autoconf/jdk-options.m4 line 449:
>> 
>>> 447:   if test "x$TOOLCHAIN_TYPE" = "xclang"; then
>>> 448: ASAN_CFLAGS="$ASAN_CFLAGS 
>>> -fsanitize-address-use-after-return=never"
>>> 449:   fi
>> 
>> There's no change being made for the microsoft toolchain.  It seems like the 
>> same issues with the fake stack
>> should arise there.
>
> So I have tried it in AWS and added the [new 
> comment](https://github.com/openjdk/jdk/pull/19843/commits/08153d9cf2ab8d0721fc1f257f9d662de4814212)
>  about it as MSVC has it off by default.
> [Microsoft 
> documentation](https://learn.microsoft.com/en-us/cpp/sanitizers/error-stack-use-after-return?view=msvc-170)
>  even implies it is off by default.
> But I have filed [JDK-8335228](https://bugs.openjdk.org/browse/JDK-8335228) 
> as the MS-Windows OpenJDK build crashes if one explicitly enables 
> `-fsanitize-address-use-after-return` there.

I guess we'll have to monitor this in future VS updates, which might start 
enabling it.  But this seems okay for now.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19843#discussion_r1656755840