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

2023-12-04 Thread Xiaohong Gong
On Fri, 1 Dec 2023 16:36:18 GMT, Magnus Ihse Bursie wrote: >> You need to expand this logic to cover more instances. See e.g. lib-ffi.m4 >> for inspiration. >> >> Basic flow: >> * if user has specified libsleef root with argument, check both lib/ and >> lib64/ under that root. >> * if user

Re: RFR: JDK-8319413: Start of release updates for JDK 23 [v5]

2023-12-04 Thread Iris Clark
On Tue, 5 Dec 2023 01:48:14 GMT, Joe Darcy wrote: >> Time to start making preparations for JDK 23. > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into JDK-8319413 > - Add

Re: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]

2023-12-04 Thread Iris Clark
On Sat, 2 Dec 2023 20:40:57 GMT, Andrey Turbanov wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update symbol files to JDK 22 b26. > > test/langtools/tools/javac/versions/Versions.java line 97: > >> 95:

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

2023-12-04 Thread Xiaohong Gong
On Mon, 4 Dec 2023 08:31:17 GMT, Xiaohong Gong wrote: >> The final thing we need to resolve properly is the SVE compiler test. >> >> @theRealAph says: >>> arm_sve.h is part of GCC. It was added to GCC in 2019. >> >> A more relevant question is what version of gcc it was added, and if that >>

Re: RFR: JDK-8319413: Start of release updates for JDK 23 [v5]

2023-12-04 Thread Joe Darcy
> Time to start making preparations for JDK 23. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'master' into JDK-8319413 - Add symbol files. - Merge branch 'master' into JDK-8319413 - Merge

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v8]

2023-12-04 Thread Srinivas Vamsi Parasa
On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX2 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v8]

2023-12-04 Thread Sandhya Viswanathan
On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX2 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >>

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v8]

2023-12-04 Thread Srinivas Vamsi Parasa
On Mon, 4 Dec 2023 11:48:44 GMT, Magnus Ihse Bursie wrote: >>> But you are saying that you want to skip building this library unless you >>> have a gcc version that supports c++17? >>> >> Yes, the request is to skip building the simdsort library if GCC version is >> < 8 as only GCC >= 8

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v8]

2023-12-04 Thread Srinivas Vamsi Parasa
> The goal is to develop faster sort routines for x86_64 CPUs by taking > advantage of AVX2 instructions. This enhancement provides an order of > magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v7]

2023-12-04 Thread Srinivas Vamsi Parasa
> The goal is to develop faster sort routines for x86_64 CPUs by taking > advantage of AVX2 instructions. This enhancement provides an order of > magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x

Re: RFR: 8321224: ct.sym for JDK 22 contains references to internal modules [v2]

2023-12-04 Thread Jan Lahoda
On Mon, 4 Dec 2023 11:39:04 GMT, Magnus Ihse Bursie wrote: >> Jan Lahoda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from >> CT_MODULES. > >

Re: RFR: 8321224: ct.sym for JDK 22 contains references to internal modules [v2]

2023-12-04 Thread Jan Lahoda
> As part of: > https://github.com/openjdk/jdk/pull/16505 > > there are new symbol files for JDK 22, and @jddarcy noted the content looks > weird. > > I was investigating, and found a few problems, some introduced by >

Re: RFR: 8321224: ct.sym for JDK 22 contains references to internal modules

2023-12-04 Thread Vicente Romero
On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda wrote: > As part of: > https://github.com/openjdk/jdk/pull/16505 > > there are new symbol files for JDK 22, and @jddarcy noted the content looks > weird. > > I was investigating, and found a few problems, some introduced by >

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

2023-12-04 Thread Magnus Ihse Bursie
On Mon, 4 Dec 2023 08:31:17 GMT, Xiaohong Gong wrote: >> The final thing we need to resolve properly is the SVE compiler test. >> >> @theRealAph says: >>> arm_sve.h is part of GCC. It was added to GCC in 2019. >> >> A more relevant question is what version of gcc it was added, and if that >>

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

2023-12-04 Thread Magnus Ihse Bursie
On Fri, 1 Dec 2023 16:49:28 GMT, Andrew Haley wrote: >> Oh, and: >> >> If we can't trust SLEEF not to break the ABI we're using, we should not be >> using SLEEF. > >> @theRealAph You are making good points. >> >> You are basically saying: "we don't need any configure support for libsleef, >>

Re: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v6]

2023-12-04 Thread Magnus Ihse Bursie
On Thu, 30 Nov 2023 20:19:56 GMT, Srinivas Vamsi Parasa wrote: >> Raising the minimum gcc version is not done willy-nilly. (I feel a "You just >> don't ..." meme coming up) >> >> But you are saying that you want to skip building this library unless you >> have a gcc version that supports

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v45]

2023-12-04 Thread Magnus Ihse Bursie
On Mon, 4 Dec 2023 11:33:09 GMT, Julian Waters wrote: >> make/autoconf/flags-cflags.m4 line 565: >> >>> 563: # The -utf-8 option sets source and execution character sets to >>> UTF-8 to enable correct >>> 564: # compilation of all source files regardless of the active code >>> page on

Re: RFR: 8321224: ct.sym for JDK 22 contains references to internal modules

2023-12-04 Thread Magnus Ihse Bursie
On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda wrote: > As part of: > https://github.com/openjdk/jdk/pull/16505 > > there are new symbol files for JDK 22, and @jddarcy noted the content looks > weird. > > I was investigating, and found a few problems, some introduced by >

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v45]

2023-12-04 Thread Julian Waters
On Mon, 4 Dec 2023 11:29:07 GMT, Magnus Ihse Bursie wrote: >> Julian Waters has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 78 commits: >> >> - Merge branch 'openjdk:master' into patch-10 >> - Fix awt_Window.cpp >> - Fix

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v45]

2023-12-04 Thread Magnus Ihse Bursie
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as >> was requested by the now backed out >> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes >> the Visual C compiler much less

Re: RFR: 8211238: @Deprecated JFR event [v8]

2023-12-04 Thread Markus Grönlund
On Sun, 3 Dec 2023 16:44:28 GMT, Markus Grönlund wrote: >> A question about "level". Is the intention that the value can be anything, >> e.g. some new event next month might use the values "1", "2, "3"? Just >> asking because ordinarily deprecated vs. terminally deprecated is very >> specific

Re: RFR: 8211238: @Deprecated JFR event [v8]

2023-12-04 Thread Jaroslav Bachorik
On Sun, 3 Dec 2023 16:44:28 GMT, Markus Grönlund wrote: >> A question about "level". Is the intention that the value can be anything, >> e.g. some new event next month might use the values "1", "2, "3"? Just >> asking because ordinarily deprecated vs. terminally deprecated is very >> specific

Re: RFR: 8211238: @Deprecated JFR event [v9]

2023-12-04 Thread Markus Grönlund
> Greetings, > > please help review this enhancement to add a JFR event to report runtime > invocations of methods that have been declared deprecated in the JDK. > > Testing: jdk_jfr, CI 1-6, stress testing > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v45]

2023-12-04 Thread Julian Waters
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as >> was requested by the now backed out >> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes >> the Visual C compiler much less

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

2023-12-04 Thread Xiaohong Gong
On Fri, 1 Dec 2023 16:45:49 GMT, Magnus Ihse Bursie wrote: > The final thing we need to resolve properly is the SVE compiler test. > > @theRealAph says: > > > arm_sve.h is part of GCC. It was added to GCC in 2019. > > A more relevant question is what version of gcc it was added, and if that