Re: RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v3]

2025-04-16 Thread Hao Sun
On Thu, 17 Apr 2025 03:13:05 GMT, Nicole Xu wrote: >> The UnsafeOps JMH benchmark fails with the following error: >> >> ``` >> java.lang.IllegalAccessError: class >> org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot >> access class jdk.internal.misc.Unsafe

Re: RFR: 8349943: [JMH] Use jvmArgs consistently

2025-02-19 Thread Hao Sun
On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote: > As is suggested in > [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should > be used consistently in microbenchmarks to 'align with the intuition that > when you use jvmArgsAppend/-Prepend intent is to add to a set of

Re: RFR: 8349184: [JMH] jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on linux-aarch64 [v2]

2025-02-02 Thread Hao Sun
On Mon, 3 Feb 2025 04:16:57 GMT, SendaoYan wrote: >> Hi all, >> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on >> linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform. >> This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run >> normally o

Re: [jdk24] RFR: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate fails NoClassDefFoundError

2025-02-02 Thread Hao Sun
On Tue, 7 Jan 2025 15:14:18 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [4d8fb807](https://github.com/openjdk/jdk/commit/4d8fb80732fd17352c36254c6dfc1be5dbfbacf1) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24. > > The commi

Re: RFR: 8349184: [JMH] jdk.incubator.vector.ColumnFilterBenchmark.filterDoubleColumn fails on linux-aarch64

2025-02-02 Thread Hao Sun
On Sat, 1 Feb 2025 14:37:44 GMT, SendaoYan wrote: > Hi all, > Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64. > The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add > option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non >

Re: RFR: 8342103: C2 compiler support for Float16 type and associated operations

2024-11-24 Thread Hao Sun
On Mon, 25 Nov 2024 01:07:43 GMT, Hao Sun wrote: > > Hi @shqking , thanks for your review. I am currently working on adding the > > aarch64 port for these operations. It's being done here - > > [jatin-bhateja#6](https://github.com/jatin-bhateja/jdk/pull/6). Do you &g

Re: RFR: 8342103: C2 compiler support for Float16 type and associated operations

2024-11-24 Thread Hao Sun
On Thu, 21 Nov 2024 02:41:47 GMT, Hao Sun 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

Re: RFR: 8342103: C2 compiler support for Float16 type and associated operations

2024-11-20 Thread Hao Sun
On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja 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 vario

Integrated: 8320131: Zero build fails on macOS after JDK-8254693

2023-11-21 Thread Hao Sun
On Wed, 22 Nov 2023 02:06:29 GMT, Hao Sun wrote: > The fix is trivial. We should include the standard C header `stdlib.h` [1], > rather than non-standard one `malloc.h`. > > [1] https://en.cppreference.com/w/c/memory/malloc This pull request has now been integrated. Changes

Re: RFR: 8320131: Zero build fails on macOS after JDK-8254693

2023-11-21 Thread Hao Sun
On Wed, 22 Nov 2023 02:06:29 GMT, Hao Sun wrote: > The fix is trivial. We should include the standard C header `stdlib.h` [1], > rather than non-standard one `malloc.h`. > > [1] https://en.cppreference.com/w/c/memory/malloc Thanks for your reviews. - PR Co

RFR: 8320131: Zero build fails on macOS after JDK-8254693

2023-11-21 Thread Hao Sun
The fix is trivial. We should include the standard C header `stdlib.h` [1], rather than non-standard one `malloc.h`. [1] https://en.cppreference.com/w/c/memory/malloc - Commit messages: - 8320131: Zero build fails on macOS after JDK-8254693 Changes: https://git.openjdk.org/jdk/pul

Integrated: 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c

2022-09-26 Thread Hao Sun
On Thu, 22 Sep 2022 07:02:16 GMT, Hao Sun wrote: > This warning seems to be a false positive, because 1) array "fq" with > elements from index 0 to "jz" has already been initialized as "fw" at line > 290 [1], and 2) variable "jz" should

Re: RFR: 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]

2022-09-26 Thread Hao Sun
On Mon, 26 Sep 2022 01:39:41 GMT, Hao Sun wrote: >> This warning seems to be a false positive, because 1) array "fq" with >> elements from index 0 to "jz" has already been initialized as "fw" at line >> 290 [1], and 2) variable "jz"

Re: RFR: 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]

2022-09-25 Thread Hao Sun
On Fri, 23 Sep 2022 12:47:24 GMT, Magnus Ihse Bursie wrote: >> Thanks for your review. >> >> Your mentioned solution should work and we can also enable the pragma only >> for aarch64 + gcc>=12 condition. >> I considered such a solution when preparing this patch. >> >> But I personally prefer t

Re: RFR: 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c [v2]

2022-09-25 Thread Hao Sun
s://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290 > > [2] > https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99 > > [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992 Hao Sun has updated the p

Re: RFR: 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c

2022-09-23 Thread Hao Sun
On Thu, 22 Sep 2022 09:35:47 GMT, Andrew Haley wrote: >> This warning seems to be a false positive, because 1) array "fq" with >> elements from index 0 to "jz" has already been initialized as "fw" at line >> 290 [1], and 2) variable "jz" should be non-negative from the comment at >> line 99 [2

RFR: 8293887: AArch64 build failure with GCC 12 due to maybe-uninitialized warning in libfdlibm k_rem_pio2.c

2022-09-22 Thread Hao Sun
This warning seems to be a false positive, because 1) array "fq" with elements from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and 2) variable "jz" should be non-negative from the comment at line 99 [2]. Note-1: GCC warning option -Wmaybe-uninitialized is not a new one