From xgong at openjdk.org  Fri Dec  1 01:16:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 1 Dec 2023 01:16:15 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
Message-ID: <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>

On Thu, 30 Nov 2023 11:13:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename vmath to sleef in configure
>
> make/autoconf/lib-sleef.m4 line 56:
> 
>> 54:         AC_MSG_CHECKING([for the specified LIBSLEEF])
>> 55:         if test -e ${with_libsleef}/lib/libsleef.so &&
>> 56:            test -e ${with_libsleef}/include/sleef.h; then
> 
> This fails on my system because libsleef is in `/usr/local/lib64/`. This is the correct place to look according to the Linux FHS. You should _not_ hard-code `/lib`

Did you try to find the libsleef by passing `--with-libsleef=` ? Currently `--with-libsleef=` can only work for people manually built from sleef source code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1411488447

From xgong at openjdk.org  Fri Dec  1 01:22:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 1 Dec 2023 01:22:15 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <WsVnzofMlpBbTX3sKjOxbdkOxpujdPyNv7VlPZ9g72M=.04bb24ee-ec4f-48ba-bc8d-a4ee68b0eedf@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <WsVnzofMlpBbTX3sKjOxbdkOxpujdPyNv7VlPZ9g72M=.04bb24ee-ec4f-48ba-bc8d-a4ee68b0eedf@github.com>
Message-ID: <WXWoaO4OuJ9zqTe9JxFuVEML97LM84F_XUdFuEKNZBA=.79a6e865-a699-4b02-8464-93f6a470f0a1@github.com>

On Thu, 30 Nov 2023 20:13:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Not having a build time dependency on libsleef means you cannot really verify that the functions you want to call are correct, but maybe you feel secure that they will never change?

I'm not sure. The main reason that we add such a wrapper library is to catch the sleef's ABI version changing earlier (i.e. at build time). So using .s code and not including sleef at built time can not match this requirement?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835248759

From xgong at openjdk.org  Fri Dec  1 01:33:12 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 1 Dec 2023 01:33:12 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
Message-ID: <XHN46bYotm3S0YdY5J3Uea28KgaFpRKCEPxFGv2CmHc=.9e3f0d53-f0ab-453a-9a47-1f82f2bc87fe@github.com>

On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename vmath to sleef in configure

> Okay, now I found a few more of your comments that I missed before. I apologize, the Github PR review UI can be a bit confusing when discussions are taking place in multiple locations. So, here's a revision to my list above:
> 
> 1. An aach64 CPU can have both Neon and SVE present at the same time.
> 2. You are assuming that Neon is always present, and what I referred to as the fallback case is in fact using Neon instead of SVE.
> 3. You would like to split vect_math.c into two parts, e.g.  vect_math_neon.c and vect_math_sve.c.
> 4. You will then, use heuristics in hotspot to determine at runtime if SVE or Neon functionality should be used.  Even if SVE is present on the runtime machine, heuristics can chose to use the Neon implementation anyway in some cases.
> 5. Only vect_math_sve.c. need the -march+sve.

Yes, all the above are true.

> 6. The neon part do not need the -march+sve flag, and will fail if built with this flag. (???)

Current neon code does not need the `-march=arm-a+sve` flag, but it will not fail if we built with it. Because the C compiler (GCC/Clang) can also supports SVE and NEON at the same time. My concert is that if we build the neon code with sve flags,  it has the possibility that compiler may generate SVE specific instructions inside the NEON functions in future (e.g. if sve has new features related to method call) , although it doesn't happen now. If so, calling the neon stubs (which contains sve instructions) on non-sve supported machines in runtime may crash. Hence, it's more safe if we can separate neon and sve code and use different flags for them.


> Anyway, it is straightforward to add compiler flags to individual files. You do it like this:
> 
> $(eval $(call SetupJdkLibrary, BUILD_LIBVMATH, \
      NAME := vmath, \
      CFLAGS := $(CFLAGS_JDKLIB) $(LIBSLEEF_CFLAGS) -fvisibility=default, \
      vect_math_sve.c_CFLAGS := $(SVE_CFLAGS), \
 ...

Thanks so much for this. That's very helpful!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835258683

From xgong at openjdk.org  Fri Dec  1 08:48:52 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 1 Dec 2023 08:48:52 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

Xiaohong Gong 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 ten additional commits since the last revision:

 - Separate neon and sve functions into two source files
 - Merge branch 'jdk:master' into JDK-8312425
 - Rename vmath to sleef in configure
 - Address review comments in build system
 - Add a bundled native lib in jdk as a bridge to libsleef
 - Merge 'jdk:master' into JDK-8312425
 - Disable sleef by default
 - Merge 'jdk:master' into JDK-8312425
 - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16234/files
  - new: https://git.openjdk.org/jdk/pull/16234/files/c1ce1968..ee5caf6d

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

  Stats: 638331 lines in 1866 files changed: 100400 ins; 474467 del; 63464 mod
  Patch: https://git.openjdk.org/jdk/pull/16234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16234/head:pull/16234

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

From alanb at openjdk.org  Fri Dec  1 08:57:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Dec 2023 08:57:05 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files to JDK 22 b26.

Good good. I assume you'll bump the copyright header on the files that need it before integration, e.g. JavacTestingAbstractProcessor.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1759306298

From aph at openjdk.org  Fri Dec  1 10:00:14 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:00:14 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <U5tslVEJqPTFCqtp_apAwmECDHvE0UOE7xN3l0KU70M=.f11ab8e8-7b8f-4603-937a-cf395cb10c5d@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <8SBUvWGDLtQmwYPRBDeUkeuq4pf2nJfKfDY5rzZODFU=.3f1cc0ff-02e6-4a4e-9425-5ffccc9cbc8f@github.com>
 <U5tslVEJqPTFCqtp_apAwmECDHvE0UOE7xN3l0KU70M=.f11ab8e8-7b8f-4603-937a-cf395cb10c5d@github.com>
Message-ID: <SpmEywJ-EtFMxPwE2pFHnwlPS5ZHfUUcuj2nM5ui06k=.caee3bc9-4bce-4fc8-b369-691f9b2fae54@github.com>

On Thu, 30 Nov 2023 14:50:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Do this, but with the name vect_math.S. Don't use SLEEF headers in the build. I think you can do this with no build-time dependency on SLEEF at all if you load the library lazily at runtime.
>> 
>> [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt)
>
>> [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt)
> 
> I guess this will live only in os_linux and os_bsd because the Windows compiler won't like it AFAIK.

> @theRealAph So your suggestion is that this assembly files lives in hotspot, instead of jdk.incubator.vector?

I don't think it much matters, because these functions will only be available to HotSpot.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835801386

From aph at openjdk.org  Fri Dec  1 10:05:19 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:05:19 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <WXWoaO4OuJ9zqTe9JxFuVEML97LM84F_XUdFuEKNZBA=.79a6e865-a699-4b02-8464-93f6a470f0a1@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <WsVnzofMlpBbTX3sKjOxbdkOxpujdPyNv7VlPZ9g72M=.04bb24ee-ec4f-48ba-bc8d-a4ee68b0eedf@github.com>
 <WXWoaO4OuJ9zqTe9JxFuVEML97LM84F_XUdFuEKNZBA=.79a6e865-a699-4b02-8464-93f6a470f0a1@github.com>
Message-ID: <GKVDsKAo5D0GxwenweAGcQXem0-t6Jk80VhUoFciNw0=.b4886d75-1155-42f8-950d-d7500f628732@github.com>

On Fri, 1 Dec 2023 01:19:12 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Not having a build time dependency on libsleef means you cannot really verify that the functions you want to call are correct, but maybe you feel secure that they will never change?
> 
> I'm not sure. The main reason that we add such a wrapper library is to catch the sleef's ABI version changing earlier (i.e. at build time). So using .s code and not including sleef at built time can not match this requirement?

I don't know what this means. If we're using an external SLEEF, then we can't catch ABI versions changes at build time.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835805290

From aph at openjdk.org  Fri Dec  1 10:05:23 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:05:23 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
Message-ID: <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>

On Fri, 1 Dec 2023 01:13:37 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> make/autoconf/lib-sleef.m4 line 56:
>> 
>>> 54:         AC_MSG_CHECKING([for the specified LIBSLEEF])
>>> 55:         if test -e ${with_libsleef}/lib/libsleef.so &&
>>> 56:            test -e ${with_libsleef}/include/sleef.h; then
>> 
>> This fails on my system because libsleef is in `/usr/local/lib64/`. This is the correct place to look according to the Linux FHS. You should _not_ hard-code `/lib`
>
> Did you try to find the libsleef by passing `--with-libsleef=` ? Currently `--with-libsleef=` can only work for people manually built from sleef source code.

Yes. It still failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1411877145

From aph at openjdk.org  Fri Dec  1 10:08:11 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:08:11 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <GKVDsKAo5D0GxwenweAGcQXem0-t6Jk80VhUoFciNw0=.b4886d75-1155-42f8-950d-d7500f628732@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <WsVnzofMlpBbTX3sKjOxbdkOxpujdPyNv7VlPZ9g72M=.04bb24ee-ec4f-48ba-bc8d-a4ee68b0eedf@github.com>
 <WXWoaO4OuJ9zqTe9JxFuVEML97LM84F_XUdFuEKNZBA=.79a6e865-a699-4b02-8464-93f6a470f0a1@github.com>
 <GKVDsKAo5D0GxwenweAGcQXem0-t6Jk80VhUoFciNw0=.b4886d75-1155-42f8-950d-d7500f628732@github.com>
Message-ID: <bT3yG7Pt3b1aX7LruU5oNjHpoiHo2sj_fUJ3UhfPfOE=.1db43dbc-bfa3-401f-b889-ab855facfdae@github.com>

On Fri, 1 Dec 2023 09:59:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Not having a build time dependency on libsleef means you cannot really verify that the functions you want to call are correct, but maybe you feel secure that they will never change?

We can still have SLEEF tests, but they will require a SLEEF library to be there. We can't control what is present at runtime, though. What are you trying to verify?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835812963

From aph at openjdk.org  Fri Dec  1 10:19:16 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:19:16 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <Syv4IWJ121JzIDObF0lqtO8OwFRhrbtRk1BLstaXbAw=.cce3e27b-c5d8-4d00-9d66-5104d34eefa2@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong 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 ten additional commits since the last revision:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

Let me summarize the issues, as I see them:

To a high-order approximation, no one builds their own JDK.
We want people to be able to use these vector math operations.
There is no need to depend on a specific SLEEF library version.
I do not expect SLEEF to break the ABI by e.g. renaming functions. (I know, but let's assume.)
As long as the functions we want to use are present, we should use them.
SLEEF is not (yet) a standard part of OSs and build systems.

We don't want to fail unnecessarily at runtime because of a SLEEF ABI version change.
We don't want to fail to build the JDK if our GCC is too old for SVE. (Is that a problem now? It might be.)
We want to be able to test and run with any version of SLEEF, as long as the functions we need are present.

It should be possible to drop a SLEEF library into the system, and the JDK will use it.
The alternative is to package SLEEF with the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835829658

From aph at openjdk.org  Fri Dec  1 10:22:21 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 10:22:21 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong 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 ten additional commits since the last revision:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

Oh, and:

If we can't trust SLEEF not to break the ABI we're using, we should not be using SLEEF.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1835833150

From clanger at openjdk.org  Fri Dec  1 12:45:10 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 1 Dec 2023 12:45:10 GMT
Subject: RFR: 8320931: [REDO] dsymutil command leaves around temporary
 directories [v2]
In-Reply-To: <Kc1DoksHzi_5d6ofBcx1dJPw48G6JZk2V2okdDm6TsI=.d557c594-171f-44cc-9dc2-802939712ffe@github.com>
References: <AoHrCiII4brHRjSxjyF3n7WiX2ZK85A5PSPrtiurEx8=.a7b3b086-827d-4f91-9e63-03729018b536@github.com>
 <Kc1DoksHzi_5d6ofBcx1dJPw48G6JZk2V2okdDm6TsI=.d557c594-171f-44cc-9dc2-802939712ffe@github.com>
Message-ID: <bPBvQbCo8-TAzdYHOv8uBB_gMeClUbnr15xMqWFJxGA=.a371a76f-227b-4b1f-9cef-d73ddea515b9@github.com>

On Thu, 30 Nov 2023 09:39:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change will attempts to workaround an issue in dsymutil?
>> 
>> The previous attempt to use `--reproducer Off` has shown that it fails to build on some other Xcode versions other than 14.3.1. Users have reported it to fail on  Xcode 15.0.1 and Xcode from a 12.4 devkit. The `--reproducer` option isn't being recognized on those versions.
>> 
>> This current PR proposes to use an alternate workaround, one which just sets an environment variable that Xcode 14.3.1 recognizes and prevents the creation of the leftover `dsymutil-*` temporary directories. Since this new approach uses an environment variable to workaround the issue, the command itself shouldn't ideally run into any usage issues. Once we agree upon this change, before integrating, I'll ask for inputs from those who had run into build issues to verify this alternate approach doesn't cause problems.
>> 
>> I have locally verified that this new approach continues to work and doesn't create those temporary directories. Additionally tier1, tier2, tier3 has completed successfully in our CI environment with this change.
>> 
>> Magnus, Erik, I looked around to see if there's any convention in setting such environment variables that will be used when invoking external tools during the build. I didn't find any similar usage. Although the current change in this PR is working, if there's a different and better way to do this, please do let me know.
>
> Jaikiran Pai 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:
> 
>  - check for the support of --reproducer option before using it for dsymutil
>  - merge latest from master branch
>  - 8320931: [REDO] dsymutil command leaves around temporary directories

Looks good, passes SAP's build setup.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16876#pullrequestreview-1759737397

From jpai at openjdk.org  Fri Dec  1 12:45:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Dec 2023 12:45:10 GMT
Subject: RFR: 8320931: [REDO] dsymutil command leaves around temporary
 directories [v2]
In-Reply-To: <Kc1DoksHzi_5d6ofBcx1dJPw48G6JZk2V2okdDm6TsI=.d557c594-171f-44cc-9dc2-802939712ffe@github.com>
References: <AoHrCiII4brHRjSxjyF3n7WiX2ZK85A5PSPrtiurEx8=.a7b3b086-827d-4f91-9e63-03729018b536@github.com>
 <Kc1DoksHzi_5d6ofBcx1dJPw48G6JZk2V2okdDm6TsI=.d557c594-171f-44cc-9dc2-802939712ffe@github.com>
Message-ID: <IV7REVkTPYgg5YgGiV6KapaB7SOFbjWY5iZQrXa5PSs=.4b324cc6-183d-4e33-b330-e0c8dc8e3de1@github.com>

On Thu, 30 Nov 2023 09:39:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change will attempts to workaround an issue in dsymutil?
>> 
>> The previous attempt to use `--reproducer Off` has shown that it fails to build on some other Xcode versions other than 14.3.1. Users have reported it to fail on  Xcode 15.0.1 and Xcode from a 12.4 devkit. The `--reproducer` option isn't being recognized on those versions.
>> 
>> This current PR proposes to use an alternate workaround, one which just sets an environment variable that Xcode 14.3.1 recognizes and prevents the creation of the leftover `dsymutil-*` temporary directories. Since this new approach uses an environment variable to workaround the issue, the command itself shouldn't ideally run into any usage issues. Once we agree upon this change, before integrating, I'll ask for inputs from those who had run into build issues to verify this alternate approach doesn't cause problems.
>> 
>> I have locally verified that this new approach continues to work and doesn't create those temporary directories. Additionally tier1, tier2, tier3 has completed successfully in our CI environment with this change.
>> 
>> Magnus, Erik, I looked around to see if there's any convention in setting such environment variables that will be used when invoking external tools during the build. I didn't find any similar usage. Although the current change in this PR is working, if there's a different and better way to do this, please do let me know.
>
> Jaikiran Pai 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:
> 
>  - check for the support of --reproducer option before using it for dsymutil
>  - merge latest from master branch
>  - 8320931: [REDO] dsymutil command leaves around temporary directories

Thank you Christoph for running the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/16876#issuecomment-1836058345

From asotona at openjdk.org  Fri Dec  1 13:18:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Dec 2023 13:18:30 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v32]
In-Reply-To: <e0eptru-lnzIXRfqrFBT1fy-oDsLORN-roOsdUzshUY=.68ff8e2b-68fb-4457-94fb-f0623eb3f96a@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com>
 <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com>
 <Fd3Aa-rvhh0iWNFsGnOMCAMPvI5JiesSWh0tvPhPg5M=.379e7492-46d4-41f2-94c6-393b6701cad2@github.com>
 <e0eptru-lnzIXRfqrFBT1fy-oDsLORN-roOsdUzshUY=.68ff8e2b-68fb-4457-94fb-f0623eb3f96a@github.com>
Message-ID: <JOJKj3mt-3DRIVKUTDXwMYvh_g-P9hVax9PZ0MiLcyU=.ab0b0bd2-6101-4f87-bac0-49cc401e8452@github.com>

On Wed, 29 Nov 2023 08:46:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This is explicit list of supported class file versions, so I don't see any other way.
>
> Would it not be possible to expose an immutable `Map<Integer, Integer>` that maps from Java version to major class version?

This is actually out of scope of this PR. Feel free to request a new ClassFile API feature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1412090733

From asotona at openjdk.org  Fri Dec  1 13:46:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Dec 2023 13:46:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v33]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <smvNLtt0YumYsmswb7vrmD5O9V2wVvfR7VCHgtrHg8k=.c6a7c0c7-2984-4041-8a3c-134c2180a318@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 371 commits:

 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - fixed SwitchBootstrapTest
 - fixed SwitchBootstrap and StackMapsTest
 - fixed SwtichBootstrapTest and ModuleVersionTest
 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java
 - added new package-info snippets and fixed ClassFile::parse throws javadoc description
 - fixed lambda tests
 - Merge branch 'master' into JDK-8308753-preview
 - ... and 361 more: https://git.openjdk.org/jdk/compare/3b30095a...b7b2e4e4

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=32
  Stats: 32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

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

From ihse at openjdk.org  Fri Dec  1 15:04:19 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 15:04:19 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
Message-ID: <ROpl3Wa_CZ9NF6W8RDqpx_OAEbFjREBP-56LHF7BO6M=.0cc8d311-a725-4642-87de-e7387a59d059@github.com>

On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xiaohong Gong 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 ten additional commits since the last revision:
>> 
>>  - Separate neon and sve functions into two source files
>>  - Merge branch 'jdk:master' into JDK-8312425
>>  - Rename vmath to sleef in configure
>>  - Address review comments in build system
>>  - Add a bundled native lib in jdk as a bridge to libsleef
>>  - Merge 'jdk:master' into JDK-8312425
>>  - Disable sleef by default
>>  - Merge 'jdk:master' into JDK-8312425
>>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF
>
> 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, we can just hard-code the names and dispatch to them directly to a dlopened library at runtime".

That is technically correct, but I'd still like to argue that the current setup have some merits:

* It will check that there is no typo in the function names. I agree that the likelihood of getting this wrong is low, but it is still a good practice to use official include files to have the compiler help checking this.
* If we would like to bundle libsleef.so with the JVM, now we have the possibility do do so easily. (Especially if it is like you say that it is not commonly installed). (If licenses allow etc)
* If we want to incorporate/bundle the source code of libsleef into OpenJDK, and build it as part of our internal library, we will have a good starting position, compared to starting from a hard-coded assembly file in hotspot. (I thought I heard some noise about this prospect).

So at this point, I am okay with the general approach of this PR. There are still some build issues to sort out, though, I'll address them separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1836266314

From ihse at openjdk.org  Fri Dec  1 16:29:18 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 16:29:18 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <dxnGzEBuDdVHnuYm1AaoTYNjTQzdpHHamkgb3QxEpPc=.7671caf2-74f8-4d6f-8bcf-8f189488bd0a@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong 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 ten additional commits since the last revision:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

doc/building.md line 639:

> 637: 
> 638: libsleef, the [SIMD Library for Evaluating Elementary Functions](
> 639: https://sleef.org/) is required when building libvmath.so on Linux/aarch64

This is incorrect. The library is not required, but if it is present, we will build libvmath with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1412330808

From ihse at openjdk.org  Fri Dec  1 16:39:14 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 16:39:14 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
Message-ID: <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>

On Fri, 1 Dec 2023 10:02:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Did you try to find the libsleef by passing `--with-libsleef=` ? Currently `--with-libsleef=` can only work for people manually built from sleef source code.
>
> Yes. It still failed.

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 has not specified libsleef root, and we have no SYSROOT, try PKG_CHECK
* Otherwise, look in well-known directories which is $SYSROOT/usr/[local/]lib[64].

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1412340745

From ihse at openjdk.org  Fri Dec  1 16:39:15 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 16:39:15 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
 <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
Message-ID: <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>

On Fri, 1 Dec 2023 16:35:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Yes. It still failed.
>
> 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 has not specified libsleef root, and we have no SYSROOT, try PKG_CHECK
> * Otherwise, look in well-known directories which is $SYSROOT/usr/[local/]lib[64].

also, ideally, you will add the corresponding specific overrides like in ffi:

  AC_ARG_WITH(libffi-include, [AS_HELP_STRING([--with-libffi-include],
      [specify directory for the libffi include files])])
  AC_ARG_WITH(libffi-lib, [AS_HELP_STRING([--with-libffi-lib],
      [specify directory for the libffi library])])

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1412341451

From ihse at openjdk.org  Fri Dec  1 16:48:17 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 16:48:17 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong 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 ten additional commits since the last revision:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

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 also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.

I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1836444674

From aph at openjdk.org  Fri Dec  1 16:52:14 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Dec 2023 16:52:14 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
Message-ID: <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>

On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Xiaohong Gong 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 ten additional commits since the last revision:
>> 
>>  - Separate neon and sve functions into two source files
>>  - Merge branch 'jdk:master' into JDK-8312425
>>  - Rename vmath to sleef in configure
>>  - Address review comments in build system
>>  - Add a bundled native lib in jdk as a bridge to libsleef
>>  - Merge 'jdk:master' into JDK-8312425
>>  - Disable sleef by default
>>  - Merge 'jdk:master' into JDK-8312425
>>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF
>
> 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, we can just hard-code the names and dispatch to them directly to a dlopened library at runtime".

Yep.

> That is technically correct, but I'd still like to argue that the current setup have some merits:
> 
>     * It will check that there is no typo in the function names. I agree that the likelihood of getting this wrong is low, but it is still a good practice to use official include files to have the compiler help checking this.
> 
>     * If we would like to bundle libsleef.so with the JVM, now we have the possibility do do so easily. (Especially if it is like you say that it is not commonly installed). (If licenses allow etc)
> 
>     * If we want to incorporate/bundle the source code of libsleef into OpenJDK, and build it as part of our internal library, we will have a good starting position, compared to starting from a hard-coded assembly file in hotspot. (I thought I heard some noise about this prospect).
> 
> 
> So at this point, I am okay with the general approach of this PR. There are still some build issues to sort out, though, I'll address them separately.

I see, OK. The question in my mind is whether the common builds of OpenJDK (Oracle, Adoptium, etc.) will support running with SLEEF. If by default SLEEF is not required, support won't be built, and (to an nth order approximation) no one will use it. But I guess it's better than nothing.

Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support?

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1836449876

From ihse at openjdk.org  Fri Dec  1 17:03:10 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Dec 2023 17:03:10 GMT
Subject: RFR: 8320931: [REDO] dsymutil command leaves around temporary
 directories [v2]
In-Reply-To: <Kc1DoksHzi_5d6ofBcx1dJPw48G6JZk2V2okdDm6TsI=.d557c594-171f-44cc-9dc2-802939712ffe@github.com>
References: <AoHrCiII4brHRjSxjyF3n7WiX2ZK85A5PSPrtiurEx8=.a7b3b086-827d-4f91-9e63-03729018b536@github.com>
 <Kc1DoksHzi_5d6ofBcx1dJPw48G6JZk2V2okdDm6TsI=.d557c594-171f-44cc-9dc2-802939712ffe@github.com>
Message-ID: <gmxjJXip_8OdUY2fOHZQO8rJkZwDvFOQBkuobP1FGdw=.fda3d9fa-10f0-4f51-9d58-da8cc42d62ec@github.com>

On Thu, 30 Nov 2023 09:39:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change will attempts to workaround an issue in dsymutil?
>> 
>> The previous attempt to use `--reproducer Off` has shown that it fails to build on some other Xcode versions other than 14.3.1. Users have reported it to fail on  Xcode 15.0.1 and Xcode from a 12.4 devkit. The `--reproducer` option isn't being recognized on those versions.
>> 
>> This current PR proposes to use an alternate workaround, one which just sets an environment variable that Xcode 14.3.1 recognizes and prevents the creation of the leftover `dsymutil-*` temporary directories. Since this new approach uses an environment variable to workaround the issue, the command itself shouldn't ideally run into any usage issues. Once we agree upon this change, before integrating, I'll ask for inputs from those who had run into build issues to verify this alternate approach doesn't cause problems.
>> 
>> I have locally verified that this new approach continues to work and doesn't create those temporary directories. Additionally tier1, tier2, tier3 has completed successfully in our CI environment with this change.
>> 
>> Magnus, Erik, I looked around to see if there's any convention in setting such environment variables that will be used when invoking external tools during the build. I didn't find any similar usage. Although the current change in this PR is working, if there's a different and better way to do this, please do let me know.
>
> Jaikiran Pai 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:
> 
>  - check for the support of --reproducer option before using it for dsymutil
>  - merge latest from master branch
>  - 8320931: [REDO] dsymutil command leaves around temporary directories

I have now tested this with Xcode 15.0 as well and confirm that it works. I think this means that you can safely integrate now.

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

PR Comment: https://git.openjdk.org/jdk/pull/16876#issuecomment-1836464615

From vromero at openjdk.org  Fri Dec  1 18:34:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Dec 2023 18:34:05 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <xWX4clN3bYSCxLaE03Oi4g8D5jDDJNh9zdN5jN3CGmU=.9ee00d2d-6115-40a8-800a-5d5bb67ddf4d@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol files to JDK 22 b26.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1760367216

From jpai at openjdk.org  Sat Dec  2 05:41:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Dec 2023 05:41:45 GMT
Subject: RFR: 8320931: [REDO] dsymutil command leaves around temporary
 directories [v2]
In-Reply-To: <Kc1DoksHzi_5d6ofBcx1dJPw48G6JZk2V2okdDm6TsI=.d557c594-171f-44cc-9dc2-802939712ffe@github.com>
References: <AoHrCiII4brHRjSxjyF3n7WiX2ZK85A5PSPrtiurEx8=.a7b3b086-827d-4f91-9e63-03729018b536@github.com>
 <Kc1DoksHzi_5d6ofBcx1dJPw48G6JZk2V2okdDm6TsI=.d557c594-171f-44cc-9dc2-802939712ffe@github.com>
Message-ID: <CymrL7WSlXM0rnnMti9R6pHZnmEfA-zIrM9RJgRYvZ4=.83d0ef4d-15d1-47b9-914f-a5aad228bfcf@github.com>

On Thu, 30 Nov 2023 09:39:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change will attempts to workaround an issue in dsymutil?
>> 
>> The previous attempt to use `--reproducer Off` has shown that it fails to build on some other Xcode versions other than 14.3.1. Users have reported it to fail on  Xcode 15.0.1 and Xcode from a 12.4 devkit. The `--reproducer` option isn't being recognized on those versions.
>> 
>> This current PR proposes to use an alternate workaround, one which just sets an environment variable that Xcode 14.3.1 recognizes and prevents the creation of the leftover `dsymutil-*` temporary directories. Since this new approach uses an environment variable to workaround the issue, the command itself shouldn't ideally run into any usage issues. Once we agree upon this change, before integrating, I'll ask for inputs from those who had run into build issues to verify this alternate approach doesn't cause problems.
>> 
>> I have locally verified that this new approach continues to work and doesn't create those temporary directories. Additionally tier1, tier2, tier3 has completed successfully in our CI environment with this change.
>> 
>> Magnus, Erik, I looked around to see if there's any convention in setting such environment variables that will be used when invoking external tools during the build. I didn't find any similar usage. Although the current change in this PR is working, if there's a different and better way to do this, please do let me know.
>
> Jaikiran Pai 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:
> 
>  - check for the support of --reproducer option before using it for dsymutil
>  - merge latest from master branch
>  - 8320931: [REDO] dsymutil command leaves around temporary directories

Thank you Magnus and others for helping review and test this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/16876#issuecomment-1837049715

From jpai at openjdk.org  Sat Dec  2 05:41:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Dec 2023 05:41:45 GMT
Subject: Integrated: 8320931: [REDO] dsymutil command leaves around temporary
 directories
In-Reply-To: <AoHrCiII4brHRjSxjyF3n7WiX2ZK85A5PSPrtiurEx8=.a7b3b086-827d-4f91-9e63-03729018b536@github.com>
References: <AoHrCiII4brHRjSxjyF3n7WiX2ZK85A5PSPrtiurEx8=.a7b3b086-827d-4f91-9e63-03729018b536@github.com>
Message-ID: <tZDEyqTXNZzRfpESUpRWY0QlDSOz3QVxRE2pVR8ERRY=.099a9b4f-9191-4c9a-a48f-4c1666fecb78@github.com>

On Wed, 29 Nov 2023 06:45:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change will attempts to workaround an issue in dsymutil?
> 
> The previous attempt to use `--reproducer Off` has shown that it fails to build on some other Xcode versions other than 14.3.1. Users have reported it to fail on  Xcode 15.0.1 and Xcode from a 12.4 devkit. The `--reproducer` option isn't being recognized on those versions.
> 
> This current PR proposes to use an alternate workaround, one which just sets an environment variable that Xcode 14.3.1 recognizes and prevents the creation of the leftover `dsymutil-*` temporary directories. Since this new approach uses an environment variable to workaround the issue, the command itself shouldn't ideally run into any usage issues. Once we agree upon this change, before integrating, I'll ask for inputs from those who had run into build issues to verify this alternate approach doesn't cause problems.
> 
> I have locally verified that this new approach continues to work and doesn't create those temporary directories. Additionally tier1, tier2, tier3 has completed successfully in our CI environment with this change.
> 
> Magnus, Erik, I looked around to see if there's any convention in setting such environment variables that will be used when invoking external tools during the build. I didn't find any similar usage. Although the current change in this PR is working, if there's a different and better way to do this, please do let me know.

This pull request has now been integrated.

Changeset: 6f7bb79a
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f7bb79a5b543ebd9ccd72d7b1b289b1f6e4cedb
Stats:     11 lines in 1 file changed: 11 ins; 0 del; 0 mod

8320931: [REDO] dsymutil command leaves around temporary directories

Reviewed-by: ihse, clanger

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

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

From mgronlun at openjdk.org  Sat Dec  2 11:33:53 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 2 Dec 2023 11:33:53 GMT
Subject: RFR: 8211238: @Deprecated JFR event
Message-ID: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>

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

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

Commit messages:
 - Merge branch 'openjdk:master' into 8211238
 - whitespace
 - emergency dump support
 - whitespace
 - remove assert
 - 8211238

Changes: https://git.openjdk.org/jdk/pull/16931/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16931&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8211238
  Stats: 2391 lines in 65 files changed: 2043 ins; 251 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/16931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16931/head:pull/16931

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

From mgronlun at openjdk.org  Sat Dec  2 17:20:58 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 2 Dec 2023 17:20:58 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v2]
In-Reply-To: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
Message-ID: <yM99EKi10q2SjhR4dncptnrz7vNswl8GqgcG54CyHYQ=.2402c0b9-cca4-4469-ba9f-871b144c5352@github.com>

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

 - Merge branch '8211238' of github.com:mgronlun/jdk into 8211238
 - reflection support

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16931/files
  - new: https://git.openjdk.org/jdk/pull/16931/files/cdedbb20..1d0b8a98

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

  Stats: 131 lines in 5 files changed: 120 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16931/head:pull/16931

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

From darcy at openjdk.org  Sat Dec  2 20:34:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 2 Dec 2023 20:34:36 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
 <Lx5ZzbGIV584QK73SK4GaA8OF-41M-BECYxzWGmh8Fk=.37a42cf6-50e9-48f4-9d76-b071c2ead567@github.com>
Message-ID: <MvHasng-zgZGKUbkeFYM30zb2yO7day8Z3S0JOWSUEU=.a10c86e6-ce86-40a6-af22-b24e784aa243@github.com>

On Fri, 1 Dec 2023 08:54:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks good. I assume you'll bump the copyright header on the files that need it before integration, e.g. JavacTestingAbstractProcessor.

Right; I run a script to update the years of modified files.

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

PR Comment: https://git.openjdk.org/jdk/pull/16505#issuecomment-1837247101

From aturbanov at openjdk.org  Sat Dec  2 20:43:39 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 2 Dec 2023 20:43:39 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
Message-ID: <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>

On Thu, 30 Nov 2023 23:49:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start making preparations for JDK 23.
>
> 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:         TWENTY_ONE(false,"65.0", "21"),
> 96:         TWENTY_TWO(false,"66.0", "22"),
> 97:         TWENTY_THREE(false,"67.0", "23"),

As alignment is broken anyway, let's add space
Suggestion:

        TWENTY_THREE(false, "67.0", "23"),

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1412868557

From duke at openjdk.org  Sat Dec  2 22:10:37 2023
From: duke at openjdk.org (serge-sans-paille)
Date: Sat, 2 Dec 2023 22:10:37 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v6]
In-Reply-To: <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <SHBw8bY7vJuMY8yynW8EMqybSIuhhP5Up_EzESHzv2Y=.e9e34b30-77c6-4f04-a590-8363bfa834d5@github.com>
 <sFgQe4eGlWzzK-fU0r5d6ryaNRn4bg8TuyRIZpNRyDo=.16d81e31-4a20-4124-8a77-2cc1515f658d@github.com>
 <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com>
Message-ID: <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>

On Wed, 29 Nov 2023 06:12:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Not listed here: https://oca.opensource.oracle.com/?ojr=contributors
>
> I take it he is not an Intel employee, in which case he has to be an OpenJDK contributor himself for code for which he holds a copyright to be contributed to OpenJDK. @robilad please correct me if I am wrong here.

hey o/ No problem on my side to either let go my copyright or fill the contributor agreement (where is it?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1409280698

From robilad at openjdk.org  Sat Dec  2 22:10:38 2023
From: robilad at openjdk.org (Dalibor Topic)
Date: Sat, 2 Dec 2023 22:10:38 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v6]
In-Reply-To: <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <SHBw8bY7vJuMY8yynW8EMqybSIuhhP5Up_EzESHzv2Y=.e9e34b30-77c6-4f04-a590-8363bfa834d5@github.com>
 <sFgQe4eGlWzzK-fU0r5d6ryaNRn4bg8TuyRIZpNRyDo=.16d81e31-4a20-4124-8a77-2cc1515f658d@github.com>
 <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com>
 <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>
Message-ID: <6gIzR7OWDjVSklcQD-PM7ng_maqv6IbhAjHfgm-hWEs=.45910411-ab20-4ef0-99fa-88a13f722b7b@github.com>

On Wed, 29 Nov 2023 13:26:58 GMT, serge-sans-paille <duke at openjdk.org> wrote:

>> I take it he is not an Intel employee, in which case he has to be an OpenJDK contributor himself for code for which he holds a copyright to be contributed to OpenJDK. @robilad please correct me if I am wrong here.
>
> hey o/ No problem on my side to either let go my copyright or fill the contributor agreement (where is it?)

Thanks Serge! And thank you for sending in an OCA for processing, which has now been done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1412885472

From alanb at openjdk.org  Sun Dec  3 10:28:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Dec 2023 10:28:44 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v2]
In-Reply-To: <yM99EKi10q2SjhR4dncptnrz7vNswl8GqgcG54CyHYQ=.2402c0b9-cca4-4469-ba9f-871b144c5352@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
 <yM99EKi10q2SjhR4dncptnrz7vNswl8GqgcG54CyHYQ=.2402c0b9-cca4-4469-ba9f-871b144c5352@github.com>
Message-ID: <Zm2Ez8PgMmme46QswDQf0V3wOr6Usoem0AjEL-yEfXQ=.d6b251bb-ceb3-4215-a415-330db9cf8551@github.com>

On Sat, 2 Dec 2023 17:20:58 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
> 
>  - Merge branch '8211238' of github.com:mgronlun/jdk into 8211238
>  - reflection support

src/jdk.jfr/share/classes/jdk/jfr/internal/test/DeprecatedThing.java line 90:

> 88:     public static void reflectionForRemoval() {
> 89:         staticCounter++;
> 90:     }

You might want to extend the set of tests to include cases that have the "since" element.  There is a 2x2 matrix of cases to fully exercise the parsing of the RuntimeVisibleAnnotations content.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16931#discussion_r1413041171

From mgronlun at openjdk.org  Sun Dec  3 13:29:21 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 3 Dec 2023 13:29:21 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v3]
In-Reply-To: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
Message-ID: <NABLZkvQ1RWf2oeRXpJ_b-Qcp5Tp1qM8G13lByZ34rA=.29bc0dde-7a44-4a04-b35f-a09f798db248@github.com>

> 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 one additional commit since the last revision:

  restructured testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16931/files
  - new: https://git.openjdk.org/jdk/pull/16931/files/1d0b8a98..f8ef13cf

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

  Stats: 279 lines in 4 files changed: 86 ins; 91 del; 102 mod
  Patch: https://git.openjdk.org/jdk/pull/16931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16931/head:pull/16931

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

From mgronlun at openjdk.org  Sun Dec  3 13:36:01 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 3 Dec 2023 13:36:01 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v4]
In-Reply-To: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
Message-ID: <848Z_qNEkLyfuHIDhH8zeM93fKdNQUk8IH9HNSX8R2g=.ecb41dae-630d-4515-9598-f642b93f4a0e@github.com>

> 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 one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16931/files
  - new: https://git.openjdk.org/jdk/pull/16931/files/f8ef13cf..2239ce2e

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

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

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

From mgronlun at openjdk.org  Sun Dec  3 13:36:05 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 3 Dec 2023 13:36:05 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v2]
In-Reply-To: <Zm2Ez8PgMmme46QswDQf0V3wOr6Usoem0AjEL-yEfXQ=.d6b251bb-ceb3-4215-a415-330db9cf8551@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
 <yM99EKi10q2SjhR4dncptnrz7vNswl8GqgcG54CyHYQ=.2402c0b9-cca4-4469-ba9f-871b144c5352@github.com>
 <Zm2Ez8PgMmme46QswDQf0V3wOr6Usoem0AjEL-yEfXQ=.d6b251bb-ceb3-4215-a415-330db9cf8551@github.com>
Message-ID: <CUqpZDiorjzRvU2wxZOjDbU7uXSHs8glbV-SZZzd-h4=.b4e8bf84-d4be-4d3b-a3a3-4b9921a5207b@github.com>

On Sun, 3 Dec 2023 10:15:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch '8211238' of github.com:mgronlun/jdk into 8211238
>>  - reflection support
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/test/DeprecatedThing.java line 90:
> 
>> 88:     public static void reflectionForRemoval() {
>> 89:         staticCounter++;
>> 90:     }
> 
> You might want to extend the set of tests to include cases that have the "since" element.  There is a 2x2 matrix of cases to fully exercise the parsing of the RuntimeVisibleAnnotations content.

Thanks for this input, Alan.

I have made the tests and cases more structured to cover this. Cheers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16931#discussion_r1413080638

From mgronlun at openjdk.org  Sun Dec  3 15:44:57 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 3 Dec 2023 15:44:57 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v5]
In-Reply-To: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
Message-ID: <0WwjBlkrqLti-FWPfWAcPrLEdgDbJPLfc0f1FGBtZM8=.d760cb3b-81cb-45d5-b8c1-994a9e16413b@github.com>

> 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 one additional commit since the last revision:

  tighter lock scopes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16931/files
  - new: https://git.openjdk.org/jdk/pull/16931/files/2239ce2e..a5717e16

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

  Stats: 45 lines in 6 files changed: 16 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16931/head:pull/16931

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

From mgronlun at openjdk.org  Sun Dec  3 16:06:16 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 3 Dec 2023 16:06:16 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v6]
In-Reply-To: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
Message-ID: <LWZSWvYKm3OLUgxOU9XauiABb3m2LtJ1B-P3spPmGQY=.149b010c-72f9-4134-ac8d-d07610e27fed@github.com>

> 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 one additional commit since the last revision:

  tuning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16931/files
  - new: https://git.openjdk.org/jdk/pull/16931/files/a5717e16..628651b3

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

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

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

From mgronlun at openjdk.org  Sun Dec  3 16:13:19 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 3 Dec 2023 16:13:19 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v7]
In-Reply-To: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
Message-ID: <F78J2NF0JW35_QDzx3nR_DVY6DuEBJUdjL1ohGA45vQ=.5335a573-01d8-4d02-9817-8e9b3038d37b@github.com>

> 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 one additional commit since the last revision:

  adjustements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16931/files
  - new: https://git.openjdk.org/jdk/pull/16931/files/628651b3..5d76503f

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

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

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

From mgronlun at openjdk.org  Sun Dec  3 16:31:13 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 3 Dec 2023 16:31:13 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v8]
In-Reply-To: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
Message-ID: <S7uOdSYbTMv7Lr0gQwZ2vIlw1j5uA5QSb4SnMYG4CDA=.4ffc9092-b830-47e1-8411-fcd24c9f945e@github.com>

> 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 one additional commit since the last revision:

  minor adjustment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16931/files
  - new: https://git.openjdk.org/jdk/pull/16931/files/5d76503f..4e78e895

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

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

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

From alanb at openjdk.org  Sun Dec  3 16:36:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Dec 2023 16:36:40 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v8]
In-Reply-To: <S7uOdSYbTMv7Lr0gQwZ2vIlw1j5uA5QSb4SnMYG4CDA=.4ffc9092-b830-47e1-8411-fcd24c9f945e@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
 <S7uOdSYbTMv7Lr0gQwZ2vIlw1j5uA5QSb4SnMYG4CDA=.4ffc9092-b830-47e1-8411-fcd24c9f945e@github.com>
Message-ID: <dbHsPeZMuohJESKpH6tt1UhlYPtoGXUC5mvdviHzHto=.b8a3e9d0-6c18-4598-971d-c18967e7a036@github.com>

On Sun, 3 Dec 2023 16:31:13 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> 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 one additional commit since the last revision:
> 
>   minor adjustment

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 to the manner in which a program element is deprecated and I assume you don't want this event grabbing the general name for a very specific event setting.

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

PR Comment: https://git.openjdk.org/jdk/pull/16931#issuecomment-1837532534

From mgronlun at openjdk.org  Sun Dec  3 16:47:38 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 3 Dec 2023 16:47:38 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v8]
In-Reply-To: <dbHsPeZMuohJESKpH6tt1UhlYPtoGXUC5mvdviHzHto=.b8a3e9d0-6c18-4598-971d-c18967e7a036@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
 <S7uOdSYbTMv7Lr0gQwZ2vIlw1j5uA5QSb4SnMYG4CDA=.4ffc9092-b830-47e1-8411-fcd24c9f945e@github.com>
 <dbHsPeZMuohJESKpH6tt1UhlYPtoGXUC5mvdviHzHto=.b8a3e9d0-6c18-4598-971d-c18967e7a036@github.com>
Message-ID: <GYLLJ4nApDwbWbjQKwVzvqRn79jo4NDGs54JqKmWzic=.e51e34d6-679c-41ce-9806-9fe093c1154c@github.com>

On Sun, 3 Dec 2023 16:33:48 GMT, Alan Bateman <alanb at openjdk.org> 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 to the manner in which a program element is deprecated and I assume you don't want this event grabbing the general name for a very specific event setting.

Yes, the design is generic. An event control/setting to be used also for other events.

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

PR Comment: https://git.openjdk.org/jdk/pull/16931#issuecomment-1837534965

From dholmes at openjdk.org  Mon Dec  4 03:20:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Dec 2023 03:20:38 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v6]
In-Reply-To: <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <SHBw8bY7vJuMY8yynW8EMqybSIuhhP5Up_EzESHzv2Y=.e9e34b30-77c6-4f04-a590-8363bfa834d5@github.com>
 <sFgQe4eGlWzzK-fU0r5d6ryaNRn4bg8TuyRIZpNRyDo=.16d81e31-4a20-4124-8a77-2cc1515f658d@github.com>
 <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com>
 <WsReFosxqMxV70m-OJLgiE7maABxc-LnxqJ1LlMZ5tY=.a864cbce-6c35-46fe-ba58-d09e53076dec@github.com>
Message-ID: <rswy0baj0j9UuOJ3baInw_iflZ6IMQSIC0C8iyF9fbM=.dc8dd26c-23e5-4803-a578-cb614d79e5ef@github.com>

On Wed, 29 Nov 2023 13:26:58 GMT, serge-sans-paille <duke at openjdk.org> wrote:

>> I take it he is not an Intel employee, in which case he has to be an OpenJDK contributor himself for code for which he holds a copyright to be contributed to OpenJDK. @robilad please correct me if I am wrong here.
>
> hey o/ No problem on my side to either let go my copyright or fill the contributor agreement (where is it?)

Thank you @serge-sans-paille !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1413324819

From asotona at openjdk.org  Mon Dec  4 05:38:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Dec 2023 05:38:48 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v34]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <ERznvvOEs71JrKcEoPMt9cLFbuN-TrBQwnv_gAssFsU=.27708813-1833-45e2-bbd3-b3dee338d691@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 372 commits:

 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - fixed SwitchBootstrapTest
 - fixed SwitchBootstrap and StackMapsTest
 - fixed SwtichBootstrapTest and ModuleVersionTest
 - Merge branch 'master' into JDK-8308753-preview
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java
 - added new package-info snippets and fixed ClassFile::parse throws javadoc description
 - fixed lambda tests
 - ... and 362 more: https://git.openjdk.org/jdk/compare/b9df827a...a908e805

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=33
  Stats: 32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

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

From asotona at openjdk.org  Mon Dec  4 07:11:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Dec 2023 07:11:11 GMT
Subject: Integrated: 8308753: Class-File API transition to Preview
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <xmC7Jgr28c-rsclwW-tBVjPo26NDX9amo2Ns2ez1Wtw=.5e1dd353-28ec-4c14-8ad0-4944b93a1216@github.com>

On Wed, 13 Sep 2023 09:48:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 2b00ac0d
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b00ac0d02a110326846c75ea7ea535dccbb1924
Stats:     32362 lines in 787 files changed: 14660 ins; 14113 del; 3589 mod

8308753: Class-File API transition to Preview

Reviewed-by: ihse, mchung, vromero

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

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

From jlahoda at openjdk.org  Mon Dec  4 07:50:57 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Dec 2023 07:50:57 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules
Message-ID: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>

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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.

Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.

The problems (and their solution) I've attempted to tackle here:
 - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
 - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
 - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed classes where finalized in JDK 17), changes are included here, and are the bulk of the changes of this patch.
 - when trying to find an existing class header when processing a new class header, it might have happened that an older existing version was picked up. This then caused repetition of the header in the new version. Proposed fix is to first look at the baseline existing header when searching for existing headers, and also a bit more careful computation of baseline.

As part of testing, I've written a simple program (inside tests), that prints all elements in exported packages using the `PrintingProcessor`, please see `PrintCTSymContent.java`. And printed the content for JDK 17-21 before this patch:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/orig/
after this patch:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/new/
and made a diff:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/diff/

Looking at the diff, it seems that (as expected) it is basically addition of `sealed`&`permits` and addition of package private classes (forced by `permits`).

Symbol files generated for JDK 22 are here:
https://github.com/lahodaj/jdk/commit/06606d544cb63f007b1d4eb5196f3ca6ffd24bed#diff-0029c8ea954c5b329126d760dc307cd3235abbe4e9f0530dc301141e33746d37

There's one quirk in the current historical record files: as the `jdk/internal/foreign/` package existed in the `jdk.incubator.foreign` module, and was moved to `java.base`, the generator still puts the classes in this package into `jdk.incubator.foreign-<version>.sym.txt`. This is a quirk only in the way the `.sym.txt` files are written, when `ct.sym` is written, the `.sig` files are generated into the correct module. I may try to fix this for the future, but it does not seem to be blocker. (We need to include classes in this package due get the correct permitted subclasses handling.)

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

Commit messages:
 - Removing trailing whitespace.
 - Ensuring qualified packages are recorded properly.
 - Fixing tests.
 - Adding a way to dump the API.
 - Adding missing file.
 - 8321224: ct.sym for JDK 22 contains references to internal modules

Changes: https://git.openjdk.org/jdk/pull/16942/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321224
  Stats: 26876 lines in 194 files changed: 6106 ins; 20256 del; 514 mod
  Patch: https://git.openjdk.org/jdk/pull/16942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16942/head:pull/16942

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

From darcy at openjdk.org  Mon Dec  4 07:50:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 4 Dec 2023 07:50:57 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <GMYNmyYZnRpl28-aJ4-WnE8uxmlyuRKx1U3UB494QY0=.bac5302e-2689-4596-8f1b-dd5c047ce629@github.com>

On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

Marked as reviewed by darcy (Reviewer).

Thanks for the quick fix @lahodaj ; the changes look plausible, but I think another person should review them too.

We can coordinate with start-of-JDK-23 work depending on exactly when this change goes back.

PS @lahodaj , I think a quick CSR is warranted here to explain the change in behavior in what is (now more correctly) stored in the symbol files.

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

PR Review: https://git.openjdk.org/jdk/pull/16942#pullrequestreview-1761515541
PR Comment: https://git.openjdk.org/jdk/pull/16942#issuecomment-1837756730
PR Comment: https://git.openjdk.org/jdk/pull/16942#issuecomment-1837760204

From xgong at openjdk.org  Mon Dec  4 08:33:49 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 4 Dec 2023 08:33:49 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>
Message-ID: <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>

On Fri, 1 Dec 2023 16:45:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
> 
> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?

Yes, the SVE compiler test code could be treated as a gcc/clang version check. `arm_sve.h` which is included in `sleef.h` and then in `vect_math_sve.c` is the SVE ACLE (Arm C Language Extensions) header file. It was included in gcc start from version 10 (may not be exact, but gcc 8/9 would fail when compile c code including this header). We have to make sure the compiler supports the SVE ACLE before using it.  Here are the different scenarios:

1. The SVE compiler test success, and `SVE_CFLAGS` is set to `-march=armv8-a+sve`. All symbols in `libvmath.so` are built successfully including NEON/SVE. Hence, the vector math operations with all kinds of vector size on both NEON/SVE machines will be improved as expected.
2. The SVE compiler test fail, and `SVE_CFLAGS` is null. SVE symbols in `libvmath.so` cannot be built out. Only NEON symbols exist in `libvmath.so`. Hence, the enhancement for vector math operations with > 128-bit vector size on SVE machines are missing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1838061502

From jwaters at openjdk.org  Mon Dec  4 09:48:59 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Dec 2023 09:48:59 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
Message-ID: <NoK2uFBJ1ZEcV_Q864oEWgdNBU0vPK1ytvuhjmiVkyc=.808bfdb1-6cb1-41b4-8153-cdad40fe346e@github.com>

On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters <jwaters at openjdk.org> 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 accepting of ill formed code, which will improve code quality on Windows in the future.
>
> 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 awt_PrintJob.cpp
>  - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4
>  - Fix awt_Window.cpp
>  - awt_Window.cpp
>  - awt_PrintJob.cpp
>  - awt_Frame.cpp
>  - Whitespace awt_Component.cpp
>  - awt_Frame.cpp
>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f

Re-adding build label since this now touches build flags again

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1838179902

From mgronlun at openjdk.org  Mon Dec  4 10:21:02 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 4 Dec 2023 10:21:02 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v9]
In-Reply-To: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
Message-ID: <XMyXI55KYdhtizq8x2U5KBlvDF2EGvnybk7XpMysviw=.2fad5ef7-a8ea-4d58-bb31-227ffdb77d6d@github.com>

> 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 one additional commit since the last revision:

  relax assertion for native caller

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16931/files
  - new: https://git.openjdk.org/jdk/pull/16931/files/4e78e895..d67d2fcb

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

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

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

From jbachorik at openjdk.org  Mon Dec  4 10:21:03 2023
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Mon, 4 Dec 2023 10:21:03 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v8]
In-Reply-To: <GYLLJ4nApDwbWbjQKwVzvqRn79jo4NDGs54JqKmWzic=.e51e34d6-679c-41ce-9806-9fe093c1154c@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
 <S7uOdSYbTMv7Lr0gQwZ2vIlw1j5uA5QSb4SnMYG4CDA=.4ffc9092-b830-47e1-8411-fcd24c9f945e@github.com>
 <dbHsPeZMuohJESKpH6tt1UhlYPtoGXUC5mvdviHzHto=.b8a3e9d0-6c18-4598-971d-c18967e7a036@github.com>
 <GYLLJ4nApDwbWbjQKwVzvqRn79jo4NDGs54JqKmWzic=.e51e34d6-679c-41ce-9806-9fe093c1154c@github.com>
Message-ID: <rufBDKmh_1RYLww37iqdt15jPqe4eFf1iFev8KOtsCw=.6c6cd8b2-52e0-4b7d-9593-ff3f9cdb54e4@github.com>

On Sun, 3 Dec 2023 16:44:28 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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 to the manner in which a program element is deprecated and I assume you don't want this event grabbing the general name for a very specific event setting.
>
>> 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 to the manner in which a program element is deprecated and I assume you don't want this event grabbing the general name for a very specific event setting.
> 
> Yes, the design is generic. An event control/setting to be used also for other events.

Hi @mgronlun - sorry for opening a design discussion in PR :(

I wonder - will this report each single one invocation of a deprecated method conforming to the rules (JDK method called from non-JDK code)? Can this, potentially, flood the recording if the deprecated method gets called from a hot loop?

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

PR Comment: https://git.openjdk.org/jdk/pull/16931#issuecomment-1838232356

From mgronlun at openjdk.org  Mon Dec  4 10:40:40 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 4 Dec 2023 10:40:40 GMT
Subject: RFR: 8211238: @Deprecated JFR event [v8]
In-Reply-To: <GYLLJ4nApDwbWbjQKwVzvqRn79jo4NDGs54JqKmWzic=.e51e34d6-679c-41ce-9806-9fe093c1154c@github.com>
References: <LhHs4FulHZaNHxnGX__oXn8K6uy5T45v4_VogJSg6-M=.a333110a-6a75-41df-bff1-3d727c245e06@github.com>
 <S7uOdSYbTMv7Lr0gQwZ2vIlw1j5uA5QSb4SnMYG4CDA=.4ffc9092-b830-47e1-8411-fcd24c9f945e@github.com>
 <dbHsPeZMuohJESKpH6tt1UhlYPtoGXUC5mvdviHzHto=.b8a3e9d0-6c18-4598-971d-c18967e7a036@github.com>
 <GYLLJ4nApDwbWbjQKwVzvqRn79jo4NDGs54JqKmWzic=.e51e34d6-679c-41ce-9806-9fe093c1154c@github.com>
Message-ID: <ZTGTrX_2XeGt8WwWS8DVtWtQ5lEcOTim8OmJHgqMMrE=.78c69168-4ddb-4ec5-b520-92b2e59e9750@github.com>

On Sun, 3 Dec 2023 16:44:28 GMT, Markus Gr?nlund <mgronlun at openjdk.org> 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 to the manner in which a program element is deprecated and I assume you don't want this event grabbing the general name for a very specific event setting.
>
>> 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 to the manner in which a program element is deprecated and I assume you don't want this event grabbing the general name for a very specific event setting.
> 
> Yes, the design is generic. An event control/setting to be used also for other events.

> Hi @mgronlun - sorry for opening a design discussion in PR :(
> 
> I wonder - will this report each single one invocation of a deprecated method conforming to the rules (JDK method called from non-JDK code)? Can this, potentially, flood the recording if the deprecated method gets called from a hot loop?

Hi @jbachorik, it will only report one event per unique call site, during link time. Its not a function of hotness, only unique edge discovery.

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

PR Comment: https://git.openjdk.org/jdk/pull/16931#issuecomment-1838269120

From ihse at openjdk.org  Mon Dec  4 11:32:09 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 11:32:09 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
Message-ID: <WJN8KSB4jQF3WPglCvTGvWKYfoY9czqaoA0L2m81-kg=.56b04dfe-e999-49bb-babe-4d5b305ff6b0@github.com>

On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters <jwaters at openjdk.org> 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 accepting of ill formed code, which will improve code quality on Windows in the future.
>
> 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 awt_PrintJob.cpp
>  - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4
>  - Fix awt_Window.cpp
>  - awt_Window.cpp
>  - awt_PrintJob.cpp
>  - awt_Frame.cpp
>  - Whitespace awt_Component.cpp
>  - awt_Frame.cpp
>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f

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 Windows.
> 565:     TOOLCHAIN_CFLAGS_JVM="-nologo -MD -Zc:preprocessor -Zc:strictStrings -Zc:inline -permissive- -utf-8 -MP"

What is the rationale for removing `-Zc:strictStrings`? That seems like a step backwards. Also, this will affect *all* files compiled, both hotspot and all native JDK libraries.

If there is a single file that cannot (for some reason) be fixed to have the compiler stop complaining about const strings, that individual file should have `-Zc:strictStrings-` added to its CFLAGS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1413741134

From jwaters at openjdk.org  Mon Dec  4 11:36:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Dec 2023 11:36:18 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <WJN8KSB4jQF3WPglCvTGvWKYfoY9czqaoA0L2m81-kg=.56b04dfe-e999-49bb-babe-4d5b305ff6b0@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
 <WJN8KSB4jQF3WPglCvTGvWKYfoY9czqaoA0L2m81-kg=.56b04dfe-e999-49bb-babe-4d5b305ff6b0@github.com>
Message-ID: <cdG-CEk4-vC2aCqiOM0r9Rh4nZWgAsXGd-ZlphxpqZE=.114eaec7-5b8e-4a12-af55-3183de30d138@github.com>

On Mon, 4 Dec 2023 11:29:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 awt_PrintJob.cpp
>>  - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4
>>  - Fix awt_Window.cpp
>>  - awt_Window.cpp
>>  - awt_PrintJob.cpp
>>  - awt_Frame.cpp
>>  - Whitespace awt_Component.cpp
>>  - awt_Frame.cpp
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f
>
> 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 Windows.
>> 565:     TOOLCHAIN_CFLAGS_JVM="-nologo -MD -Zc:preprocessor -Zc:strictStrings -Zc:inline -permissive- -utf-8 -MP"
> 
> What is the rationale for removing `-Zc:strictStrings`? That seems like a step backwards. Also, this will affect *all* files compiled, both hotspot and all native JDK libraries.
> 
> If there is a single file that cannot (for some reason) be fixed to have the compiler stop complaining about const strings, that individual file should have `-Zc:strictStrings-` added to its CFLAGS.

@magicus -permissive- automatically turns on -Zc:strictStrings, so specifying it manually becomes redundant when -permissive- is also specified
https://learn.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170

> The -Zc:strictStrings option is off by default. The [-permissive-](https://learn.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-170) compiler option implicitly sets this option, but it can be overridden by using -Zc:strictStrings-

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1413745163

From ihse at openjdk.org  Mon Dec  4 11:41:40 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 11:41:40 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <5vLxKqST7AYhrmXhRNKfYhpAK_Z2wAOSSfxKX9L9z9s=.136fcc0d-880a-4e2e-ac2c-82c92d10e0cc@github.com>

On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

make/modules/jdk.compiler/Gendata.gmk line 41:

> 39: CT_MODULES := $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))
> 40: CT_EXTRA_MODULES := jdk.unsupported
> 41: CT_TRANSITIVE_MODULES := $(call FindTransitiveIndirectDepsForModules, $(CT_MODULES)) $(CT_MODULES)

Now the CT_TRANSITIVE_MODULES will include all CT_MODULES. I am pretty sure the intention was to keep them separated, for clarity, but to act on both CT_MODULES and CT_TRANSITIVE_MODULES. See e.g. the foreach on line 43. (This change will also make that foreach process CT_MODULES twice.)

Also, just for code readability, can you move the hard-coded list of extra modules to after the programmatic definitions of CT_MODULES and transitive modules, perhaps even with an empty line in between?

I think a better solution is to change your new line to:

$(ECHO) $(CT_MODULES)  $(CT_TRANSITIVE_MODULES)  $(CT_EXTRA_MODULES) >$(SUPPORT_OUTPUTDIR)/symbols/included-modules

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16942#discussion_r1413751161

From ihse at openjdk.org  Mon Dec  4 11:47:24 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 11:47:24 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <cdG-CEk4-vC2aCqiOM0r9Rh4nZWgAsXGd-ZlphxpqZE=.114eaec7-5b8e-4a12-af55-3183de30d138@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
 <WJN8KSB4jQF3WPglCvTGvWKYfoY9czqaoA0L2m81-kg=.56b04dfe-e999-49bb-babe-4d5b305ff6b0@github.com>
 <cdG-CEk4-vC2aCqiOM0r9Rh4nZWgAsXGd-ZlphxpqZE=.114eaec7-5b8e-4a12-af55-3183de30d138@github.com>
Message-ID: <wlv1tqbf2AkbAwHyY1l-j5tWFVh-aD1JMUe9YL6I4sk=.ca9da060-66c1-4b26-8b7f-ee271d0e5890@github.com>

On Mon, 4 Dec 2023 11:33:09 GMT, Julian Waters <jwaters at openjdk.org> 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 Windows.
>>> 565:     TOOLCHAIN_CFLAGS_JVM="-nologo -MD -Zc:preprocessor -Zc:strictStrings -Zc:inline -permissive- -utf-8 -MP"
>> 
>> What is the rationale for removing `-Zc:strictStrings`? That seems like a step backwards. Also, this will affect *all* files compiled, both hotspot and all native JDK libraries.
>> 
>> If there is a single file that cannot (for some reason) be fixed to have the compiler stop complaining about const strings, that individual file should have `-Zc:strictStrings-` added to its CFLAGS.
>
> @magicus -permissive- automatically turns on -Zc:strictStrings, so specifying it manually becomes redundant when -permissive- is also specified
> https://learn.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170
> 
>> The -Zc:strictStrings option is off by default. The [-permissive-](https://learn.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-170) compiler option implicitly sets this option, but it can be overridden by using -Zc:strictStrings-

I see. Then I guess this is okay. If/when you are finally ready for integration, and turning on -permissive-, let me know so I can take the patch for a spin in our CI systems before integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1413756555

From ihse at openjdk.org  Mon Dec  4 11:51:38 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 11:51:38 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v6]
In-Reply-To: <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
Message-ID: <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>

On Thu, 30 Nov 2023 20:19:56 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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 c++17? 
>> 
>> I still don't really like it. I'd like to hear someone else who can think clearly about this, if we want to go down this path, and start adding libraries that use C++17. Maybe @kimbarrett has some input?
>
>> 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 supports C++17 features.

Then you must add logic to check for this. Now the build will just fail if building with an older gcc. That is not acceptable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1413761798

From ihse at openjdk.org  Mon Dec  4 12:01:47 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 12:01:47 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
 <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
Message-ID: <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>

On Fri, 1 Dec 2023 16:49:28 GMT, Andrew Haley <aph at openjdk.org> 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, we can just hard-code the names and dispatch to them directly to a dlopened library at runtime".
> 
> Yep.
> 
>> That is technically correct, but I'd still like to argue that the current setup have some merits:
>> 
>>     * It will check that there is no typo in the function names. I agree that the likelihood of getting this wrong is low, but it is still a good practice to use official include files to have the compiler help checking this.
>> 
>>     * If we would like to bundle libsleef.so with the JVM, now we have the possibility do do so easily. (Especially if it is like you say that it is not commonly installed). (If licenses allow etc)
>> 
>>     * If we want to incorporate/bundle the source code of libsleef into OpenJDK, and build it as part of our internal library, we will have a good starting position, compared to starting from a hard-coded assembly file in hotspot. (I thought I heard some noise about this prospect).
>> 
>> 
>> So at this point, I am okay with the general approach of this PR. There are still some build issues to sort out, though, I'll address them separately.
> 
> I see, OK. The question in my mind is whether the common builds of OpenJDK (Oracle, Adoptium, etc.) will support running with SLEEF. If by default SLEEF is not required, support won't be built, and (to an nth order approximation) no one will use it. But I guess it's better than nothing.
> 
> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support?

@theRealAph 
> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support?

I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK.

And I can't say anything at all about what Oracle JDKs are going to release with, but I am fully open towards adding libsleef to the GHA builds. And I'm guessing that Adoptium has no reason not to include libsleef, but then again, I cannot of course speak for them.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1838489588

From ihse at openjdk.org  Mon Dec  4 12:04:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 12:04:45 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>
 <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>
Message-ID: <_oX3Rqyygpj-612IlxZBZOZQnauEyTBjE4goHDa4Ov8=.0ccafde6-c95e-469d-aee6-77a2e75ee7a7@github.com>

On Mon, 4 Dec 2023 08:31:17 GMT, Xiaohong Gong <xgong at openjdk.org> 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 also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
>> 
>> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?
>
>> 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 also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
>> 
>> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?
> 
> Yes, the SVE compiler test code could be treated as a gcc/clang version check. `arm_sve.h` which is included in `sleef.h` and then in `vect_math_sve.c` is the SVE ACLE (Arm C Language Extensions) header file. It was included in gcc start from version 10 (may not be exact, but gcc 8/9 would fail when compile c code including this header). We have to make sure the compiler supports the SVE ACLE before using it.  Here are the different scenarios:
> 
> 1. The SVE compiler test success, and `SVE_CFLAGS` is set to `-march=armv8-a+sve`. All symbols in `libvmath.so` are built successfully including NEON/SVE. Hence, the vector math operations with all kinds of vector size on both NEON/SVE machines will be improved as expected.
> 2. The SVE compiler test fail, and `SVE_CFLAGS` is null. SVE symbols in `libvmath.so` cannot be built out. Only NEON symbols exist in `libvmath.so`. Hence, the enhancement for vector math operations with > 128-bit vector size on SVE machines are missing.

@XiaohongGong If we are sure that the SVE test will always succeed when running on gcc 10 or higher, then I guess I don't really need a way to enforce SVE support -- you'll just have to make sure you use a recent enough gcc.

But, then the entire test becomes a bit unnecessary. You can just replace it with a version check on gcc, or perhaps a FLAGS_COMPILER_CHECK_ARGUMENTS on `-march=armv8-a+sve`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1838495553

From vromero at openjdk.org  Mon Dec  4 19:42:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 4 Dec 2023 19:42:47 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <qjAB5WtEWwoxzU5lkF61Sp0JMnf3yJeYH_7rIiYoZj0=.4ace519b-1cc3-4270-8642-e1174d215a4a@github.com>

On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16942#pullrequestreview-1763256790

From jlahoda at openjdk.org  Mon Dec  4 21:27:57 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Dec 2023 21:27:57 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v2]
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>

> 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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16942/files
  - new: https://git.openjdk.org/jdk/pull/16942/files/c65eb44b..87927789

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

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

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

From jlahoda at openjdk.org  Mon Dec  4 21:27:59 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Dec 2023 21:27:59 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v2]
In-Reply-To: <5vLxKqST7AYhrmXhRNKfYhpAK_Z2wAOSSfxKX9L9z9s=.136fcc0d-880a-4e2e-ac2c-82c92d10e0cc@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
 <5vLxKqST7AYhrmXhRNKfYhpAK_Z2wAOSSfxKX9L9z9s=.136fcc0d-880a-4e2e-ac2c-82c92d10e0cc@github.com>
Message-ID: <Qi4FyHVWclZ3HkXJ0Ci6LsgvxYD3cJbG7xrKg1JVPQY=.36bfd1c7-3ae7-4f88-9c04-fcc9e8f0d414@github.com>

On Mon, 4 Dec 2023 11:39:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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.
>
> make/modules/jdk.compiler/Gendata.gmk line 41:
> 
>> 39: CT_MODULES := $(filter-out $(MODULES_FILTER), $(DOCS_MODULES))
>> 40: CT_EXTRA_MODULES := jdk.unsupported
>> 41: CT_TRANSITIVE_MODULES := $(call FindTransitiveIndirectDepsForModules, $(CT_MODULES)) $(CT_MODULES)
> 
> Now the CT_TRANSITIVE_MODULES will include all CT_MODULES. I am pretty sure the intention was to keep them separated, for clarity, but to act on both CT_MODULES and CT_TRANSITIVE_MODULES. See e.g. the foreach on line 43. (This change will also make that foreach process CT_MODULES twice.)
> 
> Also, just for code readability, can you move the hard-coded list of extra modules to after the programmatic definitions of CT_MODULES and transitive modules, perhaps even with an empty line in between?
> 
> I think a better solution is to change your new line to:
> 
> $(ECHO) $(CT_MODULES)  $(CT_TRANSITIVE_MODULES)  $(CT_EXTRA_MODULES) >$(SUPPORT_OUTPUTDIR)/symbols/included-modules

Thanks for the comment! I tried to act on it here:
https://github.com/openjdk/jdk/pull/16942/commits/879277891708533b0b56dbe36b20760c62708bbf

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16942#discussion_r1414515956

From duke at openjdk.org  Mon Dec  4 21:55:36 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 4 Dec 2023 21:55:36 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v7]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <Wtw85e0b1KZvSOdEMPLMzJG89x4A3V1U3HVuUy-zWoE=.795cdd9c-cc64-4da2-829e-170d7c0889ba@github.com>

> 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 improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  add GCC version guards

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/d957f413..bb5f711a

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

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

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

From duke at openjdk.org  Mon Dec  4 22:15:24 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 4 Dec 2023 22:15:24 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>

> 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 improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

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

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
 - add GCC version guards
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
 - Remove C++17 from C flags
 - add avoid masked stores operation
 - update the code to check for supported simd sort cpus
 - Disable AVX2 sort for 64-bit types
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
 - fix jcheck failures due to windows encoding
 - fix carriage return and change insertion sort thresholds
 - ... and 7 more: https://git.openjdk.org/jdk/compare/0b17dc14...bc590d9f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/bb5f711a..bc590d9f

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

  Stats: 36176 lines in 1033 files changed: 17425 ins; 14551 del; 4200 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From duke at openjdk.org  Mon Dec  4 22:18:35 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 4 Dec 2023 22:18:35 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
Message-ID: <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>

On Mon, 4 Dec 2023 11:48:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 supports C++17 features.
>
> Then you must add logic to check for this. Now the build will just fail if building with an older gcc. That is not acceptable.

Hi Marcus (@magicus), please see the updated code which added guards to check for GCC version >= 7.5 in `src/java.base/linux/native/libsimdsort/{avx2-linux-qsort.cpp, avx512-linux-qsort.cpp}`. GCC >= 7.5 is needed to compile libsimdsort using C++17 features. Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1414570644

From sviswanathan at openjdk.org  Tue Dec  5 00:10:38 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 5 Dec 2023 00:10:38 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <5JnWpXMWKZ85mosrUdVrdNLRyHWF_HNW3h8krKWO63k=.63bf3ffa-63a1-4ce4-b972-278655e8a567@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d4804a12...bc590d9f

The PR looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16534#pullrequestreview-1763680754

From duke at openjdk.org  Tue Dec  5 00:50:41 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 5 Dec 2023 00:50:41 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <QZ8yVYKm3kiatXbu13DaPLDGNHmhjgi28_fqzFnEwOU=.df19c109-f34c-4301-85b2-fbbe48a13dc0@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/0dc47dcf...bc590d9f

Hello Vladimir (@vnkozlov),

Could you please review this PR?

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1839810768

From darcy at openjdk.org  Tue Dec  5 01:48:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 5 Dec 2023 01:48:14 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v5]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>

> 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 branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Update symbol files to JDK 22 b26.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files for JDK 22 build 25.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/30b5d427...2ee6cb96

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

Changes: https://git.openjdk.org/jdk/pull/16505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=04
  Stats: 12598 lines in 97 files changed: 12560 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505

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

From xgong at openjdk.org  Tue Dec  5 02:08:40 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 5 Dec 2023 02:08:40 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <emidt6MaU3Owb2FMLA1EibqvQF4_zTtsA00ccPQAy4Y=.1b90ba32-ac3a-41db-acf9-f1c45704b203@github.com>
 <xVVii7I4RU8P9bpGqTdLnUqzD3LhrrXYhuN0URC6JAE=.5027c6d2-d75e-48bd-bcc2-57332216078e@github.com>
Message-ID: <DUOQVUOJwBpCSxB1JmS-pCfZhGQUfmHyNFbf2-aWj_I=.cea497eb-68d4-4b49-a228-ac73d52facd8@github.com>

On Mon, 4 Dec 2023 08:31:17 GMT, Xiaohong Gong <xgong at openjdk.org> 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 also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
>> 
>> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?
>
>> 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 also implies that the compiler knows about `-march=armv8-a+sve`. If so, then this test could basically be framed as a gcc version check.
>> 
>> I'm still leaning towards failing configure if the SVE code cannot be compiled. Under what circumstances can this test possibly fail, so SVE_CFLAGS would not be set?
> 
> Yes, the SVE compiler test code could be treated as a gcc/clang version check. `arm_sve.h` which is included in `sleef.h` and then in `vect_math_sve.c` is the SVE ACLE (Arm C Language Extensions) header file. It was included in gcc start from version 10 (may not be exact, but gcc 8/9 would fail when compile c code including this header). We have to make sure the compiler supports the SVE ACLE before using it.  Here are the different scenarios:
> 
> 1. The SVE compiler test success, and `SVE_CFLAGS` is set to `-march=armv8-a+sve`. All symbols in `libvmath.so` are built successfully including NEON/SVE. Hence, the vector math operations with all kinds of vector size on both NEON/SVE machines will be improved as expected.
> 2. The SVE compiler test fail, and `SVE_CFLAGS` is null. SVE symbols in `libvmath.so` cannot be built out. Only NEON symbols exist in `libvmath.so`. Hence, the enhancement for vector math operations with > 128-bit vector size on SVE machines are missing.

> @XiaohongGong If we are sure that the SVE test will always succeed when running on gcc 10 or higher, then I guess I don't really need a way to enforce SVE support -- you'll just have to make sure you use a recent enough gcc.
> 
> But, then the entire test becomes a bit unnecessary. You can just replace it with a version check on gcc, or perhaps a FLAGS_COMPILER_CHECK_ARGUMENTS on `-march=armv8-a+sve`.

Thanks for the suggestion @magicus ! Replacing with a version check for the c compiler seems fine. But I cannot see the advantange than current test. Here are the reasons:
1. `-march=armv8-a+sve` is the necessary cflag for the sve source, and only included start from some c compiler versions. The c compiler version check must happen before using it. So it should also happen in the make or configure stage? Hence, we still have to find a right place to check it (should be in `lib-sleef.m4` or otherwhere?).
2. We not only have to check the gcc version, but also have to check the clang version. Would this make the code more complex?

Regarding to using `FLAGS_COMPILER_CHECK_ARGUMENTS on "-march=armv8-a+sve"`, it is not right as well. Because we have to make sure the c compiler supports SVE ACLE completely which contains the sve header `arm_sve.h`. The compiler that supports option `-march=armv8-a+sve` cannot make sure the SVE ACLE is supported as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1839875881

From iris at openjdk.org  Tue Dec  5 05:40:40 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Dec 2023 05:40:40 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v5]
In-Reply-To: <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <WT4hwqImuTyuIoTT1l7nJmD7pNjADyuLXYLWrOBK_lU=.11e17f95-9c77-4dc3-a9b4-26bbcfc63141@github.com>
Message-ID: <HioUyYK9DU0tuyxoIMtKjDiwDiOvkC3-89h9aUirlQU=.08a78467-afb7-497f-88b5-cce72a31dcd1@github.com>

On Tue, 5 Dec 2023 01:48:14 GMT, Joe Darcy <darcy at openjdk.org> 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 symbol files.
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Update symbol files to JDK 22 b26.
>  - Merge branch 'master' into JDK-8319413
>  - Merge branch 'master' into JDK-8319413
>  - Add symbol files for JDK 22 build 25.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/30b5d427...2ee6cb96

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1764000855

From iris at openjdk.org  Tue Dec  5 05:40:44 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Dec 2023 05:40:44 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4]
In-Reply-To: <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
 <P9uONCgJlH6ON2nqV1TxpJ5tn_XrGmBuFWKrU45JrKs=.4f773cc2-b13c-42c8-a7f4-2591af065743@github.com>
 <8B_EG0mwCKb3mRlrAoyz7vkzZhNPpZUAfY-EOQ1FlEo=.efbc5ce9-1a75-4aa2-8dfc-96a9c9fd03b7@github.com>
Message-ID: <uBGC1h1iKx_-qR6p93-OjXCiNnyl8lqV8tTT0AaWjD8=.92e0ed23-2e7d-4ec0-952d-62aa768df14d@github.com>

On Sat, 2 Dec 2023 20:40:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> 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:         TWENTY_ONE(false,"65.0", "21"),
>> 96:         TWENTY_TWO(false,"66.0", "22"),
>> 97:         TWENTY_THREE(false,"67.0", "23"),
> 
> As alignment is broken anyway, let's add space
> Suggestion:
> 
>         TWENTY_THREE(false, "67.0", "23"),

If you're going to add the space, I'd consider establishing new alignment at TWENTY to accommodate the eventual space needed for "THREE", "SEVEN", and "EIGHT".  You wouldn't need to reset alignment for quite some time after that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1414904341

From xgong at openjdk.org  Tue Dec  5 07:24:42 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 5 Dec 2023 07:24:42 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
 <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
 <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>
Message-ID: <tHkg8-8CbvcHsfEhonfA4PxB_XXjonY5MbmunXEfFEI=.428e7a97-0bce-4f17-b93c-3275037e5a66@github.com>

On Fri, 1 Dec 2023 16:36:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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 has not specified libsleef root, and we have no SYSROOT, try PKG_CHECK
>> * Otherwise, look in well-known directories which is $SYSROOT/usr/[local/]lib[64].
>
> also, ideally, you will add the corresponding specific overrides like in ffi:
> 
>   AC_ARG_WITH(libffi-include, [AS_HELP_STRING([--with-libffi-include],
>       [specify directory for the libffi include files])])
>   AC_ARG_WITH(libffi-lib, [AS_HELP_STRING([--with-libffi-lib],
>       [specify directory for the libffi library])])

Thanks for the suggestion @magicus !

The check in current `lib-sleef.m4` is very common:

-  If user has specified libsleef root by '--with-libsleef', we assume it is the manually built sleef lib. So only `lib/` and `include/` is checked. And the flags are set based on that path.
- If user has not specified the libsleef root, and no `SYSROOT` is set, we try `PKG_CHECK` (like what you suggested)
- Otherwise, check `sleef.h`   
   - We assume the sleef module is installed under one of the valid system paths if the header can be found. So just linking with `-lsleef` will success.

It's an issue in current flow like what @theRealAph met. I will add the options like `--with-libsleef-lib` and `--with-libsleef-include` like ffi. Regarding to extending the check for`--with-libsleef`, I think we can just make it simple like what it is now. Or, we have to check all the potential valid lib paths like `lib/`, `lib64/`, or maybe `lib/aarch64-linux-gnu`. The same to the `include` part.  @theRealAph @magicus , WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1414980861

From asotona at openjdk.org  Tue Dec  5 09:01:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 5 Dec 2023 09:01:38 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v2]
In-Reply-To: <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
 <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>
Message-ID: <L9t3lVyjVYM4fbrb_0KNVfUjK0SH979IflQX2UxobDU=.d3f7771f-f21c-4d46-9e04-e860ff93240a@github.com>

On Mon, 4 Dec 2023 21:27:57 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
>> 
>> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
>> 
>> The problems (and their solution) I've attempted to tackle here:
>>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator ...
>
> 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.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16942#pullrequestreview-1764410922

From magnus.ihse.bursie at oracle.com  Tue Dec  5 10:36:09 2023
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 11:36:09 +0100
Subject: Compile Errors in OpenJDK 11 with Non-English Characters in
 Compilation Path
In-Reply-To: <c3a89130-5638-456a-bb20-49011a844dd2@oracle.com>
References: <CAMBge5Nnw4YzdU5sfpC3OyWG+en6U911-TmphEApi+Y7OaMVww@mail.gmail.com>
 <5b3c1d56-e1e1-4afd-a117-e1e9af6ac73a@oracle.com>
 <CAMBge5MSF1C4qNr+trgMuafc9PhdmohMr5=6Oxhn4vxENBM3NQ@mail.gmail.com>
 <c3a89130-5638-456a-bb20-49011a844dd2@oracle.com>
Message-ID: <cd9bb96c-d4c9-4b96-98c9-f2aa5c76fe58@oracle.com>

On closer inspection, it would probably be more prudential to set the 
value of LC_ALL to C.UTF-8 in the build. It will likely help you with 
your problem. I have published a PR at 
https://github.com/openjdk/jdk/pull/16971 (JDK-8321373).

/Magnus

On 2023-11-24 13:08, Magnus Ihse Bursie wrote:
>
> Are you running on Ubuntu properly, or Ubuntu in WLS? If it is the 
> former, the it is not the same problem as the other poster, which were 
> running on Windows.
>
> The JDK build uses the "C" locale. This should be set automatically by 
> the build system, so it should just work. But in case there is some 
> bug, try exporting LC_ALL=C before building and see if it helps.
>
> Also, the point of LC_ALL is that you can specify it instead of all 
> the detailed LC_* variables...
>
> /Magnus
>
> On 2023-11-24 08:41, last last wrote:
>> I am currently facing the same error when build paths include Chinese 
>> characters ,after setting the environment variable "export 
>> LC_ALL=zh_CN.UTF-8" .The testing environment is also Ubuntu 2004.
>> The system locale settings are as follows:LANG=zh_CN.UTF-8 
>> LANGUAGE=zh_CN:zh LC_CTYPE="zh_CN.UTF-8" LC_NUMERIC="zh_CN.UTF-8" 
>> LC_TIME="zh_CN.UTF-8" LC_COLLATE="zh_CN.UTF-8" 
>> LC_MONETARY="zh_CN.UTF-8" LC_MESSAGES="zh_CN.UTF-8" 
>> LC_PAPER="zh_CN.UTF-8" LC_NAME="zh_CN.UTF-8" LC_ADDRESS="zh_CN.UTF-8" 
>> LC_TELEPHONE="zh_CN.UTF-8" LC_MEASUREMENT="zh_CN.UTF-8" 
>> LC_IDENTIFICATION="zh_CN.UTF-8" LC_ALL=zh_CN.UTF-8
>> I'm wondering if there are any other system configurations that could 
>> help resolve this problem. Your insights would be greatly appreciated.
>>
>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ?2023?11?23??? 
>> 22:30???
>>
>>     Congratulations! You get to test drive the recently updated build
>>     instructions for Windows locale requirements! :-)
>>
>>     Please see
>>     https://github.com/openjdk/jdk/blob/master/doc/building.md#locale-requirements
>>
>>     In particular, I believe you need to set your system locale.
>>
>>     Please report back if that solves the problem or not.
>>
>>     /Magnus
>>
>>
>>     On 2023-11-23 03:51, last last wrote:
>>     > Hi all,
>>     >
>>     > I tried to build a OpenJDK11 fastdebug with paths that include
>>     Chinese
>>     > characters?my build path is "/home/kylin/??/jdk11u-dev"?but i
>>     saw some
>>     > error as followings:
>>     >
>>     > Exception in thread "main" java.nio.file.InvalidPathException:
>>     > Malformed input or input contains unmappable characters:
>>     >
>>     /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch.tmp
>>     > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>>     > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>>     > at
>>     java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>>     > at java.base/java.nio.file.Path.of(Path.java:147)
>>     > at java.base/java.nio.file.Paths.get(Paths.java:69)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>>     > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>>     > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>>     > make[3]: *** [ToolsLangtools.gmk:40:
>>     >
>>     /home/kylin/??/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch]
>>
>>     > Error 1
>>     > make[2]: *** [make/Main.gmk:73: buildtools-langtools] Error 2
>>     > make[2]: *** Waiting for unfinished jobs....
>>     > Exception in thread "main" java.nio.file.InvalidPathException:
>>     > Malformed input or input contains unmappable characters:
>>     >
>>     /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/tools/jvmti/_the.BUILD_JVMTI_TOOLS_batch.tmp
>>     > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>>     > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>>     > at
>>     java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>>     > at java.base/java.nio.file.Path.of(Path.java:147)
>>     > at java.base/java.nio.file.Paths.get(Paths.java:69)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>>     > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>>     > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>>     > make[3]: *** [gensrc/GensrcJvmti.gmk:45:
>>     >
>>     /home/kylin/??/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/tools/jvmti/_the.BUILD_JVMTI_TOOLS_batch]
>>
>>     > Error 1
>>     > make[3]: *** Waiting for unfinished jobs....
>>     > Exception in thread "main" java.nio.file.InvalidPathException:
>>     > Malformed input or input contains unmappable characters:
>>     >
>>     /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
>>     > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>>     > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>>     > at
>>     java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>>     > at java.base/java.nio.file.Path.of(Path.java:147)
>>     > at java.base/java.nio.file.Paths.get(Paths.java:69)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>>     > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>>     > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>>     > make[3]: *** [gensrc/GensrcJfr.gmk:43:
>>     >
>>     /home/kylin/??/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch]
>>
>>     > Error 1
>>     > make[2]: *** [make/Main.gmk:265: hotspot-server-gensrc] Error 2
>>     >
>>     > ERROR: Build failed for target 'images' in configuration
>>     > 'linux-aarch64-normal-server-fastdebug' (exit code 2)
>>     >
>>     > === Output from failing command(s) repeated here ===
>>     > * For target
>>     >
>>     buildtools_langtools_tools_classes__the.BUILD_TOOLS_LANGTOOLS_batch:
>>     > Exception in thread "main" java.nio.file.InvalidPathException:
>>     > Malformed input or input contains unmappable characters:
>>     >
>>     /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch.tmp
>>     > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>>     > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>>     > at
>>     java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>>     > at java.base/java.nio.file.Path.of(Path.java:147)
>>     > at java.base/java.nio.file.Paths.get(Paths.java:69)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>>     > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>>     > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>>     > * For target
>>     >
>>     hotspot_variant-server_buildtools_tools_classes__the.BUILD_JFR_TOOLS_batch:
>>     > Exception in thread "main" java.nio.file.InvalidPathException:
>>     > Malformed input or input contains unmappable characters:
>>     >
>>     /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
>>     > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>>     > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>>     > at
>>     java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>>     > at java.base/java.nio.file.Path.of(Path.java:147)
>>     > at java.base/java.nio.file.Paths.get(Paths.java:69)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>>     > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>>     > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>>     > * For target
>>     > hotspot_variant-server_tools_jvmti__the.BUILD_JVMTI_TOOLS_batch:
>>     > Exception in thread "main" java.nio.file.InvalidPathException:
>>     > Malformed input or input contains unmappable characters:
>>     >
>>     /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/tools/jvmti/_the.BUILD_JVMTI_TOOLS_batch.tmp
>>     > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>>     > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>>     > at
>>     java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>>     > at java.base/java.nio.file.Path.of(Path.java:147)
>>     > at java.base/java.nio.file.Paths.get(Paths.java:69)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>>     > at
>>     >
>>     jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>>     > at
>>     jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>>     > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>>     > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>>     >
>>     > * All command lines available in
>>     >
>>     /home/kylin/??/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/make-support/failure-logs.
>>     >
>>     > ----------
>>     > This error only arises when the compilation path contains Chinese
>>     > characters. There is no such problem with the compilation path in
>>     > English. The testing environment is Ubuntu 20.04.
>>     > I also tested having the compilation path include German and
>>     French
>>     > characters, and encountered the same compilation issues.
>>     >
>>     > Is this considered an issue? If it is, can it be added to the
>>     Java Bug
>>     > System?
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20231205/fda21896/attachment-0001.htm>

From ihse at openjdk.org  Tue Dec  5 10:40:46 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 10:40:46 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8
Message-ID: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>

We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.

This will at least have effect on how Java treats path names including unicode characters.

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

Commit messages:
 - 8321373: Build should use LC_ALL=C.UTF-8

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

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

From ihse at openjdk.org  Tue Dec  5 11:21:36 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 11:21:36 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
Message-ID: <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLdBS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>

On Mon, 4 Dec 2023 22:14:14 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Then you must add logic to check for this. Now the build will just fail if building with an older gcc. That is not acceptable.
>
> Hi Marcus (@magicus), please see the updated code which added guards to check for GCC version >= 7.5 in `src/java.base/linux/native/libsimdsort/{avx2-linux-qsort.cpp, avx512-linux-qsort.cpp}`. GCC >= 7.5 is needed to compile libsimdsort using C++17 features. Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.

That sounds weird. You can't check for if compiler options should be enabled or not inside source code files.

Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1415392615

From ihse at openjdk.org  Tue Dec  5 11:25:33 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 11:25:33 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v2]
In-Reply-To: <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
 <f9S-8qxJmZs2Fq1wj9GccpmBOkwYgoYP9J3FgwvA8WY=.329e2dda-a28d-427e-8c2e-27255c9527f8@github.com>
Message-ID: <LeCokS4AZOwIhTrphnTRtJwAGZnZP_2OrkRWnN_0IlU=.b5ff6f40-5f38-403e-b20b-2c4bded80ae4@github.com>

On Mon, 4 Dec 2023 21:27:57 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
>> 
>> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
>> 
>> The problems (and their solution) I've attempted to tackle here:
>>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator ...
>
> 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.

Build changes look fine now.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16942#pullrequestreview-1764783110

From fthevene at redhat.com  Tue Dec  5 11:30:16 2023
From: fthevene at redhat.com (Frederic Thevenet)
Date: Tue, 5 Dec 2023 12:30:16 +0100
Subject: [Proposal] Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
Message-ID: <2680b825-a017-47f4-8414-92ef5dadf9da@redhat.com>

Hi,

I would like to propose a small enhancement to the way the VersionInfo 
resources[1] embedded into native exes and dlls? on Windows are 
populated by the JDK build for its native components, and more 
specifically, the value for the property called "Company name".

It is currently always the same as that of "vendor-name" but it It would 
be really useful to some build scenarios to allow for the "company name" 
property embedded in the VersionInfo compiled resources to be different 
from the "vendor name" property that is used within the JVM (e.g. java 
-version).

So I'd like to propose the addition of? a "--with-jdk-rc-company-name" 
configure option which can be used to set "Company name" to its own 
value, independently of "'vendor-name", in the same fashion as the 
existing "--with-jdk-rc-name" can be used to override the values of 
"File description" and "Product name".

If "--with-jdk-rc-company-name" isn't used, then the vendor-name value 
is used instead, reproducing the same behavior than without this patch.

[1] 
https://learn.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource

Cheers,

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20231205/2fe6ec94/attachment-0001.htm>

From magnus.ihse.bursie at oracle.com  Tue Dec  5 12:58:42 2023
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 13:58:42 +0100
Subject: [Proposal] Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
In-Reply-To: <2680b825-a017-47f4-8414-92ef5dadf9da@redhat.com>
References: <2680b825-a017-47f4-8414-92ef5dadf9da@redhat.com>
Message-ID: <4b62dd64-a3c0-4656-a0c1-83b9038c08e3@oracle.com>


On 2023-12-05 12:30, Frederic Thevenet wrote:
>
> Hi,
>
> I would like to propose a small enhancement to the way the VersionInfo 
> resources[1] embedded into native exes and dlls? on Windows are 
> populated by the JDK build for its native components, and more 
> specifically, the value for the property called "Company name".
>
> It is currently always the same as that of "vendor-name" but it It 
> would be really useful to some build scenarios to allow for the 
> "company name" property embedded in the VersionInfo compiled resources 
> to be different from the "vendor name" property that is used within 
> the JVM (e.g. java -version).
>
> So I'd like to propose the addition of? a "--with-jdk-rc-company-name" 
> configure option which can be used to set "Company name" to its own 
> value, independently of "'vendor-name", in the same fashion as the 
> existing "--with-jdk-rc-name" can be used to override the values of 
> "File description" and "Product name".
>
So this is really a "--with-jdk-rc-vendor-name", since it will use that 
value instead of --with-jdk-vendor-name for the RC fields in Windows 
binaries?

Would --with-jdk-vendor-name be used for anything at all on Windows in 
that case?

/Magnus

> If "--with-jdk-rc-company-name" isn't used, then the vendor-name value 
> is used instead, reproducing the same behavior than without this patch.
>
> [1] 
> https://learn.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource
>
> Cheers,
>
> -- 
> Frederic Thevenet
> Senior Software Engineer - OpenJDK
> Red Hat France<https://www.redhat.com>
> BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20231205/b8566159/attachment.htm>

From ihse at openjdk.org  Tue Dec  5 13:02:47 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 13:02:47 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
Message-ID: <yB8Wm-5B6h7aHyZyF0zgoc8Bem8Q0FCO5HDo9dlAiCI=.c19369f6-d48e-4c92-9ae4-83d1478be11f@github.com>

On Fri, 1 Dec 2023 08:48:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong 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 ten additional commits since the last revision:
> 
>  - Separate neon and sve functions into two source files
>  - Merge branch 'jdk:master' into JDK-8312425
>  - Rename vmath to sleef in configure
>  - Address review comments in build system
>  - Add a bundled native lib in jdk as a bridge to libsleef
>  - Merge 'jdk:master' into JDK-8312425
>  - Disable sleef by default
>  - Merge 'jdk:master' into JDK-8312425
>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF

So you need to check both the flag and the header file? Oh well, then this is probably as good as it gets.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1840748314

From ihse at openjdk.org  Tue Dec  5 13:05:48 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Dec 2023 13:05:48 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <tHkg8-8CbvcHsfEhonfA4PxB_XXjonY5MbmunXEfFEI=.428e7a97-0bce-4f17-b93c-3275037e5a66@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
 <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
 <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>
 <tHkg8-8CbvcHsfEhonfA4PxB_XXjonY5MbmunXEfFEI=.428e7a97-0bce-4f17-b93c-3275037e5a66@github.com>
Message-ID: <Zhu-7NV4dgrBXks4CoC1tNs-4WFmoQvBo-tzqYjbY50=.210204f3-7ed2-4d40-a7c7-c1989530dca0@github.com>

On Tue, 5 Dec 2023 07:21:32 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> also, ideally, you will add the corresponding specific overrides like in ffi:
>> 
>>   AC_ARG_WITH(libffi-include, [AS_HELP_STRING([--with-libffi-include],
>>       [specify directory for the libffi include files])])
>>   AC_ARG_WITH(libffi-lib, [AS_HELP_STRING([--with-libffi-lib],
>>       [specify directory for the libffi library])])
>
> Thanks for the suggestion @magicus !
> 
> The check in current `lib-sleef.m4` is very common:
> 
> -  If user has specified libsleef root by '--with-libsleef', we assume it is the manually built sleef lib. So only `lib/` and `include/` is checked. And the flags are set based on that path.
> - If user has not specified the libsleef root, and no `SYSROOT` is set, we try `PKG_CHECK` (like what you suggested)
> - Otherwise, check `sleef.h`   
>    - We assume the sleef module is installed under one of the valid system paths if the header can be found. So just linking with `-lsleef` will success.
> 
> It's an issue in current flow like what @theRealAph met. I will add the options like `--with-libsleef-lib` and `--with-libsleef-include` like ffi. Regarding to extending the check for`--with-libsleef`, I think we can just make it simple like what it is now. Or, we have to check all the potential valid lib paths like `lib/`, `lib64/`, or maybe `lib/aarch64-linux-gnu`. The same to the `include` part.  @theRealAph @magicus , WDYT?

I'm fine with adding just --with-libsleef-lib and --with-libsleef-include to specify them directly. This makes it at least possible to use, if not overly convenient, for people using a system like Andrew's. If it annoys someone too much, we can extend it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1415576201

From fthevene at redhat.com  Tue Dec  5 14:19:16 2023
From: fthevene at redhat.com (Frederic Thevenet)
Date: Tue, 5 Dec 2023 15:19:16 +0100
Subject: [Proposal] Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
In-Reply-To: <4b62dd64-a3c0-4656-a0c1-83b9038c08e3@oracle.com>
References: <2680b825-a017-47f4-8414-92ef5dadf9da@redhat.com>
 <4b62dd64-a3c0-4656-a0c1-83b9038c08e3@oracle.com>
Message-ID: <b84495ed-193b-4153-9fd2-fbe98884d3d7@redhat.com>

Hi Magnus,


On 05/12/2023 13:58, Magnus Ihse Bursie wrote:
>
> So this is really a "--with-jdk-rc-vendor-name", since it will use 
> that value instead of --with-jdk-vendor-name for the RC fields in 
> Windows binaries?
>
I don't have a strong opinion about the name, only the target RC field 
in question is called "CompanyName", and this new option would only be 
used to set this property, so referencing to this instead of the term 
"vendor" made maybe more sense to me.

> Would --with-jdk-vendor-name be used for anything at all on Windows in 
> that case?
>

I can't find any references to an existing "--with-jdk-vendor-name" so I 
assume than you meant "--wtih-vendor-name", is that correct?

If so, yes; "--with-vendor-name" would still be used for the same things 
than it currently is, with the exception of populating the "CompanyName" 
RC field *if* "--with-jdk-rc-vendor/company-name" is also used.

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20231205/b1a0396d/attachment.htm>

From fthevene at redhat.com  Tue Dec  5 14:24:16 2023
From: fthevene at redhat.com (Frederic Thevenet)
Date: Tue, 5 Dec 2023 15:24:16 +0100
Subject: [Proposal] Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
In-Reply-To: <b84495ed-193b-4153-9fd2-fbe98884d3d7@redhat.com>
References: <2680b825-a017-47f4-8414-92ef5dadf9da@redhat.com>
 <4b62dd64-a3c0-4656-a0c1-83b9038c08e3@oracle.com>
 <b84495ed-193b-4153-9fd2-fbe98884d3d7@redhat.com>
Message-ID: <9360b600-f5f5-4d8d-979c-f58a3e267581@redhat.com>

To maybe clarify things a bit; the idea here is to allow for different 
values for the CompanyName RC field and the rest of the places where 
"vendor-name" is currently used.

You may be wondering why? The TL:DR is; we aim to make it easier to do a 
binary comparison between builds from the same source but from different 
vendors.

Now there are of course a lot of things that need to happen before this 
even matters (like aligning the native tool chains, bootjdks, etc..), 
but because differences in the compiled resources for an otherwise 
identically produced binary on Windows will cause the CRC in the PE 
header to change, this means that all native binaries resulting from 
will have significant differences that are difficult to account for.

There is only one RC field that is typically different in two builds of 
the same sources by two different vendors, and it is "CompanyName ", and 
as a matter of fact, it is of very little use: both users and java 
programs will query the java.vendor property to get this info, and if 
one's goal is to verify the provenance of a single binary file, then the 
name of signer from the digital signature on that file is far more 
reliable, as it is not so easily forged.

So having the option to set this value to something generic enough that 
it can be the same across different vendors (should they want to) - 
while keeping all of other the usage or "vendor-name" as they are now - 
seems like a good way of solving that particular problem.

Of course, the comparison process still needs to account for differences 
in the vendor strings (but that now only affects jvm.dll, instead of 
every single exe and dll) as the different digital signatures (but these 
can be easily stripped before comparing).

This is just our own reason for having this as an option, but it could 
probably prove useful in other situations too.

On 05/12/2023 15:19, Frederic Thevenet wrote:
> Hi Magnus,
>
>
> On 05/12/2023 13:58, Magnus Ihse Bursie wrote:
>>
>> So this is really a "--with-jdk-rc-vendor-name", since it will use 
>> that value instead of --with-jdk-vendor-name for the RC fields in 
>> Windows binaries?
>>
> I don't have a strong opinion about the name, only the target RC field 
> in question is called "CompanyName", and this new option would only be 
> used to set this property, so referencing to this instead of the term 
> "vendor" made maybe more sense to me.
>
>> Would --with-jdk-vendor-name be used for anything at all on Windows 
>> in that case?
>>
>
> I can't find any references to an existing "--with-jdk-vendor-name" so 
> I assume than you meant "--wtih-vendor-name", is that correct?
>
> If so, yes; "--with-vendor-name" would still be used for the same 
> things than it currently is, with the exception of populating the 
> "CompanyName" RC field *if* "--with-jdk-rc-vendor/company-name" is 
> also used.

-- 
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20231205/d80ba790/attachment-0001.htm>

From jlahoda at openjdk.org  Tue Dec  5 16:27:30 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Dec 2023 16:27:30 GMT
Subject: RFR: 8321224: ct.sym for JDK 22 contains references to internal
 modules [v3]
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <Wxv9oGOPRzHKZik6LXtbs31p1eI64qaL9fvby4AIyiE=.e5364a2c-59bf-44e1-a846-67c07512d544@github.com>

> 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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

Jan Lahoda 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 ten additional commits since the last revision:

 - Removing unneeded exports.
 - Merge branch 'master' into JDK-8321224
 - Reflecting review feedback - keeping CT_TRANSITIVE_MODULES separate from CT_MODULES.
 - Removing trailing whitespace.
 - Ensuring qualified packages are recorded properly.
 - Fixing tests.
 - Adding a way to dump the API.
 - Adding missing file.
 - 8321224: ct.sym for JDK 22 contains references to internal modules

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16942/files
  - new: https://git.openjdk.org/jdk/pull/16942/files/87927789..ce981117

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

  Stats: 56068 lines in 1520 files changed: 31819 ins; 18328 del; 5921 mod
  Patch: https://git.openjdk.org/jdk/pull/16942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16942/head:pull/16942

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

From jlahoda at openjdk.org  Tue Dec  5 17:27:48 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Dec 2023 17:27:48 GMT
Subject: Integrated: 8321224: ct.sym for JDK 22 contains references to internal
 modules
In-Reply-To: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
References: <N4DWfTxHjI_ySIZ58odsXrT5HHjdHgWyQ3tP7h2elQM=.f8164bf4-c690-4c2a-a919-4106b2cc0072@github.com>
Message-ID: <sQ4LcPdHJFMLJlarMFXm2ZUsQvPVUbqF2HOG0nqw3oA=.06c21c44-5f50-44ed-a5a4-6f95a811f0e3@github.com>

On Sun, 3 Dec 2023 21:31:42 GMT, Jan Lahoda <jlahoda at openjdk.org> 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 https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.
> 
> Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.
> 
> The problems (and their solution) I've attempted to tackle here:
>  - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
>  - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
>  - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed c...

This pull request has now been integrated.

Changeset: 18c79227
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18c7922781536366be93b2478251e32e261d06bb
Stats:     26870 lines in 194 files changed: 6101 ins; 20256 del; 513 mod

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

Reviewed-by: darcy, vromero, asotona, ihse

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

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

From duke at openjdk.org  Tue Dec  5 17:28:39 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 5 Dec 2023 17:28:39 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLdBS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
Message-ID: <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>

On Tue, 5 Dec 2023 11:19:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi Marcus (@magicus), please see the updated code which added guards to check for GCC version >= 7.5 in `src/java.base/linux/native/libsimdsort/{avx2-linux-qsort.cpp, avx512-linux-qsort.cpp}`. GCC >= 7.5 is needed to compile libsimdsort using C++17 features. Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.
>
> That sounds weird. You can't check for if compiler options should be enabled or not inside source code files.
> 
> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.

Hi Magnus (@magicus),
 
> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.

The GCC complier for versions 6 (and even 5) silently ignores the flag `-std=c++17`. It does not print any warning or error. I tested it with a toy C++ program and also by building OpenJDK using GCC 6. 

> You can't check for if compiler options should be enabled or not inside source code files.

 what I meant was, there are #ifdef guards using predefined macros in the C++ source code to check for GCC version and make the simdsort code available for compilation or not based on the GCC version


// src/java.base/linux/native/libsimdsort/simdsort-support.hpp
#if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 7) || ((__GNUC__ == 7) && (__GNUC_MINOR__ >= 5))))
        #define __SIMDSORT_SUPPORTED_LINUX
#endif



//src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp
#include "simdsort-support.hpp"
#ifdef __SIMDSORT_SUPPORTED_LINUX
            <simdsort functions>
#endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416037340

From jbhateja at openjdk.org  Tue Dec  5 19:22:49 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 5 Dec 2023 19:22:49 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <bfQ06T6iTnowcGtYhxroMpFD7c9SIconr-AaWliY7Us=.c85c0dbb-0c57-4565-81ac-bf9ad4cbeb5e@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/fc7d33f2...bc590d9f

src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 50:

> 48:             case JVM_T_DOUBLE:
> 49:                 avx2_fast_sort((double*)array, from_index, to_index, INSERTION_SORT_THRESHOLD_64BIT);
> 50:                 break;

Please add safe assertions for missing types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416173543

From jbhateja at openjdk.org  Tue Dec  5 19:47:49 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 5 Dec 2023 19:47:49 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/021f5063...bc590d9f

src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 64:

> 62:     }
> 63:     return lut;
> 64: }();

Lut64 is needed for compress64 emulation, can be removed.

src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 234:

> 232: 
> 233:     vtype::mask_storeu(leftStore, left, temp);
> 234: }

Can be removed if not being used.

src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 277:

> 275: 
> 276:     return _mm_popcnt_u32(shortMask);
> 277: }

Can be removed if not being used.

src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 44:

> 42:                 break;
> 43:             case JVM_T_FLOAT:
> 44:                 avx2_fast_sort((float*)array, from_index, to_index, INSERTION_SORT_THRESHOLD_32BIT);

Assertions for unsupported types.

src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 56:

> 54:             case JVM_T_FLOAT:
> 55:                 avx2_fast_partition((float*)array, from_index, to_index, pivot_indices, index_pivot1, index_pivot2);
> 56:                 break;

Please add assertion for unsupported types.

src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp line 235:

> 233:         return avx512_double_compressstore<zmm_vector<type_t>>(
> 234:             left_addr, right_addr, k, reg);
> 235:     }

Can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416191049
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416186096
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416186814
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416189371
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416189115
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1416187350

From erikj at openjdk.org  Wed Dec  6 00:27:33 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Dec 2023 00:27:33 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8
In-Reply-To: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
Message-ID: <ISqb1UgmICJq1Y1T31m-_F7pMD8lyc_Kj9AGnZgMM5o=.7de68dca-546a-409a-9ebc-d4cf0d29d42b@github.com>

On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
> 
> This will at least have effect on how Java treats path names including unicode characters.

I think this is ok, but would feel more at ease if you had run through all our internal builds and done compare builds with the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16971#issuecomment-1841871611

From xgong at openjdk.org  Wed Dec  6 01:29:42 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 6 Dec 2023 01:29:42 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <yB8Wm-5B6h7aHyZyF0zgoc8Bem8Q0FCO5HDo9dlAiCI=.c19369f6-d48e-4c92-9ae4-83d1478be11f@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <yB8Wm-5B6h7aHyZyF0zgoc8Bem8Q0FCO5HDo9dlAiCI=.c19369f6-d48e-4c92-9ae4-83d1478be11f@github.com>
Message-ID: <k5MReh19bzIF4GiLM_NhTBwGi8nwDHGfg_-hiSPWT5s=.001a7075-2815-4ad1-92bf-d7313bd8b2d3@github.com>

On Tue, 5 Dec 2023 13:00:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> So you need to check both the flag and the header file? Oh well, then this is probably as good as it gets.

Yes, we have to check both the flag and the header file.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1841926432

From xgong at openjdk.org  Wed Dec  6 09:15:05 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 6 Dec 2023 09:15:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v5]
In-Reply-To: <Zhu-7NV4dgrBXks4CoC1tNs-4WFmoQvBo-tzqYjbY50=.210204f3-7ed2-4d40-a7c7-c1989530dca0@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <nZFspjlPXfeQxrr5cKfbjeL3typf6DKSgNQUNszhufE=.caac471d-9c7b-4f8f-953f-04ee4a13f111@github.com>
 <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com>
 <mnf_hjWdemelALPlwcS8mnKIxR5ljIyGD6MHpqCPDsQ=.0cb49580-ed76-4728-a604-acff3dff42a5@github.com>
 <aArEqABKvjZDCxOkkpKS1rlX9Q0aafCUY8ZS3L5OBek=.f009f07b-c9e4-437b-a6d3-c86fb29d75a0@github.com>
 <vlqKSuAKzKRTXWG_hLCEJixN8oFec68IuSnfb0u9OJ0=.6c926fc3-f0f3-4ccf-b373-555948c3702b@github.com>
 <a0fi6KAaaVceRSRWzviR0W1iN-CjlkCIS9GjHAxRr5g=.324dd1aa-d4bd-48f1-8e23-604b09b75b4c@github.com>
 <tHkg8-8CbvcHsfEhonfA4PxB_XXjonY5MbmunXEfFEI=.428e7a97-0bce-4f17-b93c-3275037e5a66@github.com>
 <Zhu-7NV4dgrBXks4CoC1tNs-4WFmoQvBo-tzqYjbY50=.210204f3-7ed2-4d40-a7c7-c1989530dca0@github.com>
Message-ID: <81tcSvaI8RdngSM-Nq051Vwl81u9NyEgVr8BCV44KYw=.74051087-23af-441f-825a-83dfa70c9426@github.com>

On Tue, 5 Dec 2023 13:03:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks for the suggestion @magicus !
>> 
>> The check in current `lib-sleef.m4` is very common:
>> 
>> -  If user has specified libsleef root by '--with-libsleef', we assume it is the manually built sleef lib. So only `lib/` and `include/` is checked. And the flags are set based on that path.
>> - If user has not specified the libsleef root, and no `SYSROOT` is set, we try `PKG_CHECK` (like what you suggested)
>> - Otherwise, check `sleef.h`   
>>    - We assume the sleef module is installed under one of the valid system paths if the header can be found. So just linking with `-lsleef` will success.
>> 
>> It's an issue in current flow like what @theRealAph met. I will add the options like `--with-libsleef-lib` and `--with-libsleef-include` like ffi. Regarding to extending the check for`--with-libsleef`, I think we can just make it simple like what it is now. Or, we have to check all the potential valid lib paths like `lib/`, `lib64/`, or maybe `lib/aarch64-linux-gnu`. The same to the `include` part.  @theRealAph @magicus , WDYT?
>
> I'm fine with adding just --with-libsleef-lib and --with-libsleef-include to specify them directly. This makes it at least possible to use, if not overly convenient, for people using a system like Andrew's. If it annoys someone too much, we can extend it later.

Added these two options in latest commit. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1416962901

From xgong at openjdk.org  Wed Dec  6 09:14:58 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 6 Dec 2023 09:14:58 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v7]
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

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

  Add "--with-libsleef-lib" and "--with-libsleef-include" options

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16234/files
  - new: https://git.openjdk.org/jdk/pull/16234/files/ee5caf6d..f3ff0672

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

  Stats: 124 lines in 3 files changed: 67 ins; 33 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16234/head:pull/16234

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

From xgong at openjdk.org  Wed Dec  6 09:15:03 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 6 Dec 2023 09:15:03 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <dxnGzEBuDdVHnuYm1AaoTYNjTQzdpHHamkgb3QxEpPc=.7671caf2-74f8-4d6f-8bcf-8f189488bd0a@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <dxnGzEBuDdVHnuYm1AaoTYNjTQzdpHHamkgb3QxEpPc=.7671caf2-74f8-4d6f-8bcf-8f189488bd0a@github.com>
Message-ID: <NkqVZRkKYcpkdOOYPeRzMoLLMogCGlrgytimezITYQk=.2643ccd9-aba5-4bf0-bf41-5a09e9a25495@github.com>

On Fri, 1 Dec 2023 16:26:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Xiaohong Gong 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 ten additional commits since the last revision:
>> 
>>  - Separate neon and sve functions into two source files
>>  - Merge branch 'jdk:master' into JDK-8312425
>>  - Rename vmath to sleef in configure
>>  - Address review comments in build system
>>  - Add a bundled native lib in jdk as a bridge to libsleef
>>  - Merge 'jdk:master' into JDK-8312425
>>  - Disable sleef by default
>>  - Merge 'jdk:master' into JDK-8312425
>>  - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF
>
> doc/building.md line 639:
> 
>> 637: 
>> 638: libsleef, the [SIMD Library for Evaluating Elementary Functions](
>> 639: https://sleef.org/) is required when building libvmath.so on Linux/aarch64
> 
> This is incorrect. The library is not required, but if it is present, we will build libvmath with it.
> 
> Edit: Or rather, this is misleading. Technically it is correct, since you state that it is required when building libvmath.so, but it is easy to mistake for being required for building the JDK. The reader presumably does not know what libvmath.so is or how it is used.
> 
> Please rephrase this to so that it is clear that this is optional, but will provide performance benefits to the resulting JDK if present. You do not need to mention libvmath.so here, for no other dependency do we declare what parts of the JDK that require it -- it is not essential for this document.
> 
> Also see if you can make this paragraph and the one at the end be a bit more tighter, not the last paragraph seems to be both repeat and contradict this one.

Hi @magicus , the doc is updated. Thanks for your comment on this!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1416964362

From sakyosang at gmail.com  Wed Dec  6 09:39:05 2023
From: sakyosang at gmail.com (last last)
Date: Wed, 6 Dec 2023 17:39:05 +0800
Subject: Compile Errors in OpenJDK 11 with Non-English Characters in
 Compilation Path
In-Reply-To: <cd9bb96c-d4c9-4b96-98c9-f2aa5c76fe58@oracle.com>
References: <CAMBge5Nnw4YzdU5sfpC3OyWG+en6U911-TmphEApi+Y7OaMVww@mail.gmail.com>
 <5b3c1d56-e1e1-4afd-a117-e1e9af6ac73a@oracle.com>
 <CAMBge5MSF1C4qNr+trgMuafc9PhdmohMr5=6Oxhn4vxENBM3NQ@mail.gmail.com>
 <c3a89130-5638-456a-bb20-49011a844dd2@oracle.com>
 <cd9bb96c-d4c9-4b96-98c9-f2aa5c76fe58@oracle.com>
Message-ID: <CAMBge5PnYwknRdEZRoXPcJBwaNyiA9sAwYCJ4DWs_JQs4ZQj5A@mail.gmail.com>

The pull request at https://github.com/openjdk/jdk/pull/16971/files has
effectively addressed the issue I was facing.
Thank you for your time and effort in addressing this matter?

Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ?2023?12?5??? 18:36???

> On closer inspection, it would probably be more prudential to set the
> value of LC_ALL to C.UTF-8 in the build. It will likely help you with your
> problem. I have published a PR at
> https://github.com/openjdk/jdk/pull/16971 (JDK-8321373).
>
> /Magnus
> On 2023-11-24 13:08, Magnus Ihse Bursie wrote:
>
> Are you running on Ubuntu properly, or Ubuntu in WLS? If it is the former,
> the it is not the same problem as the other poster, which were running on
> Windows.
>
> The JDK build uses the "C" locale. This should be set automatically by the
> build system, so it should just work. But in case there is some bug, try
> exporting LC_ALL=C before building and see if it helps.
>
> Also, the point of LC_ALL is that you can specify it instead of all the
> detailed LC_* variables...
>
> /Magnus
> On 2023-11-24 08:41, last last wrote:
>
> I am currently facing the same error when build paths include Chinese
> characters ,after setting the environment variable "export
> LC_ALL=zh_CN.UTF-8" .The testing environment is also Ubuntu 2004.
> The system locale settings are as follows: LANG=zh_CN.UTF-8
> LANGUAGE=zh_CN:zh LC_CTYPE="zh_CN.UTF-8" LC_NUMERIC="zh_CN.UTF-8"
> LC_TIME="zh_CN.UTF-8" LC_COLLATE="zh_CN.UTF-8" LC_MONETARY="zh_CN.UTF-8"
> LC_MESSAGES="zh_CN.UTF-8" LC_PAPER="zh_CN.UTF-8" LC_NAME="zh_CN.UTF-8"
> LC_ADDRESS="zh_CN.UTF-8" LC_TELEPHONE="zh_CN.UTF-8"
> LC_MEASUREMENT="zh_CN.UTF-8" LC_IDENTIFICATION="zh_CN.UTF-8"
> LC_ALL=zh_CN.UTF-8
> I'm wondering if there are any other system configurations that could help
> resolve this problem. Your insights would be greatly appreciated.
>
> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> ?2023?11?23??? 22:30???
>
>> Congratulations! You get to test drive the recently updated build
>> instructions for Windows locale requirements! :-)
>>
>> Please see
>>
>> https://github.com/openjdk/jdk/blob/master/doc/building.md#locale-requirements
>>
>> In particular, I believe you need to set your system locale.
>>
>> Please report back if that solves the problem or not.
>>
>> /Magnus
>>
>>
>> On 2023-11-23 03:51, last last wrote:
>> > Hi all,
>> >
>> > I tried to build a OpenJDK11 fastdebug with paths that include Chinese
>> > characters?my build path is "/home/kylin/??/jdk11u-dev"?but i saw some
>> > error as followings:
>> >
>> > Exception in thread "main" java.nio.file.InvalidPathException:
>> > Malformed input or input contains unmappable characters:
>> >
>> /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch.tmp
>> > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>> > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>> > at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>> > at java.base/java.nio.file.Path.of(Path.java:147)
>> > at java.base/java.nio.file.Paths.get(Paths.java:69)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>> > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>> > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>> > make[3]: *** [ToolsLangtools.gmk:40:
>> >
>> /home/kylin/??/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch]
>>
>> > Error 1
>> > make[2]: *** [make/Main.gmk:73: buildtools-langtools] Error 2
>> > make[2]: *** Waiting for unfinished jobs....
>> > Exception in thread "main" java.nio.file.InvalidPathException:
>> > Malformed input or input contains unmappable characters:
>> >
>> /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/tools/jvmti/_the.BUILD_JVMTI_TOOLS_batch.tmp
>> > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>> > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>> > at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>> > at java.base/java.nio.file.Path.of(Path.java:147)
>> > at java.base/java.nio.file.Paths.get(Paths.java:69)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>> > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>> > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>> > make[3]: *** [gensrc/GensrcJvmti.gmk:45:
>> >
>> /home/kylin/??/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/tools/jvmti/_the.BUILD_JVMTI_TOOLS_batch]
>>
>> > Error 1
>> > make[3]: *** Waiting for unfinished jobs....
>> > Exception in thread "main" java.nio.file.InvalidPathException:
>> > Malformed input or input contains unmappable characters:
>> >
>> /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
>> > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>> > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>> > at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>> > at java.base/java.nio.file.Path.of(Path.java:147)
>> > at java.base/java.nio.file.Paths.get(Paths.java:69)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>> > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>> > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>> > make[3]: *** [gensrc/GensrcJfr.gmk:43:
>> >
>> /home/kylin/??/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch]
>>
>> > Error 1
>> > make[2]: *** [make/Main.gmk:265: hotspot-server-gensrc] Error 2
>> >
>> > ERROR: Build failed for target 'images' in configuration
>> > 'linux-aarch64-normal-server-fastdebug' (exit code 2)
>> >
>> > === Output from failing command(s) repeated here ===
>> > * For target
>> > buildtools_langtools_tools_classes__the.BUILD_TOOLS_LANGTOOLS_batch:
>> > Exception in thread "main" java.nio.file.InvalidPathException:
>> > Malformed input or input contains unmappable characters:
>> >
>> /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/buildtools/langtools_tools_classes/_the.BUILD_TOOLS_LANGTOOLS_batch.tmp
>> > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>> > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>> > at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>> > at java.base/java.nio.file.Path.of(Path.java:147)
>> > at java.base/java.nio.file.Paths.get(Paths.java:69)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>> > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>> > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>> > * For target
>> >
>> hotspot_variant-server_buildtools_tools_classes__the.BUILD_JFR_TOOLS_batch:
>> > Exception in thread "main" java.nio.file.InvalidPathException:
>> > Malformed input or input contains unmappable characters:
>> >
>> /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
>> > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>> > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>> > at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>> > at java.base/java.nio.file.Path.of(Path.java:147)
>> > at java.base/java.nio.file.Paths.get(Paths.java:69)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>> > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>> > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>> > * For target
>> > hotspot_variant-server_tools_jvmti__the.BUILD_JVMTI_TOOLS_batch:
>> > Exception in thread "main" java.nio.file.InvalidPathException:
>> > Malformed input or input contains unmappable characters:
>> >
>> /home/kylin/??????/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/hotspot/variant-server/tools/jvmti/_the.BUILD_JVMTI_TOOLS_batch.tmp
>> > at java.base/sun.nio.fs.UnixPath.encode(UnixPath.java:145)
>> > at java.base/sun.nio.fs.UnixPath.<init>(UnixPath.java:69)
>> > at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:279)
>> > at java.base/java.nio.file.Path.of(Path.java:147)
>> > at java.base/java.nio.file.Paths.get(Paths.java:69)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.loadCmdFile(CommandLine.java:128)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.appendParsedCommandArgs(CommandLine.java:71)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:102)
>> > at
>> >
>> jdk.compiler/com.sun.tools.javac.main.CommandLine.parse(CommandLine.java:123)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:215)
>> > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170)
>> > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57)
>> > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43)
>> >
>> > * All command lines available in
>> >
>> /home/kylin/??/jdk11u-dev/build/linux-aarch64-normal-server-fastdebug/make-support/failure-logs.
>> >
>> > ----------
>> > This error only arises when the compilation path contains Chinese
>> > characters. There is no such problem with the compilation path in
>> > English. The testing environment is Ubuntu 20.04.
>> > I also tested having the compilation path include German and French
>> > characters, and encountered the same compilation issues.
>> >
>> > Is this considered an issue? If it is, can it be added to the Java Bug
>> > System?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20231206/778661db/attachment-0001.htm>

From ihse at openjdk.org  Wed Dec  6 11:48:44 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 11:48:44 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v7]
In-Reply-To: <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
Message-ID: <0ya82eFBzsE0U96QMoP7OKmd7PAvW7GFXYP_iD_HTqE=.f12ca572-4a4e-4fbd-947b-e11f0aad81a1@github.com>

On Wed, 6 Dec 2023 09:14:58 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "--with-libsleef-lib" and "--with-libsleef-include" options

make/modules/jdk.incubator.vector/Lib.gmk line 45:

> 43:   $(eval $(call SetupJdkLibrary, BUILD_LIBVMATH, \
> 44:       NAME := vmath, \
> 45:       CFLAGS := $(CFLAGS_JDKLIB) $(LIBSLEEF_CFLAGS) -fvisibility=default, \

Why `-fvisibility=default`? (Sorry, only noticed this now)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1417156921

From ihse at openjdk.org  Wed Dec  6 11:53:42 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 11:53:42 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v7]
In-Reply-To: <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
Message-ID: <UFlHjCC7UqA5FCAjn2v5lmzML8cYEbMERY6GW2CYs3Q=.c814b409-4cd1-4e6a-b3d6-f660c24b5487@github.com>

On Wed, 6 Dec 2023 09:14:58 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "--with-libsleef-lib" and "--with-libsleef-include" options

All the makefile changes we've discussed previously now look good. However, I just noticed the additional -f flag. Why are you not exporting the functions from source code instead? That is the way we normally do it in JDK libraries. In your case, it seems like you only need to add the export to the macro.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1842720243

From ihse at openjdk.org  Wed Dec  6 12:02:42 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 12:02:42 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
Message-ID: <rh_4hxMmK37EYUk21sIZIgKff3FLD9u29HCz0b3sNts=.bfdf3f5f-686c-4b13-971e-edb321b3ea2d@github.com>

On Mon, 4 Dec 2023 22:15:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - add GCC version guards
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - Remove C++17 from C flags
>  - add avoid masked stores operation
>  - update the code to check for supported simd sort cpus
>  - Disable AVX2 sort for 64-bit types
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>  - fix jcheck failures due to windows encoding
>  - fix carriage return and change insertion sort thresholds
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/dbbc5f0a...bc590d9f

Build changes look fine. You will still need the usual 2 reviewers from hotspot.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16534#pullrequestreview-1767374468

From ihse at openjdk.org  Wed Dec  6 12:02:43 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 12:02:43 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
Message-ID: <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>

On Tue, 5 Dec 2023 17:26:06 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> That sounds weird. You can't check for if compiler options should be enabled or not inside source code files.
>> 
>> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.
>
> Hi Magnus (@magicus),
>  
>> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.
> 
> The GCC complier for versions 6 (and even 5) silently ignores the flag `-std=c++17`. It does not print any warning or error. I tested it with a toy C++ program and also by building OpenJDK using GCC 6. 
> 
>> You can't check for if compiler options should be enabled or not inside source code files.
> 
>  what I meant was, there are #ifdef guards using predefined macros in the C++ source code to check for GCC version and make the simdsort code available for compilation or not based on the GCC version
> 
> 
> // src/java.base/linux/native/libsimdsort/simdsort-support.hpp
> #if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 7) || ((__GNUC__ == 7) && (__GNUC_MINOR__ >= 5))))
>         #define __SIMDSORT_SUPPORTED_LINUX
> #endif
> 
> 
> 
> //src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp
> #include "simdsort-support.hpp"
> #ifdef __SIMDSORT_SUPPORTED_LINUX
>             <simdsort functions>
> #endif

Okay, then I guess I am fine with this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417170882

From aph-open at littlepinkcloud.com  Wed Dec  6 12:18:23 2023
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 6 Dec 2023 12:18:23 +0000
Subject: Cross compilation discussion
In-Reply-To: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
References: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
Message-ID: <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>

On 11/29/23 14:31, erik.joelsson at oracle.com wrote:
> Perhaps what we need to do is separate the notion of needing a separate
> BUILD_JDK from the notion of cross compiling.

Isn't that what --with-sysroot= usually means? In that case, you're
building against an incompatible set of libraries. By definition,
because if you're building against a compatible set of libraries you
don't have a different sysroot.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From ihse at openjdk.org  Wed Dec  6 12:33:32 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2023 12:33:32 GMT
Subject: RFR: 8321373: Build should use LC_ALL=C.UTF-8
In-Reply-To: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
References: <9CbEPFCW69TrCZHAEYtPrOLDJdDyPN3NN6jjKzPhEv4=.e70c5204-28a4-4f42-814f-927dad42b8d4@github.com>
Message-ID: <I5Y1Vef28aghX2Hol3VgEGhmaGS8HxRWXmXniiJKwUE=.2fc99904-d4c1-4f8a-9c5d-89e88baa64c8@github.com>

On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as their encoding of choice when they see this locale, but use an arbitrarily encoding, which might not properly handle all UTF-8 characters. Since in practice, all our encoding is utf8, we should tell our tools this as well.
> 
> This will at least have effect on how Java treats path names including unicode characters.

I'll make such a run. But I discovered now that C.UTF-8 is not available on (some?) macs, so I guess I'll need to add a configure check to determine if we should use C or C.UTF-8. The latter is the norm on Linux nowadays (or, to be precise, locales should in general be specified as `<locale>.UTF-8`).

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

PR Comment: https://git.openjdk.org/jdk/pull/16971#issuecomment-1842772271

From erik.joelsson at oracle.com  Wed Dec  6 14:35:07 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 6 Dec 2023 06:35:07 -0800
Subject: Cross compilation discussion
In-Reply-To: <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>
References: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
 <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>
Message-ID: <fba01ff6-2fed-40fd-86b4-180473c5d54e@oracle.com>

On 12/6/23 04:18, Andrew Haley wrote:
> On 11/29/23 14:31, erik.joelsson at oracle.com wrote:
>> Perhaps what we need to do is separate the notion of needing a separate
>> BUILD_JDK from the notion of cross compiling.
>
> Isn't that what --with-sysroot= usually means? In that case, you're
> building against an incompatible set of libraries. By definition,
> because if you're building against a compatible set of libraries you
> don't have a different sysroot.
>
No, that is not always the case, and was the point of my previous email. 
When we build the JDK at Oracle, we provide a sysroot of an older Linux 
version (the least common denominator for all our support Linux 
distros/versions). The goal is to produce a single JDK distribution that 
works on all our support Linux versions. Today we run the build on OL8 
and "cross compile" it to OL6 using a devkit/sysroot. The JDK produced 
is compatible with OL6, OL7, OL8 and OL9. Because of this we haven't 
considered it a cross compilation setup, while it does have some aspects 
of cross compiling. There is however no need to deal with a separate 
BUILD_JDK in this scenario. Also the build, host and target tuples in 
autoconf are the same.

/Erik


From aph-open at littlepinkcloud.com  Wed Dec  6 14:46:40 2023
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 6 Dec 2023 14:46:40 +0000
Subject: Cross compilation discussion
In-Reply-To: <fba01ff6-2fed-40fd-86b4-180473c5d54e@oracle.com>
References: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
 <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>
 <fba01ff6-2fed-40fd-86b4-180473c5d54e@oracle.com>
Message-ID: <789dcb6f-e326-4be6-ba49-0e50e9251e98@littlepinkcloud.com>

On 12/6/23 14:35, erik.joelsson at oracle.com wrote:
> On 12/6/23 04:18, Andrew Haley wrote:
>> On 11/29/23 14:31, erik.joelsson at oracle.com wrote:
>>> Perhaps what we need to do is separate the notion of needing a separate
>>> BUILD_JDK from the notion of cross compiling.
>>
>> Isn't that what --with-sysroot= usually means? In that case, you're
>> building against an incompatible set of libraries. By definition,
>> because if you're building against a compatible set of libraries you
>> don't have a different sysroot.
>>
> No, that is not always the case, and was the point of my previous email.
> When we build the JDK at Oracle, we provide a sysroot of an older Linux
> version (the least common denominator for all our support Linux
> distros/versions). The goal is to produce a single JDK distribution that
> works on all our support Linux versions. Today we run the build on OL8
> and "cross compile" it to OL6 using a devkit/sysroot. The JDK produced
> is compatible with OL6, OL7, OL8 and OL9. Because of this we haven't
> considered it a cross compilation setup, while it does have some aspects
> of cross compiling. There is however no need to deal with a separate
> BUILD_JDK in this scenario. Also the build, host and target tuples in
> autoconf are the same.

OK. So you are doing what I'd usually call cross compiling, sort of, but
you don't want to treat it as a cross-compiled build. It's an unusual
case, in that it is cross compiled, but it is also expected to be able to
run on the build system.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From fthevenet at openjdk.org  Wed Dec  6 15:10:52 2023
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Wed, 6 Dec 2023 15:10:52 GMT
Subject: RFR: 8321374: Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
Message-ID: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>

When building OpenJDK on the Windows platform, version information are embedded as compiled resources into every native library and executable, which typically contain version numbers, copyright information, product name and vendor name (called "Company name" in this context).

Currently, the value for "Company name" is always the same as that of "vendor-name" but it It would be really useful to some build scenarios to allow for the "company name" property embedded in the VersionInfo compiled resources to be different from the "vendor name" property that is used within the JVM (e.g. java -version). 

This PR adds  a "--with-jdk-rc-company-name" configure option which can be used to set "Company name" to its own value, independently of "'vendor-name", in the same fashion as the existing "--with-jdk-rc-name", used to override the values of "File description" and "Product name".

If "--with-jdk-rc-company-name" isn't used, then the vendor-name value is used instead, reproducing the same behavior than without this patch.

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

Commit messages:
 - 8321374: Add a configure option to explicitly set CompanyName property in VersionInfo resource for Windows exe/dll

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

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

From fthevenet at openjdk.org  Wed Dec  6 15:10:53 2023
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Wed, 6 Dec 2023 15:10:53 GMT
Subject: RFR: 8321374: Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
In-Reply-To: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
References: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
Message-ID: <A865m1zcPExMQfob_GJ87a7KObu8pmgnXW4KbXXZkuY=.da2de411-110f-400c-8783-fbc6f73b6eca@github.com>

On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> When building OpenJDK on the Windows platform, version information are embedded as compiled resources into every native library and executable, which typically contain version numbers, copyright information, product name and vendor name (called "Company name" in this context).
> 
> Currently, the value for "Company name" is always the same as that of "vendor-name" but it It would be really useful to some build scenarios to allow for the "company name" property embedded in the VersionInfo compiled resources to be different from the "vendor name" property that is used within the JVM (e.g. java -version). 
> 
> This PR adds  a "--with-jdk-rc-company-name" configure option which can be used to set "Company name" to its own value, independently of "'vendor-name", in the same fashion as the existing "--with-jdk-rc-name", used to override the values of "File description" and "Product name".
> 
> If "--with-jdk-rc-company-name" isn't used, then the vendor-name value is used instead, reproducing the same behavior than without this patch.

NB: Test "GathererTest::testMassivelyComposedGatherers" in tier1 on linux-86 is failing for reasons unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16972#issuecomment-1843058806

From duke at openjdk.org  Wed Dec  6 17:16:50 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:16:50 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
 <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>
Message-ID: <U3bL-hzUArX9ZmXqR4LSenxEn2Q0ysD5aIoEaQejpKI=.ef6a5de4-52d6-461e-8be1-e6a67ab9b3ec@github.com>

On Tue, 5 Dec 2023 19:33:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - add GCC version guards
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - Remove C++17 from C flags
>>  - add avoid masked stores operation
>>  - update the code to check for supported simd sort cpus
>>  - Disable AVX2 sort for 64-bit types
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - fix jcheck failures due to windows encoding
>>  - fix carriage return and change insertion sort thresholds
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d8b29378...bc590d9f
>
> src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp line 235:
> 
>> 233:         return avx512_double_compressstore<zmm_vector<type_t>>(
>> 234:             left_addr, right_addr, k, reg);
>> 235:     }
> 
> Can be removed.

This is needed for AVX512 sort...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417690992

From duke at openjdk.org  Wed Dec  6 17:23:03 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:23:03 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v9]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <IDxV7jNTnTc7pjv5xNTbk5LRT0D-mgcbdnkTq9TDQ7E=.6de40c65-26a0-4953-8ab3-b19bcb45e6f8@github.com>

> 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 improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  remove unused avx2 64 bit sort functions; add assertions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/bc590d9f..c143e0b9

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

  Stats: 128 lines in 4 files changed: 12 ins; 116 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From duke at openjdk.org  Wed Dec  6 17:23:04 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:23:04 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v9]
In-Reply-To: <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
 <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
Message-ID: <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>

On Wed, 6 Dec 2023 11:59:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi Magnus (@magicus),
>>  
>>> Are you saying that when compiling with GCC 6, it will just silently ignore `-std=c++17`? I'd have assumed that it printed a warning or error about an unknown or invalid option, if C++17 is not supported.
>> 
>> The GCC complier for versions 6 (and even 5) silently ignores the flag `-std=c++17`. It does not print any warning or error. I tested it with a toy C++ program and also by building OpenJDK using GCC 6. 
>> 
>>> You can't check for if compiler options should be enabled or not inside source code files.
>> 
>>  what I meant was, there are #ifdef guards using predefined macros in the C++ source code to check for GCC version and make the simdsort code available for compilation or not based on the GCC version
>> 
>> 
>> // src/java.base/linux/native/libsimdsort/simdsort-support.hpp
>> #if defined(_LP64) && (defined(__GNUC__) && ((__GNUC__ > 7) || ((__GNUC__ == 7) && (__GNUC_MINOR__ >= 5))))
>>         #define __SIMDSORT_SUPPORTED_LINUX
>> #endif
>> 
>> 
>> 
>> //src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp
>> #include "simdsort-support.hpp"
>> #ifdef __SIMDSORT_SUPPORTED_LINUX
>>             <simdsort functions>
>> #endif
>
> Okay, then I guess I am fine with this.

Thank you Magnus!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417707661

From duke at openjdk.org  Wed Dec  6 17:23:13 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:23:13 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v8]
In-Reply-To: <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
 <gvK1FxA_Bm_0ZVahS1S7Gr9GMXVmDYeRejiv3T51jVE=.9506e127-d11c-4c56-a6de-bef6d61d3cc3@github.com>
Message-ID: <zipNAArwW5naESKzcUCV2POoD2KH8Lg3V5-Y-98g5-s=.3f22dfca-a421-4cab-b836-d8e36b51af62@github.com>

On Tue, 5 Dec 2023 19:37:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - add GCC version guards
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - Remove C++17 from C flags
>>  - add avoid masked stores operation
>>  - update the code to check for supported simd sort cpus
>>  - Disable AVX2 sort for 64-bit types
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort
>>  - fix jcheck failures due to windows encoding
>>  - fix carriage return and change insertion sort thresholds
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d4151e5b...bc590d9f
>
> src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 64:
> 
>> 62:     }
>> 63:     return lut;
>> 64: }();
> 
> Lut64 is needed for compress64 emulation, can be removed.

Removed in the latest commit...

> src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 234:
> 
>> 232: 
>> 233:     vtype::mask_storeu(leftStore, left, temp);
>> 234: }
> 
> Can be removed if not being used.

Removed in the latest commit...

> src/java.base/linux/native/libsimdsort/avx2-emu-funcs.hpp line 277:
> 
>> 275: 
>> 276:     return _mm_popcnt_u32(shortMask);
>> 277: }
> 
> Can be removed if not being used.

Removed in the latest commit...

> src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 44:
> 
>> 42:                 break;
>> 43:             case JVM_T_FLOAT:
>> 44:                 avx2_fast_sort((float*)array, from_index, to_index, INSERTION_SORT_THRESHOLD_32BIT);
> 
> Assertions for unsupported types.

Added in the latest commit...

> src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 56:
> 
>> 54:             case JVM_T_FLOAT:
>> 55:                 avx2_fast_partition((float*)array, from_index, to_index, pivot_indices, index_pivot1, index_pivot2);
>> 56:                 break;
> 
> Please add assertion for unsupported types.

Added in the latest commit...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417701182
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417702999
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417702251
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417701469
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417701705

From duke at openjdk.org  Wed Dec  6 17:23:14 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:23:14 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v9]
In-Reply-To: <bfQ06T6iTnowcGtYhxroMpFD7c9SIconr-AaWliY7Us=.c85c0dbb-0c57-4565-81ac-bf9ad4cbeb5e@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <7ocsRxaWjoU2vxwPUSE7BrnLSL1bF_7Pp8vReacNJvE=.1c044b21-b27e-4e94-8db0-6ae888a1e8b9@github.com>
 <bfQ06T6iTnowcGtYhxroMpFD7c9SIconr-AaWliY7Us=.c85c0dbb-0c57-4565-81ac-bf9ad4cbeb5e@github.com>
Message-ID: <Fo2CJITUDIymCcSYskZgCSwztX4oZ-SU5QioTuNYEX4=.a4fd82a3-3a4e-4560-8b23-f49752cbb437@github.com>

On Tue, 5 Dec 2023 19:19:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused avx2 64 bit sort functions; add assertions
>
> src/java.base/linux/native/libsimdsort/avx2-linux-qsort.cpp line 50:
> 
>> 48:             case JVM_T_DOUBLE:
>> 49:                 avx2_fast_sort((double*)array, from_index, to_index, INSERTION_SORT_THRESHOLD_64BIT);
>> 50:                 break;
> 
> Please add safe assertions for missing types.

This is from an older (but outdated) commit. The assertions have been added in other cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417706670

From duke at openjdk.org  Wed Dec  6 17:48:04 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:48:04 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>

> 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 improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  add missing header files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/c143e0b9..7e124581

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

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

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

From jbhateja at openjdk.org  Wed Dec  6 17:48:05 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Dec 2023 17:48:05 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
Message-ID: <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>

On Wed, 6 Dec 2023 17:44:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing header files

LGTM, thanks!

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

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16534#pullrequestreview-1768255412

From duke at openjdk.org  Wed Dec  6 17:48:06 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 17:48:06 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
Message-ID: <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>

On Wed, 6 Dec 2023 17:42:39 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> LGTM, thanks!

Thanks Jatin!

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843372385

From sviswanathan at openjdk.org  Wed Dec  6 18:07:45 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 6 Dec 2023 18:07:45 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
Message-ID: <1H8N81T-C79IER_JFotgxYegmmZHI8-Efbe0vbmO5oU=.2150bacd-7a5a-4a66-8096-662a35cc893e@github.com>

On Wed, 6 Dec 2023 17:48:04 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing header files

@TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR today before the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843407940

From kvn at openjdk.org  Wed Dec  6 18:29:41 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 6 Dec 2023 18:29:41 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <1H8N81T-C79IER_JFotgxYegmmZHI8-Efbe0vbmO5oU=.2150bacd-7a5a-4a66-8096-662a35cc893e@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <1H8N81T-C79IER_JFotgxYegmmZHI8-Efbe0vbmO5oU=.2150bacd-7a5a-4a66-8096-662a35cc893e@github.com>
Message-ID: <AwRo0-HLJR6L8VbdZMsGrp25Rwku3yREefT0M-6N82k=.4cb8bf71-3dc3-432c-bdec-df03f0a4d74a@github.com>

On Wed, 6 Dec 2023 18:05:22 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR today before the fork.

Too late. Changes looks fine to me (I am still on fence that we moving to C++ implementation of intrinsics and require latest C++ compiler version). I need to run testing for latest version of changes before approval. Lets not rush.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843446956

From erikj at openjdk.org  Wed Dec  6 18:33:36 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Dec 2023 18:33:36 GMT
Subject: RFR: 8321374: Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
In-Reply-To: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
References: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
Message-ID: <fGG2vuEO5rpsx7fcg9Nr0wh3ACa-a7pwDdtzGVuokZk=.2287818a-03e7-4ebe-821b-5b454cf02270@github.com>

On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> When building OpenJDK on the Windows platform, version information are embedded as compiled resources into every native library and executable, which typically contain version numbers, copyright information, product name and vendor name (called "Company name" in this context).
> 
> Currently, the value for "Company name" is always the same as that of "vendor-name" but it It would be really useful to some build scenarios to allow for the "company name" property embedded in the VersionInfo compiled resources to be different from the "vendor name" property that is used within the JVM (e.g. java -version). 
> 
> This PR adds  a "--with-jdk-rc-company-name" configure option which can be used to set "Company name" to its own value, independently of "'vendor-name", in the same fashion as the existing "--with-jdk-rc-name", used to override the values of "File description" and "Product name".
> 
> If "--with-jdk-rc-company-name" isn't used, then the vendor-name value is used instead, reproducing the same behavior than without this patch.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16972#pullrequestreview-1768356733

From sviswanathan at openjdk.org  Wed Dec  6 18:33:45 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 6 Dec 2023 18:33:45 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <AwRo0-HLJR6L8VbdZMsGrp25Rwku3yREefT0M-6N82k=.4cb8bf71-3dc3-432c-bdec-df03f0a4d74a@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <1H8N81T-C79IER_JFotgxYegmmZHI8-Efbe0vbmO5oU=.2150bacd-7a5a-4a66-8096-662a35cc893e@github.com>
 <AwRo0-HLJR6L8VbdZMsGrp25Rwku3yREefT0M-6N82k=.4cb8bf71-3dc3-432c-bdec-df03f0a4d74a@github.com>
Message-ID: <oOCxQNLnxkRMKCABb6QeqLVL9MyhH7_Uwz8qn1d54gk=.e4e2e963-f622-4f16-af0b-dce3ac00474c@github.com>

On Wed, 6 Dec 2023 18:26:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR today before the fork.
>
>> @TobiHartmann @vnkozlov Please advice if we can go head and integrate this PR today before the fork.
> 
> Too late. Changes looks fine to me (I am still on fence that we moving to C++ implementation of intrinsics and require latest C++ compiler version). I need to run testing for latest version of changes before approval. Lets not rush.

Thanks a lot @vnkozlov, we will wait for your approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843454162

From darcy at openjdk.org  Wed Dec  6 18:41:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Dec 2023 18:41:57 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v6]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <Mje8eoVfAhXc5K8LoU8YnhAga5PevtfNArYMUHXn6w8=.1cab743b-c1b8-460f-b492-80defdc48745@github.com>

> 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 18 commits:

 - Regenerate JDK 22 symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Update symbol files to JDK 22 b26.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/db5613af...efe849f6

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

Changes: https://git.openjdk.org/jdk/pull/16505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=05
  Stats: 4866 lines in 98 files changed: 4828 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505

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

From kvn at openjdk.org  Wed Dec  6 18:44:47 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 6 Dec 2023 18:44:47 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
Message-ID: <dSUNCdyZym0mjS3bSuYSqKFt8d5seRlDAiYfA2ixzOQ=.7d79c7da-4972-497b-bf61-096565ebb322@github.com>

On Wed, 6 Dec 2023 17:48:04 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing header files

src/hotspot/share/opto/library_call.cpp line 5393:

> 5391:     if (!Matcher::supports_simd_sort(bt)) {
> 5392:       return false;
> 5393:     }

This check should be in `C2Compiler::is_intrinsic_supported()`

src/hotspot/share/opto/library_call.cpp line 5450:

> 5448:   if (!Matcher::supports_simd_sort(bt)) {
> 5449:     return false;
> 5450:   }

Same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417831171
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417832246

From duke at openjdk.org  Wed Dec  6 20:36:04 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 20:36:04 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v11]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <drQZwXdTKCD5FyyAYLAE0TDCSUSIaNEDdbspV3r7ahI=.07011779-006f-4a93-84c9-d1f997b130c9@github.com>

> 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 improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Change supported intrinsic check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/7e124581..9621eb04

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

  Stats: 28 lines in 4 files changed: 20 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From duke at openjdk.org  Wed Dec  6 20:36:09 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 20:36:09 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <dSUNCdyZym0mjS3bSuYSqKFt8d5seRlDAiYfA2ixzOQ=.7d79c7da-4972-497b-bf61-096565ebb322@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <dSUNCdyZym0mjS3bSuYSqKFt8d5seRlDAiYfA2ixzOQ=.7d79c7da-4972-497b-bf61-096565ebb322@github.com>
Message-ID: <Iatvjk9HYS1ka2u-FvwFQiuDKil3q2i0d48IPfEO6Dw=.67bfa7b6-c737-43b9-9a03-43dd09fa30e0@github.com>

On Wed, 6 Dec 2023 18:41:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add missing header files
>
> src/hotspot/share/opto/library_call.cpp line 5393:
> 
>> 5391:     if (!Matcher::supports_simd_sort(bt)) {
>> 5392:       return false;
>> 5393:     }
> 
> This check should be in `C2Compiler::is_intrinsic_supported()`

Hi Vladimir (@vnkozlov), please see the updated changes which use `C2Compiler::is_intrinsic_supported(id, bt)`

> src/hotspot/share/opto/library_call.cpp line 5450:
> 
>> 5448:   if (!Matcher::supports_simd_sort(bt)) {
>> 5449:     return false;
>> 5450:   }
> 
> Same.

Please see the updated changes which use C2Compiler::is_intrinsic_supported(id, bt)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417946689
PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1417946968

From kvn at openjdk.org  Wed Dec  6 22:59:41 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 6 Dec 2023 22:59:41 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v10]
In-Reply-To: <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
 <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
Message-ID: <hu1-M6J5FHsos8it_WTyop4ezyUvTMLWU0I1eDL03A0=.fb5413a8-7fd5-4d35-aeb4-932efee2c93d@github.com>

On Wed, 6 Dec 2023 17:44:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> LGTM, thanks!
>
>> LGTM, thanks!
> 
> Thanks Jatin!

@vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I will test previous version 09.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843822075

From duke at openjdk.org  Wed Dec  6 23:12:13 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 23:12:13 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>

> 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 improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Change supported intrinsic check"
  
  This reverts commit 9621eb045c2958582f81ec06b237789a07481ddd.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16534/files
  - new: https://git.openjdk.org/jdk/pull/16534/files/9621eb04..eadba369

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

  Stats: 28 lines in 4 files changed: 0 ins; 20 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534

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

From duke at openjdk.org  Wed Dec  6 23:12:14 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 6 Dec 2023 23:12:14 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
 <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
Message-ID: <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>

On Wed, 6 Dec 2023 17:44:24 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> LGTM, thanks!
>
>> LGTM, thanks!
> 
> Thanks Jatin!

> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I will test previous version 09.
@vnkozlov 
Vladimir, please see the commit reverted in the updated changes pushed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843834085

From kvn at openjdk.org  Wed Dec  6 23:17:42 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 6 Dec 2023 23:17:42 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
Message-ID: <NBATWRQteo2cmkX8BodUzAeXshXOVYhItQbIsTznTQ8=.dc220a47-e276-4153-9884-4ff89e8527d5@github.com>

On Wed, 6 Dec 2023 23:12:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Change supported intrinsic check"
>   
>   This reverts commit 9621eb045c2958582f81ec06b237789a07481ddd.

Good. I submitted testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843839669

From kvn at openjdk.org  Thu Dec  7 00:34:48 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 7 Dec 2023 00:34:48 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
 <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
 <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>
Message-ID: <huS-3meCchpHYnberzOmVeE5Z43hSFGdl9E4FSBRt-c=.8f87b240-cb11-48ed-89d9-fa59b675b6ca@github.com>

On Wed, 6 Dec 2023 23:09:01 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> LGTM, thanks!
>> 
>> Thanks Jatin!
>
>> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I will test previous version 09.
> @vnkozlov 
> Vladimir, please see the commit reverted in the updated changes pushed now.

@vamsi-parasa, please, remind me which tests check that code in `libsmdsort.so` is used?

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843938518

From duke at openjdk.org  Thu Dec  7 01:03:47 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 7 Dec 2023 01:03:47 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <hbnJof4NG7vsMtA6Ze5xcZ_XqyGKE4kJJ5t4mWDpYtA=.c0dc9cba-007f-4164-843e-1d74dd894501@github.com>
 <u8cnCqv4xmTnuYLURQdWGR_h4HNWmmuKM-zgdue3thg=.832ce475-9c89-48ae-88e2-6155c7235c41@github.com>
 <Os9Qc0Q8N6tzPrwpww6omeOU4qKq4tqZCXS2MN1_vJc=.0fddcbb5-56e6-4c27-b839-12579f462115@github.com>
 <fDxbLY4lMd-F3lJEjcX7Xu2Y86cZrOASmgfu41zFkVg=.434364bd-61eb-4bc1-a6a6-3e187cf10012@github.com>
Message-ID: <wV34H4ZTDiQHvrPvLcGAoAuhEzBnElswbSNrfQoMtEk=.9f455185-4618-4fc0-a37f-cf605d765636@github.com>

On Wed, 6 Dec 2023 23:09:01 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> LGTM, thanks!
>> 
>> Thanks Jatin!
>
>> @vamsi-parasa, sorry, I was wrong. I missed that you need to check type `bt`. Latest change is more complicated than it was before. Please revert it back (undo last change). I will test previous version 09.
> @vnkozlov 
> Vladimir, please see the commit reverted in the updated changes pushed now.

> @vamsi-parasa, please, remind me which tests check that code in `libsmdsort.so` is used?

@vnkozlov 
Please see the tests for simd sort code in `test/jdk/java/util/Arrays/Sorting.java`

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1843963054

From darcy at openjdk.org  Thu Dec  7 06:33:02 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 06:33:02 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v7]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <gP4NSm10UOuaPUJbDAASnybpKh4T1ds-zvkjHiZH2-U=.03c17fcb-c21c-49f4-8cdd-323db3e0d6a8@github.com>

> 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 21 commits:

 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Regenerate JDK 22 symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - Add symbol files.
 - Merge branch 'master' into JDK-8319413
 - Merge branch 'master' into JDK-8319413
 - ... and 11 more: https://git.openjdk.org/jdk/compare/632a3c56...4a871372

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

Changes: https://git.openjdk.org/jdk/pull/16505/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=06
  Stats: 4866 lines in 98 files changed: 4828 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/16505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505

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

From darcy at openjdk.org  Thu Dec  7 06:41:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 06:41:09 GMT
Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v8]
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <GYRRAPm9pekioWkc3IaUOzWIYFMGAcc9a2Uvkk5Q-ds=.461d318d-ad9a-45cf-a2a7-6edc17d55302@github.com>

> Time to start making preparations for JDK 23.

Joe Darcy 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/16505/files
  - new: https://git.openjdk.org/jdk/pull/16505/files/4a871372..a1aa187c

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

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

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

From xgong at openjdk.org  Thu Dec  7 06:41:16 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 7 Dec 2023 06:41:16 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v8]
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <_hHpYHZtmwFRLVj4waIAI1iWq8AINtdwx2Wtp-ZztrM=.c7f07b96-914f-4f67-a2a7-761be6e36e92@github.com>

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

Xiaohong Gong 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:

 - Remove -fvisibility in makefile and add the attribute in source code
 - Merge branch 'jdk:master' into JDK-8312425
 - Add "--with-libsleef-lib" and "--with-libsleef-include" options
 - Separate neon and sve functions into two source files
 - Merge branch 'jdk:master' into JDK-8312425
 - Rename vmath to sleef in configure
 - Address review comments in build system
 - Add a bundled native lib in jdk as a bridge to libsleef
 - Merge 'jdk:master' into JDK-8312425
 - Disable sleef by default
 - ... and 2 more: https://git.openjdk.org/jdk/compare/6feb6794...c55357b6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16234/files
  - new: https://git.openjdk.org/jdk/pull/16234/files/f3ff0672..c55357b6

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

  Stats: 83778 lines in 1591 files changed: 38309 ins; 39305 del; 6164 mod
  Patch: https://git.openjdk.org/jdk/pull/16234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16234/head:pull/16234

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

From sspitsyn at openjdk.org  Thu Dec  7 07:08:47 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Dec 2023 07:08:47 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
Message-ID: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>

This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
The deadlocking scenario is well described by Patricio in a bug report comment.
In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.

The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.

Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.

New test was developed by Patricio:
 `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
The test is never failing with this fix.

Testing:
 - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
 - tested with mach5 tiers 1-6

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

Commit messages:
 - added @summary to new test SuspendWithInterruptLock.java
 - add new test SuspendWithInterruptLock.java
 - 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

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

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

From xgong at openjdk.org  Thu Dec  7 09:30:01 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 7 Dec 2023 09:30:01 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
Message-ID: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>

> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
> 
> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
> 
> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
> 
> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
> 
> [1] https://github.com/openjdk/jdk/pull/3638
> [2] https://sleef.org/
> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
> [4] https://packages.debian.org/bookworm/libsleef3
> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html

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

  Fix potential attribute issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16234/files
  - new: https://git.openjdk.org/jdk/pull/16234/files/c55357b6..7a4be736

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

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

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

From xgong at openjdk.org  Thu Dec  7 09:30:05 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 7 Dec 2023 09:30:05 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v7]
In-Reply-To: <0ya82eFBzsE0U96QMoP7OKmd7PAvW7GFXYP_iD_HTqE=.f12ca572-4a4e-4fbd-947b-e11f0aad81a1@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <VaRAGqDPyx-9MRdtDUT1EwN2bEwJM0V3o0_AJpmNdBU=.0af098f2-aedf-43e2-a7b1-d127b02f14ba@github.com>
 <0ya82eFBzsE0U96QMoP7OKmd7PAvW7GFXYP_iD_HTqE=.f12ca572-4a4e-4fbd-947b-e11f0aad81a1@github.com>
Message-ID: <sbP1Ok5WY4IwPagSf38zMmDSs2oYs2O6uO9nC-oQVuk=.d20ad8ac-6cbb-47ae-aa88-29a4def8552f@github.com>

On Wed, 6 Dec 2023 11:46:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add "--with-libsleef-lib" and "--with-libsleef-include" options
>
> make/modules/jdk.incubator.vector/Lib.gmk line 45:
> 
>> 43:   $(eval $(call SetupJdkLibrary, BUILD_LIBVMATH, \
>> 44:       NAME := vmath, \
>> 45:       CFLAGS := $(CFLAGS_JDKLIB) $(LIBSLEEF_CFLAGS) -fvisibility=default, \
> 
> Why `-fvisibility=default`? (Sorry, only noticed this now)

Yeah. Considering all the symbols in this lib are global and need to be exported, I added this flag here instead of the source code. I'v removed this in latest commit, and added the attribute visibility in source code like other jdk code. Please help to review again. Thanks a lot!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1418458207

From ihse at openjdk.org  Thu Dec  7 09:42:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 7 Dec 2023 09:42:45 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <aZvKwyT8NMnJgFWlEbIrzO5ekyF9FRBYzHKmyEbMXQY=.de5cda35-5ac9-48fd-b733-68364cb2141b@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

Build changes finally look good. Great, actually! Thanks for persisting, despite the many rounds of review.

You will still need the 2 hotspot reviews for the hotspot part of the patch.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16234#pullrequestreview-1769660206

From darcy at openjdk.org  Thu Dec  7 17:04:41 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 7 Dec 2023 17:04:41 GMT
Subject: Integrated: JDK-8319413: Start of release updates for JDK 23
In-Reply-To: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
References: <l4yhr-qaWjB3KpNoAoFo_J3hEpUswftopURWhEqzkyI=.2141521f-0158-4baa-af3e-155b3cd73b5c@github.com>
Message-ID: <zmVMgvlrXfVNIim6gb1ZSPp2jteSr8-AwHK01zktclc=.fa0c0145-9b1e-42c0-86ca-8b677f55f07b@github.com>

On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start making preparations for JDK 23.

This pull request has now been integrated.

Changeset: 519ecd35
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/519ecd352a66633589f160db7390647d90e36b99
Stats:     4872 lines in 98 files changed: 4828 ins; 0 del; 44 mod

8319413: Start of release updates for JDK 23
8319414: Add SourceVersion.RELEASE_23
8319416: Add source 23 and target 23 to javac

Reviewed-by: iris, erikj, alanb, vromero

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

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

From djelinski at openjdk.org  Thu Dec  7 19:55:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 7 Dec 2023 19:55:06 GMT
Subject: RFR: 8321533: Clang build for Windows
Message-ID: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>

I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.

Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.

Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.

In order to use the clang compiler:
- install Visual Studio 2022
- install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
- configure `--with-toolchain-type=clcl`
- compile as usual.

Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

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

Commit messages:
 - Rename mscl->clcl
 - Add MSCL toolchain type

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

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

From erikj at openjdk.org  Thu Dec  7 20:56:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Dec 2023 20:56:17 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <2rHI8VWXECNcwZ1EW6s8RNIGlR7gLR4htZ39B1SmMiY=.e802099a-82dc-4656-ace6-066c497b3bcd@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

I only commented on minor style issues. I would like to hear from others what they think about the validity of this approach.

Does it work with current devkits, or are they missing something? How is build performance relative to regular `cl`?

make/autoconf/spec.gmk.in line 167:

> 165:   export PATH := @TOOLCHAIN_PATH@:$(PATH)
> 166: endif
> 167: ifeq (@TOOLCHAIN_TYPE@, clcl)

You can combine this with the ifeq above using an ifneq like this:


ifneq ($(filter @TOOLCHAIN_TYPE@, microsoft clcl), )

make/common/NativeCompilation.gmk line 450:

> 448: 	$$(call LogInfo, Compiling $$($1_FILENAME) (for $$($$($1_BASE)_BASENAME)))
> 449: 	$$(call MakeDir, $$(@D))
> 450:         ifeq ($(findstring $(TOOLCHAIN_TYPE), microsoft clcl), )

I know `findstring` is used frequently for this construct in the makefile, but I prefer `filter` in cases like this as it only matches complete words.

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

PR Review: https://git.openjdk.org/jdk/pull/17019#pullrequestreview-1771104027
PR Review Comment: https://git.openjdk.org/jdk/pull/17019#discussion_r1419645950
PR Review Comment: https://git.openjdk.org/jdk/pull/17019#discussion_r1419649071

From erikj at openjdk.org  Thu Dec  7 23:34:23 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Dec 2023 23:34:23 GMT
Subject: RFR: 8321557: Move SOURCE line verification of OracleJDK out of
 OpenJDK
Message-ID: <UyyQ3xvNFLcrqmEvxX38ST7mrl4LQR-DjgZXZGf3ASE=.aa8f51e5-6c62-4f49-868b-a297883ff0c8@github.com>

The main goal of this patch is to remove the OracleJDK specific verification of the SOURCE field in the release file from the OpenJDK test. While at it, I decided to do some cleanup as well to make the code a bit more modern and less unnecessarily verbose.

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

Commit messages:
 - Rename method
 - JDK-8321557

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

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

From kvn at openjdk.org  Fri Dec  8 00:36:21 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 8 Dec 2023 00:36:21 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
Message-ID: <Y7s_Omtt8q8W9rzWEypxgjVtZn3MAHfISJZgeFApL2k=.f369a72e-50d3-4ffd-a616-3210ac823d8e@github.com>

On Wed, 6 Dec 2023 23:12:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Change supported intrinsic check"
>   
>   This reverts commit 9621eb045c2958582f81ec06b237789a07481ddd.

Testing have only one failure in closed tests and I need to fix it before this can be pushed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1846315767

From duke at openjdk.org  Fri Dec  8 00:36:22 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 8 Dec 2023 00:36:22 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <Y7s_Omtt8q8W9rzWEypxgjVtZn3MAHfISJZgeFApL2k=.f369a72e-50d3-4ffd-a616-3210ac823d8e@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
 <Y7s_Omtt8q8W9rzWEypxgjVtZn3MAHfISJZgeFApL2k=.f369a72e-50d3-4ffd-a616-3210ac823d8e@github.com>
Message-ID: <YcEQlYSi5wgr6gcw7Led1o415DIIHXu6kRYL4cGndqQ=.11796f39-7161-495e-acc1-cbdbfff2a818@github.com>

On Fri, 8 Dec 2023 00:31:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Testing have only one failure in closed tests and I need to fix it before this can be pushed.

Thanks Vladimir for the update. Is the test failure because of this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1846317507

From kvn at openjdk.org  Fri Dec  8 00:47:23 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 8 Dec 2023 00:47:23 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <YcEQlYSi5wgr6gcw7Led1o415DIIHXu6kRYL4cGndqQ=.11796f39-7161-495e-acc1-cbdbfff2a818@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
 <Y7s_Omtt8q8W9rzWEypxgjVtZn3MAHfISJZgeFApL2k=.f369a72e-50d3-4ffd-a616-3210ac823d8e@github.com>
 <YcEQlYSi5wgr6gcw7Led1o415DIIHXu6kRYL4cGndqQ=.11796f39-7161-495e-acc1-cbdbfff2a818@github.com>
Message-ID: <PXjw2KihDJ5OZNkYQ12N7O6FyZIVaj1NG_wtGZhBrFo=.3e805224-5fc1-4580-9555-de70fbbc67cf@github.com>

On Fri, 8 Dec 2023 00:33:49 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> > Testing have only one failure in closed tests and I need to fix it before this can be pushed.
> 
> Thanks Vladimir for the update. Is the test failure because of this PR?

Yes. One of our test, which checks integrity of built JDK, is confused by changes in libsimdsort.so.

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1846326542

From xgong at openjdk.org  Fri Dec  8 00:53:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 8 Dec 2023 00:53:27 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <hd3QLWKom9VFSeX9AxaD6vzAN0goIoUn74UDH3cdumY=.e7c4a01c-620a-4686-be89-4ad82ba1f340@github.com>
Message-ID: <b96RhEmwIImjWS3oyk9PxePfyguzdnMH99r5ehZymyM=.713daa09-855a-48e7-9aff-af671cc947c9@github.com>

On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]).
>> 
>> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead.
>> 
>> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly.
>> 
>> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts.
>> 
>> [1] https://github.com/openjdk/jdk/pull/3638
>> [2] https://sleef.org/
>> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/
>> [4] https://packages.debian.org/bookworm/libsleef3
>> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix potential attribute issue

> Build changes finally look good. Great, actually! Thanks for persisting, despite the many rounds of review.
> 
> You will still need the 2 hotspot reviews for the hotspot part of the patch.
> 
> /reviewers 3

Thanks for the review and all the comments!

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1846330893

From sspitsyn at openjdk.org  Fri Dec  8 01:16:52 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Dec 2023 01:16:52 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v2]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <rFV2kG_1cw-LDPZLlFeYZd6cwCQV_JSkmqSFMm9JSKE=.a4d911c2-75b6-44a6-bdff-e29121a879b6@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - 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 pull request now contains four commits:

 - Resolved merge conflict in VirtualThread.java
 - added @summary to new test SuspendWithInterruptLock.java
 - add new test SuspendWithInterruptLock.java
 - 8311218: fatal error: stuck in JvmtiVTMSTransitionDisabler::VTMS_transition_disable

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

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

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

From jwaters at openjdk.org  Fri Dec  8 08:03:15 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Dec 2023 08:03:15 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <qnJw4dl45Kz2tKdx6WXNowYu23WKoOzuuyfe2VbfzP8=.9787d9b1-1f3b-4ed7-ba45-fda98e0dfdec@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

Wow, you're really leaving me in the dust here :P

Is it possible to fold clang-cl into the microsoft toolchain instead, and just pass clang-cl as the compiler instead of cl?

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1846726950

From djelinski at openjdk.org  Fri Dec  8 09:40:15 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Dec 2023 09:40:15 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <PcEiX2hQXFTyHZ9Jmq1nT9Bbz1rEa6K3RLL-TKL7Sfs=.9a7c9315-1782-4080-8a61-5c7b486152d5@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

Thanks for the suggestions, I'll apply them shortly.

The current devkits do not contain the required clang frontend (clang-cl.exe, llvm-lib.exe and lld-link.exe).

I compared `make hotspot` performance, got the following results:
- default toolchain (msvc 19.35): 6 min 35 sec
- this PR (clang 15.0.1): 7 min 41 sec
- this PR with compiler warnings disabled: 6 min 47 sec

so it's going to be slightly slower than MSVC once we have all the warning suppressions in place.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1846860566

From djelinski at openjdk.org  Fri Dec  8 09:49:13 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Dec 2023 09:49:13 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <qnJw4dl45Kz2tKdx6WXNowYu23WKoOzuuyfe2VbfzP8=.9787d9b1-1f3b-4ed7-ba45-fda98e0dfdec@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
 <qnJw4dl45Kz2tKdx6WXNowYu23WKoOzuuyfe2VbfzP8=.9787d9b1-1f3b-4ed7-ba45-fda98e0dfdec@github.com>
Message-ID: <mLfqZ6cEtXdjsXSWALckIqK4PUMnnE9GjKUtAPT_R5A=.d83fbf9a-2628-4916-9c87-d2f08d3f100b@github.com>

On Fri, 8 Dec 2023 08:00:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Is it possible to fold clang-cl into the microsoft toolchain instead, and just pass clang-cl as the compiler instead of cl?

I suppose it's possible; clang-cl output is supposed to be compatible with link & lib, and most command line options are similar.

The thing is, when it comes to warning control, only W0-W4 are somewhat similar between clang-cl and microsoft; other than that, clang-cl accepts the same options as the regular clang. Folding clang-cl into microsoft would leave us with no way to suppress warnings.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1846872278

From jwaters at openjdk.org  Fri Dec  8 10:15:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Dec 2023 10:15:13 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <mLfqZ6cEtXdjsXSWALckIqK4PUMnnE9GjKUtAPT_R5A=.d83fbf9a-2628-4916-9c87-d2f08d3f100b@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
 <qnJw4dl45Kz2tKdx6WXNowYu23WKoOzuuyfe2VbfzP8=.9787d9b1-1f3b-4ed7-ba45-fda98e0dfdec@github.com>
 <mLfqZ6cEtXdjsXSWALckIqK4PUMnnE9GjKUtAPT_R5A=.d83fbf9a-2628-4916-9c87-d2f08d3f100b@github.com>
Message-ID: <F-hjEauqN9fX7DlykdGByQLsAp3Dq3Zt3jolhInFRVM=.08f9ec3c-db70-4755-9c35-c376cc6277ff@github.com>

On Fri, 8 Dec 2023 09:46:59 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> > Is it possible to fold clang-cl into the microsoft toolchain instead, and just pass clang-cl as the compiler instead of cl?
> 
> I suppose it's possible; clang-cl output is supposed to be compatible with link & lib, and most command line options are similar.
> 
> The thing is, when it comes to warning control, only W0-W4 are somewhat similar between clang-cl and microsoft; other than that, clang-cl accepts the same options as the regular clang. Folding clang-cl into microsoft would leave us with no way to suppress warnings.

My main concern is that this occludes clang proper, if and when that becomes a thing. If so, the clcl options might become a little redundant when compared with the existing clang option. Maybe there can be some specialized code to detect if microsoft is really clang-cl in disguise, or perhaps this could use the clang option that we already have in the build system, and then have --with-toolchain-type=clang mean either clang-cl or clang proper when the platform is Windows

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1846906553

From ihse at openjdk.org  Fri Dec  8 10:26:23 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 10:26:23 GMT
Subject: RFR: 8316657: Support whitebox testing in microbenchmarks
Message-ID: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>

The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.

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

Commit messages:
 - 8316657: Support whitebox testing in microbenchmarks

Changes: https://git.openjdk.org/jdk/pull/16996/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316657
  Stats: 61 lines in 4 files changed: 41 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16996/head:pull/16996

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

From ihse at openjdk.org  Fri Dec  8 10:51:17 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 10:51:17 GMT
Subject: RFR: 8321374: Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
In-Reply-To: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
References: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
Message-ID: <qCMdBXKQT6yccF3uY90u4Z1R-LzDcSjR51tqQGoYvHo=.8f0833cc-5211-4188-821e-46e17a4a88fd@github.com>

On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> When building OpenJDK on the Windows platform, version information are embedded as compiled resources into every native library and executable, which typically contain version numbers, copyright information, product name and vendor name (called "Company name" in this context).
> 
> Currently, the value for "Company name" is always the same as that of "vendor-name" but it It would be really useful to some build scenarios to allow for the "company name" property embedded in the VersionInfo compiled resources to be different from the "vendor name" property that is used within the JVM (e.g. java -version). 
> 
> This PR adds  a "--with-jdk-rc-company-name" configure option which can be used to set "Company name" to its own value, independently of "'vendor-name", in the same fashion as the existing "--with-jdk-rc-name", used to override the values of "File description" and "Product name".
> 
> If "--with-jdk-rc-company-name" isn't used, then the vendor-name value is used instead, reproducing the same behavior than without this patch.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16972#pullrequestreview-1772102544

From sspitsyn at openjdk.org  Fri Dec  8 11:54:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Dec 2023 11:54:40 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
Message-ID: <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>

> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
> The deadlocking scenario is well described by Patricio in a bug report comment.
> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
> 
> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
> 
> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
> 
> New test was developed by Patricio:
>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
> The test is never failing with this fix.
> 
> Testing:
>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>  - tested with mach5 tiers 1-6

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

  review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17011/files
  - new: https://git.openjdk.org/jdk/pull/17011/files/ccba940d..18f1752e

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

  Stats: 80 lines in 9 files changed: 25 ins; 7 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/17011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17011/head:pull/17011

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

From djelinski at openjdk.org  Fri Dec  8 11:59:16 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Dec 2023 11:59:16 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <dBu31ugzDrOVitM5n2mKCdm70wmIXCF2-uaiYvoWDwc=.3587bf3a-8948-43e1-b197-7b47b5787bac@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

Well I can't tell the future, but at this point in time, implementing support for clang-cl requires much less effort than implementing  support for the gcc clang frontend. The end result is equivalent - in both cases we use the same compiler.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1847052032

From alanb at openjdk.org  Fri Dec  8 12:09:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Dec 2023 12:09:15 GMT
Subject: RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable [v3]
In-Reply-To: <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
References: <aZ2ReW3s9t8BsRwK3PmHyqpMgdfon61RFeBaAfEq1Pg=.1edb2c84-abc4-4ea0-84fe-5cf47f398025@github.com>
 <-3HkgdDQk9480AnHQeIxaNsqK0nVzjaf6UZJ5E9LGHo=.bdff2ed6-db98-4a77-832f-6accad54245f@github.com>
Message-ID: <pS1TWVzQt5czKRifws8S2UgvBEQRtbxt6inw4L__KAs=.3b671378-e651-4a10-99a0-e317254a5a32@github.com>

On Fri, 8 Dec 2023 11:54:40 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fix is for JDK 23 but the intention is to back port it to 22 in RDP-1 time frame.
>> It is fixing a deadlock issue between `VirtualThread` class critical sections with the `interruptLock` (in methods: `unpark()`, `interrupt()`, `getAndClearInterrupt()`, `threadState()`, `toString()`), `JvmtiVTMSTransitionDisabler` and JVMTI `Suspend/Resume` mechanisms.
>> The deadlocking scenario is well described by Patricio in a bug report comment.
>> In simple words, a virtual thread should not be suspended during 'interruptLock' critical sections.
>> 
>> The fix is to record that a virtual thread is in a critical section (`JavaThread`'s `_in_critical_section` bit) by notifying the VM/JVMTI about begin/end of critical section.
>> This bit is used in `HandshakeState::get_op_for_self()` to filter out any `HandshakeOperation` if a target `JavaThread` is in a critical section.
>> 
>> Some of new notifications with `notifyJvmtiSync()` method is on a performance critical path. It is why this method has been intrincified.
>> 
>> New test was developed by Patricio:
>>  `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>> The test is very nice as it reliably in 100% reproduces the deadlock without the fix.
>> The test is never failing with this fix.
>> 
>> Testing:
>>  - tested with newly added test: `test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendWithInterruptLock`
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: (1) rename notifyJvmti method; (2) add try-final statements to VirtualThread methods

I chatted briefly with @sspitsyn about this. A couple of points:
- It shouldn't be necessary to touch mount/unmount as the thread identity is the carrier, not the virtual thread, when executing the "critical code".
- toggle_is_in_critical_section needs to detect reentrancy, it is otherwise too early to refactor the Java code, e.g. call threadState while holding the interrupt lock.
- All the use-sides will need to use try-finally to more reliably revert the critical section flag when rewinding.
- The naming is very problematic, we'll need to replace with methods that are clearly named enter and exit critical section. Ongoing work in this area to support monitors has to introduce some temporary pinning so there will be enter/exitCriticalSection methods, that's a better place for the JVMTI hooks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17011#issuecomment-1847063362

From fthevenet at openjdk.org  Fri Dec  8 13:48:15 2023
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Fri, 8 Dec 2023 13:48:15 GMT
Subject: RFR: 8321374: Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
In-Reply-To: <fGG2vuEO5rpsx7fcg9Nr0wh3ACa-a7pwDdtzGVuokZk=.2287818a-03e7-4ebe-821b-5b454cf02270@github.com>
References: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
 <fGG2vuEO5rpsx7fcg9Nr0wh3ACa-a7pwDdtzGVuokZk=.2287818a-03e7-4ebe-821b-5b454cf02270@github.com>
Message-ID: <k8kMJ2j4w-t9LcUOoOlUObnCsXXojukoeVTpCtG-VUw=.ab536434-ae3b-42a3-a1ff-37537b22b99d@github.com>

On Wed, 6 Dec 2023 18:30:58 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> When building OpenJDK on the Windows platform, version information are embedded as compiled resources into every native library and executable, which typically contain version numbers, copyright information, product name and vendor name (called "Company name" in this context).
>> 
>> Currently, the value for "Company name" is always the same as that of "vendor-name" but it It would be really useful to some build scenarios to allow for the "company name" property embedded in the VersionInfo compiled resources to be different from the "vendor name" property that is used within the JVM (e.g. java -version). 
>> 
>> This PR adds  a "--with-jdk-rc-company-name" configure option which can be used to set "Company name" to its own value, independently of "'vendor-name", in the same fashion as the existing "--with-jdk-rc-name", used to override the values of "File description" and "Product name".
>> 
>> If "--with-jdk-rc-company-name" isn't used, then the vendor-name value is used instead, reproducing the same behavior than without this patch.
>
> Marked as reviewed by erikj (Reviewer).

Thanks for the reviews @erikj79 and @magicus.
Could one of you please sponsor this?

Cheers!

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

PR Comment: https://git.openjdk.org/jdk/pull/16972#issuecomment-1847188041

From fthevenet at openjdk.org  Fri Dec  8 14:13:21 2023
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Fri, 8 Dec 2023 14:13:21 GMT
Subject: RFR: 8321374: Add a configure option to explicitly set CompanyName
 property in VersionInfo resource for Windows exe/dll
In-Reply-To: <qCMdBXKQT6yccF3uY90u4Z1R-LzDcSjR51tqQGoYvHo=.8f0833cc-5211-4188-821e-46e17a4a88fd@github.com>
References: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
 <qCMdBXKQT6yccF3uY90u4Z1R-LzDcSjR51tqQGoYvHo=.8f0833cc-5211-4188-821e-46e17a4a88fd@github.com>
Message-ID: <zeG-pb-FDzqBQPX12go0gaLkUsyqCOb1ROwYiKVBchY=.4378c93b-0e82-49ca-bc4f-a51f0e9427c4@github.com>

On Fri, 8 Dec 2023 10:48:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When building OpenJDK on the Windows platform, version information are embedded as compiled resources into every native library and executable, which typically contain version numbers, copyright information, product name and vendor name (called "Company name" in this context).
>> 
>> Currently, the value for "Company name" is always the same as that of "vendor-name" but it It would be really useful to some build scenarios to allow for the "company name" property embedded in the VersionInfo compiled resources to be different from the "vendor name" property that is used within the JVM (e.g. java -version). 
>> 
>> This PR adds  a "--with-jdk-rc-company-name" configure option which can be used to set "Company name" to its own value, independently of "'vendor-name", in the same fashion as the existing "--with-jdk-rc-name", used to override the values of "File description" and "Product name".
>> 
>> If "--with-jdk-rc-company-name" isn't used, then the vendor-name value is used instead, reproducing the same behavior than without this patch.
>
> Marked as reviewed by ihse (Reviewer).

Thanks @magicus

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

PR Comment: https://git.openjdk.org/jdk/pull/16972#issuecomment-1847228469

From fthevenet at openjdk.org  Fri Dec  8 14:13:23 2023
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Fri, 8 Dec 2023 14:13:23 GMT
Subject: Integrated: 8321374: Add a configure option to explicitly set
 CompanyName property in VersionInfo resource for Windows exe/dll
In-Reply-To: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
References: <BL4C4cDDIyuslJdm1wwy_HZNscu6V8lfBvQNZ67SmQE=.c6712bb1-7a31-44b4-97ed-860cc3786d89@github.com>
Message-ID: <irlOekXhTgJ5sGkOfU0EaTyTDvO1T_EOw33whishOR8=.043e956a-9059-4fb8-b5e4-9ade3fa7e004@github.com>

On Tue, 5 Dec 2023 11:15:18 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> When building OpenJDK on the Windows platform, version information are embedded as compiled resources into every native library and executable, which typically contain version numbers, copyright information, product name and vendor name (called "Company name" in this context).
> 
> Currently, the value for "Company name" is always the same as that of "vendor-name" but it It would be really useful to some build scenarios to allow for the "company name" property embedded in the VersionInfo compiled resources to be different from the "vendor name" property that is used within the JVM (e.g. java -version). 
> 
> This PR adds  a "--with-jdk-rc-company-name" configure option which can be used to set "Company name" to its own value, independently of "'vendor-name", in the same fashion as the existing "--with-jdk-rc-name", used to override the values of "File description" and "Product name".
> 
> If "--with-jdk-rc-company-name" isn't used, then the vendor-name value is used instead, reproducing the same behavior than without this patch.

This pull request has now been integrated.

Changeset: 05f95093
Author:    Frederic Thevenet <fthevenet at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05f950934ee720c82e9b62dd8d31e13bab7775da
Stats:     11 lines in 3 files changed: 10 ins; 0 del; 1 mod

8321374: Add a configure option to explicitly set CompanyName property in VersionInfo resource for Windows exe/dll

Reviewed-by: erikj, ihse

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

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

From erikj at openjdk.org  Fri Dec  8 14:20:14 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Dec 2023 14:20:14 GMT
Subject: RFR: 8316657: Support whitebox testing in microbenchmarks
In-Reply-To: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
References: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
Message-ID: <pOtI2EUP7pMZoy6NFjDM_cCoMQbSg3Yn_Q9KgMtiBKk=.edb2bbd5-9b39-493f-8874-98af41765ef2@github.com>

On Wed, 6 Dec 2023 15:32:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16996#pullrequestreview-1772448490

From redestad at openjdk.org  Fri Dec  8 14:49:15 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 8 Dec 2023 14:49:15 GMT
Subject: RFR: 8316657: Support whitebox testing in microbenchmarks
In-Reply-To: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
References: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
Message-ID: <kBhomDqmLfaYbwlFn6H0NCdXHykcWvXDwk0OJFIRfh0=.111c1c68-95c6-4e92-85d5-2835b2407122@github.com>

On Wed, 6 Dec 2023 15:32:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.

Adding wb.jar to the test image is great. Maybe that could be done separately?

I think we need a different solution here that does not pollute the bootclasspath for all microbenchmarks with wb.jar. Ideally `make test TEST=micro:foo` should be strictly an alias for `$JDK/bin/java -jar test/micro/benchmarks.jar foo` (none of our scripts and lab setups use the `make` support to run microbenchmarks but rather download the test image and run the jar directly); this PR steps away from that ideal.

Something self-contained where the wb.jar is appended explicitly to forked runs by those tests that explicitly need it would be strongly preferred. Perhaps we can do so in a robust fashion with annotations alone since the wb.jar should be relative to the benchmarks.jar, perhaps through the JMH java API.

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

PR Comment: https://git.openjdk.org/jdk/pull/16996#issuecomment-1847306934

From ihse at openjdk.org  Fri Dec  8 14:51:33 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 14:51:33 GMT
Subject: RFR: 8321597: Use .template consistently for files treated as
 templates by the build
Message-ID: <EZOOqtqdYFsXiz11Mv7sBtBfYA0ifk1T78cs4CZ1zLs=.290c82ea-c021-4ef8-bc26-4ae525724ffe@github.com>

Some files are used as "templates" in the build, that is, they are almost, but not fully, in the intended state. Instead, they have some pattern markers that need to be replaced with actual content as part of the build.

As a convention, most such files are named as `<resulting name>.template`, e.g. `VersionProps.java.template`, to indicate that this is almost, but not fully, a Java file.

A few files were created before this convention was fully embraced. These should be renamed to match the pattern.

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

Commit messages:
 - Merge branch 'master' into template-rename
 - 8321597: Use .template consistently for files treated as templates by the build

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

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

From erikj at openjdk.org  Fri Dec  8 15:18:13 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Dec 2023 15:18:13 GMT
Subject: RFR: 8321597: Use .template consistently for files treated as
 templates by the build
In-Reply-To: <EZOOqtqdYFsXiz11Mv7sBtBfYA0ifk1T78cs4CZ1zLs=.290c82ea-c021-4ef8-bc26-4ae525724ffe@github.com>
References: <EZOOqtqdYFsXiz11Mv7sBtBfYA0ifk1T78cs4CZ1zLs=.290c82ea-c021-4ef8-bc26-4ae525724ffe@github.com>
Message-ID: <eeQV0E2bVXj-v_bfECPNrv6ZlRVjYPwInE6JsOuBPVU=.a5dc1c2d-0181-4ab4-8047-493df20b4a08@github.com>

On Fri, 8 Dec 2023 14:43:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files are used as "templates" in the build, that is, they are almost, but not fully, in the intended state. Instead, they have some pattern markers that need to be replaced with actual content as part of the build.
> 
> As a convention, most such files are named as `<resulting name>.template`, e.g. `VersionProps.java.template`, to indicate that this is almost, but not fully, a Java file.
> 
> A few files were created before this convention was fully embraced. These should be renamed to match the pattern.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17033#pullrequestreview-1772602285

From eastigeevich at openjdk.org  Fri Dec  8 15:19:44 2023
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Fri, 8 Dec 2023 15:19:44 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v8]
In-Reply-To: <yBk1E0UvGMs1SkRvJ4Ffw5EVjAoIISDDYtoX4bNUZqE=.54dca99d-e0c0-4ae5-bc60-6519ba695d37@github.com>
References: <XbiGOUrvZoi-2JNIMmUGYXGN9iv2jD7o3cuBrtgvyj4=.3656f9cc-7e66-45be-a5ef-35ba481129e0@github.com>
 <yBk1E0UvGMs1SkRvJ4Ffw5EVjAoIISDDYtoX4bNUZqE=.54dca99d-e0c0-4ae5-bc60-6519ba695d37@github.com>
Message-ID: <YKqmmlqFC2cU_5ngtDNOaB4zS7zxdAJTZOe6xjInCAE=.38d7f892-b1e5-4ee7-85dc-d5fa7a41d627@github.com>

On Thu, 24 Jun 2021 17:02:03 GMT, Scott Gibbons <sgibbons at openjdk.org> wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size...
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed Windows register stomping.

We found this optimization causes https://bugs.openjdk.org/browse/JDK-8321599

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

PR Comment: https://git.openjdk.org/jdk/pull/4368#issuecomment-1847357495

From ihse at openjdk.org  Fri Dec  8 15:49:27 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 15:49:27 GMT
Subject: Integrated: 8321597: Use .template consistently for files treated as
 templates by the build
In-Reply-To: <EZOOqtqdYFsXiz11Mv7sBtBfYA0ifk1T78cs4CZ1zLs=.290c82ea-c021-4ef8-bc26-4ae525724ffe@github.com>
References: <EZOOqtqdYFsXiz11Mv7sBtBfYA0ifk1T78cs4CZ1zLs=.290c82ea-c021-4ef8-bc26-4ae525724ffe@github.com>
Message-ID: <6U2t-AXMe6vvv60sQPRmDvKVQFlExldQFAXG2P7B7kg=.83f1669b-c09c-4b50-8720-94b26ff0e4d8@github.com>

On Fri, 8 Dec 2023 14:43:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files are used as "templates" in the build, that is, they are almost, but not fully, in the intended state. Instead, they have some pattern markers that need to be replaced with actual content as part of the build.
> 
> As a convention, most such files are named as `<resulting name>.template`, e.g. `VersionProps.java.template`, to indicate that this is almost, but not fully, a Java file.
> 
> A few files were created before this convention was fully embraced. These should be renamed to match the pattern.

This pull request has now been integrated.

Changeset: b893a2b2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b893a2b2f70346f9d204d1050a0ad32fd98fdd56
Stats:     11 lines in 16 files changed: 0 ins; 0 del; 11 mod

8321597: Use .template consistently for files treated as templates by the build

Reviewed-by: erikj

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

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

From ihse at openjdk.org  Fri Dec  8 15:59:13 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 15:59:13 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <oiwQZmOwoIaf9X-5Zb4N4knBEBgUFeFA3biuqgPXun0=.d01ce856-ca42-42ce-9c4a-1a33958d7ad4@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

This is interesting, but we must be careful to not rush things here. We're basically creating a chimera, mixing assumptions about "windows", "microsoft toolchain" and "clang".

Do I understand you correctly that clang-cl uses "mostly" the same arguments as cl, but uses the clang warnings system, e.g. -Wno-foo-loops instead of C1234?

That means we need to separate the warning option handling from all the other options. You say something about not disabling warnings adds a minute to the build time. I assume that means that even with your linked patches, the build will spew out warnings.

This is not something we can fix "afterwards"; we need to design the integration of clang-cl in a way that we can (hopefully) reuse existing clang warning disables.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1847437678

From ihse at openjdk.org  Fri Dec  8 16:03:14 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 16:03:14 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <3zwUsPqCReEB0tNH28tFxGBbCiG1pbgyuizAV6mj8FA=.83cc850d-7d6d-4077-9e2d-f2d8db330b1b@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

And, oh, I must say that I think "clcl" as name for the toolchain is really bad. :-(

I think `microsoft-clang` would be the best and clearest name. Possibly, we should rename `microsoft` to `microsoft-cl`, and use `microsoft` as an user-facing alias. At least if the rest of the toolchain is 100% the same as in the current `microsoft` toolchain.

Doing that will present both a risk and an opportunity: if we are checking the toolchain using "findstring" for "microsoft", but we really only want to match `microsoft-cl`, then it will break, so any such instances must be discovered and checked. On the other hand, if we do want to treat `microsoft-cl` and `microsoft-clang` the same, then a "findstring" instead of a "filter" will actually do the trick.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1847444124

From ihse at openjdk.org  Fri Dec  8 16:08:13 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 16:08:13 GMT
Subject: RFR: 8321557: Move SOURCE line verification for OracleJDK out of
 OpenJDK
In-Reply-To: <UyyQ3xvNFLcrqmEvxX38ST7mrl4LQR-DjgZXZGf3ASE=.aa8f51e5-6c62-4f49-868b-a297883ff0c8@github.com>
References: <UyyQ3xvNFLcrqmEvxX38ST7mrl4LQR-DjgZXZGf3ASE=.aa8f51e5-6c62-4f49-868b-a297883ff0c8@github.com>
Message-ID: <CcHdzXKbkqkSifHzmp_2NguAsyg1eGsUUwKNHDckkTY=.28634c67-5271-43ee-ac3b-429f00fa4185@github.com>

On Thu, 7 Dec 2023 23:29:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The main goal of this patch is to remove the OracleJDK specific verification of the SOURCE field in the release file from the OpenJDK test. While at it, I decided to do some cleanup as well to make the code a bit more modern and less unnecessarily verbose.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17027#pullrequestreview-1772729313

From ihse at openjdk.org  Fri Dec  8 16:15:15 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 16:15:15 GMT
Subject: RFR: 8316657: Support whitebox testing in microbenchmarks
In-Reply-To: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
References: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
Message-ID: <HaiwCawyTW40WjZetAykXWU4ybSNTs6VLepZlRmAZZc=.4e7dd873-2f73-422e-9733-21be262da537@github.com>

On Wed, 6 Dec 2023 15:32:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.

make/RunTests.gmk line 598:

> 596:   endif
> 597: 
> 598:   # Set paths for dependencies

@cl4es So basically this is the line you're objecting to? 

I can remove the change in RunTests.gmk for this patch. That way the wb.jar will be available, but additional work is needed for the micros to access it. But that might, as you say, perhaps be solved within the micros themselves, by annotations or whatever.

Does that sound reasonable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16996#discussion_r1420726640

From ihse at openjdk.org  Fri Dec  8 16:19:15 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 16:19:15 GMT
Subject: RFR: 8316657: Support whitebox testing in microbenchmarks
In-Reply-To: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
References: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
Message-ID: <hqXvndHyc9LIpCu3Ozu5F0NdXJP3DxcQghl-qQn-kRM=.6b5cb11e-dc2c-4fd0-9f25-46b977ce05f7@github.com>

On Wed, 6 Dec 2023 15:32:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.

Alternatively, I could also unpack wb.jar alongside `$(JMH_CORE_JAR) $(JMH_COMMONS_MATH_JAR) $(JMH_JOPT_SIMPLE_JAR)`, and re-pack it into `benchmarks.jar`. My gut feeling was that it "polluted" benchmarks.jar unnecessarily, but then again it also creates an additional jar dependency. If the "I just want a single jar with everything" is an important driver here, then that is perhaps the way to go?

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

PR Comment: https://git.openjdk.org/jdk/pull/16996#issuecomment-1847467298

From magnus.ihse.bursie at oracle.com  Fri Dec  8 16:29:21 2023
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 17:29:21 +0100
Subject: Cross compilation discussion
In-Reply-To: <789dcb6f-e326-4be6-ba49-0e50e9251e98@littlepinkcloud.com>
References: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
 <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>
 <fba01ff6-2fed-40fd-86b4-180473c5d54e@oracle.com>
 <789dcb6f-e326-4be6-ba49-0e50e9251e98@littlepinkcloud.com>
Message-ID: <5daf61ab-13c4-4c6c-9e03-ddef27c744de@oracle.com>


> OK. So you are doing what I'd usually call cross compiling, sort of, but
> you don't want to treat it as a cross-compiled build. It's an unusual
> case, in that it is cross compiled, but it is also expected to be able to
> run on the build system.

The main reason for the build to know if we're doing a cross-compilation 
or not has been if we need a special compiler to create build tools. For 
me, that is in essence what the cross-compilation flag is saying.

Separately, we have the concept of sysroot, but I agree that setting the 
sysroot is essentially a form of cross-compilation. The question is: do 
the build system need to know about this, any more than just make sure 
we pass along the sysroot properly?

Maybe this is just a question on how to present the needs of the build 
system to the user, where "cross-compilation" might have different 
connotations than are used inside the build system.

So maybe we should have like "cross-compiling-need-build-compiler" and 
"cross-complining-can-use-target-compiler"?

/Magnus


From djelinski at openjdk.org  Fri Dec  8 17:11:18 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Dec 2023 17:11:18 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <oiwQZmOwoIaf9X-5Zb4N4knBEBgUFeFA3biuqgPXun0=.d01ce856-ca42-42ce-9c4a-1a33958d7ad4@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
 <oiwQZmOwoIaf9X-5Zb4N4knBEBgUFeFA3biuqgPXun0=.d01ce856-ca42-42ce-9c4a-1a33958d7ad4@github.com>
Message-ID: <UxcbHPAHZirJnC7zLWfsS3z11h6SMNOSdSwR7i3LJsY=.ea96f9d4-c793-4f7a-bd75-a6746b3dae3d@github.com>

On Fri, 8 Dec 2023 15:56:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Do I understand you correctly that clang-cl uses "mostly" the same arguments as cl, but uses the clang warnings system, e.g. -Wno-foo-loops instead of C1234?

That's correct.
Clang-cl only supports the following cl warning parameters:

  /W0                     Disable all warnings
  /W1                     Enable -Wall
  /W2                     Enable -Wall
  /W3                     Enable -Wall
  /W4                     Enable -Wall and -Wextra
  /Wall                   Enable -Weverything

note how `Wall` differs in meaning between clang and clang-cl. [Source](https://clang.llvm.org/docs/UsersManual.html#id10)

> I assume that means that even with your linked patches, the build will spew out warnings.

Right, with this patch the build produces warnings. No per-file or per-module suppressions are applied.

> we need to design the integration of clang-cl in a way that we can (hopefully) reuse existing clang warning disables.

I'd love that. Got any preferences on how that should be handled?

> And, oh, I must say that I think "clcl" as name for the toolchain is really bad. :-(

It was not my first choice. I tried `clang-cl` first; the scripts didn't like the dash. Then I tried `clangcl`, and some of the changes found their way into the MacOS build. `findstring` is tricky to get right.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1847539074

From erik.joelsson at oracle.com  Fri Dec  8 20:36:21 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 8 Dec 2023 12:36:21 -0800
Subject: Cross compilation discussion
In-Reply-To: <5daf61ab-13c4-4c6c-9e03-ddef27c744de@oracle.com>
References: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
 <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>
 <fba01ff6-2fed-40fd-86b4-180473c5d54e@oracle.com>
 <789dcb6f-e326-4be6-ba49-0e50e9251e98@littlepinkcloud.com>
 <5daf61ab-13c4-4c6c-9e03-ddef27c744de@oracle.com>
Message-ID: <6f40d377-1f06-42ce-a417-27c99bdbf76c@oracle.com>


On 12/8/23 08:29, Magnus Ihse Bursie wrote:
>
>> OK. So you are doing what I'd usually call cross compiling, sort of, but
>> you don't want to treat it as a cross-compiled build. It's an unusual
>> case, in that it is cross compiled, but it is also expected to be 
>> able to
>> run on the build system.
>
> The main reason for the build to know if we're doing a 
> cross-compilation or not has been if we need a special compiler to 
> create build tools. For me, that is in essence what the 
> cross-compilation flag is saying.
I think the issue now is that automatically figuring out if a separate 
compiler is needed or not can be hard. We do it in some cases, but not 
in others, and sometimes we get it wrong (as in the linux-aarch64 issue 
Mikael recently fixed, where the given tuple didn't exactly match what 
config.guess found on the build machine). I think it would be reasonable 
to have a configure parameter to control this explicitly.
>
> Separately, we have the concept of sysroot, but I agree that setting 
> the sysroot is essentially a form of cross-compilation. The question 
> is: do the build system need to know about this, any more than just 
> make sure we pass along the sysroot properly?
>
I agree that the purpose of the sysroot is to help configure find 
headers and libraries, and setup correct flags for compiler and linker 
tools.
> Maybe this is just a question on how to present the needs of the build 
> system to the user, where "cross-compilation" might have different 
> connotations than are used inside the build system.
>
> So maybe we should have like "cross-compiling-need-build-compiler" and 
> "cross-complining-can-use-target-compiler"?
>
Not sure of the naming here, but in essence, that's where we are making 
implicit assumptions today that are hard to control.

If you specify --with-openjdk-target and the tuple is different than the 
build tuple, then we can assume the default is to need a build compiler, 
but there are cases where that is still not strictly needed. If 
--with-build-devkit is supplied, then that is also a good indication as 
we are given an explicit build compiler. Just supplying a sysroot/devkit 
should probably not be assumed as needing a build compiler, but paired 
with a suitable option, this could support the cross compile to EL8 from 
EL7. I could for instance imagine setting --with-build-sysroot=/ to help 
nudge configure into defining a separate build compiler, but maybe 
that's too clunky?

/Erik

From kvn at openjdk.org  Fri Dec  8 22:40:21 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 8 Dec 2023 22:40:21 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
Message-ID: <ztyQOqmAdklsQ8TjD3OA7MSWKd3ZzF-cvJnXuhCv2M0=.0eee671d-24e1-444d-bd01-1544962500f6@github.com>

On Wed, 6 Dec 2023 23:12:13 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
>> 
>> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
>> 
>> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
>> 
>> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> 
>> 
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
>> -- | -- | -- | -- | --
>> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
>> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
>> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
>> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
>> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
>> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
>> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
>> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
>> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
>> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
>> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
>> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
>> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
>> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
>> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
>> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
>> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
>> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
>> 
>> </body>
>> 
>> </html>
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId cont...
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Change supported intrinsic check"
>   
>   This reverts commit 9621eb045c2958582f81ec06b237789a07481ddd.

I pushed closed changes.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16534#pullrequestreview-1773255608

From shurailine at openjdk.org  Fri Dec  8 22:48:25 2023
From: shurailine at openjdk.org (Alexandre Iline)
Date: Fri, 8 Dec 2023 22:48:25 GMT
Subject: RFR: JDK-8321621: Update JCov version to 3.0.16
Message-ID: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>

JCov support for byte code version 67.

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

Commit messages:
 - JDK-8321621: Update JCov version to 3.0.16

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

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

From duke at openjdk.org  Fri Dec  8 22:51:21 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 8 Dec 2023 22:51:21 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <ztyQOqmAdklsQ8TjD3OA7MSWKd3ZzF-cvJnXuhCv2M0=.0eee671d-24e1-444d-bd01-1544962500f6@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <_L--_bl81TgfP1_0bLld6-xzcNqsopfL3HX3bmlbqgE=.923709b1-2e65-4659-a9cd-db4a6ac375c0@github.com>
 <ztyQOqmAdklsQ8TjD3OA7MSWKd3ZzF-cvJnXuhCv2M0=.0eee671d-24e1-444d-bd01-1544962500f6@github.com>
Message-ID: <e_rkNep7m7NvH5BOGu-d66ZlJrLhMe5_rOA1pDS-cW8=.bed5ea58-ab94-4048-a4e4-7ebbbcbe1dae@github.com>

On Fri, 8 Dec 2023 22:37:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I pushed closed changes.

Thanks Vladimir!

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

PR Comment: https://git.openjdk.org/jdk/pull/16534#issuecomment-1847939767

From erikj at openjdk.org  Fri Dec  8 22:52:18 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Dec 2023 22:52:18 GMT
Subject: RFR: JDK-8321621: Update JCov version to 3.0.16
In-Reply-To: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>
References: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>
Message-ID: <B5bOXNsjCV-ZsmufAXw5Qu38MhhuKzemZscmKFa3duo=.1bd433f6-3cd2-4da5-8e60-fac7df5c639a@github.com>

On Fri, 8 Dec 2023 22:42:42 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> JCov support for byte code version 67.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17041#pullrequestreview-1773267176

From duke at openjdk.org  Fri Dec  8 22:55:37 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 8 Dec 2023 22:55:37 GMT
Subject: Integrated: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods
 (int, float arrays)
In-Reply-To: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
Message-ID: <EHNbplJ2r5tEm1rxhEkQc96CxUFfZdXGymefYbon_J0=.5594b84c-c768-42f1-aece-78121d9171b8@github.com>

On Tue, 7 Nov 2023 00:12:41 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> 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.
> 
> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below.
> 
> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below.
> 
> **Note:** This PR also improves the performance of AVX512 sort by upto 35%.
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> 
> 
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark (Serial Sort) | Size | Baseline      (us/op) | AVX2     (us/op) | Speedup
> -- | -- | -- | -- | --
> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2
> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0
> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5
> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5
> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2
> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4
> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6
> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3
> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1
> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0
> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4
> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3
> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0
> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9
> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4
> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7
> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0
> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6
> 
> </body>
> 
> </html>
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/...

This pull request has now been integrated.

Changeset: ce108446
Author:    vamsi-parasa <srinivas.vamsi.parasa at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce108446ca1fe604ecc24bbefb0bf1c6318271c7
Stats:     4026 lines in 24 files changed: 2311 ins; 1560 del; 155 mod

8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays)

Reviewed-by: sviswanathan, ihse, jbhateja, kvn

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

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

From ihse at openjdk.org  Fri Dec  8 23:20:12 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Dec 2023 23:20:12 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <UxcbHPAHZirJnC7zLWfsS3z11h6SMNOSdSwR7i3LJsY=.ea96f9d4-c793-4f7a-bd75-a6746b3dae3d@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
 <oiwQZmOwoIaf9X-5Zb4N4knBEBgUFeFA3biuqgPXun0=.d01ce856-ca42-42ce-9c4a-1a33958d7ad4@github.com>
 <UxcbHPAHZirJnC7zLWfsS3z11h6SMNOSdSwR7i3LJsY=.ea96f9d4-c793-4f7a-bd75-a6746b3dae3d@github.com>
Message-ID: <ceTnGyTCKTRSLaKG_RIcJCNTtAIBCZ5owpAt8Poc1S4=.bf484d6f-738f-4bba-89a6-0e4a8263333b@github.com>

On Fri, 8 Dec 2023 17:08:33 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> >    And, oh, I must say that I think "clcl" as name for the toolchain is really bad. :-(
>
> It was not my first choice. I tried clang-cl first; the scripts didn't like the dash. Then I tried clangcl, and some of the changes found their way into the MacOS build. findstring is tricky to get right.

Then we need to fix those places. As Erik has commented, `findstring` is usually the wrong function to use when what you really mean is `filter`.

> >    we need to design the integration of clang-cl in a way that we can (hopefully) reuse existing clang warning disables.
> 
> I'd love that. Got any preferences on how that should be handled?

Not straight out of my hat, no. I wonder what would happen as a first step if we started looking at the DISABLE_WARNINGS_clang fields, by just using a hack. I'm guessing this will take some experimenting.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1847960400
PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1847962061

From alanb at openjdk.org  Sat Dec  9 08:04:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Dec 2023 08:04:12 GMT
Subject: RFR: JDK-8321621: Update JCov version to 3.0.16
In-Reply-To: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>
References: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>
Message-ID: <eHNFOBqQjs0FmsEB-ZDQTypCNMx55pnjckqJEdfuKO8=.2ec5c291-b26f-499c-a0a6-79ddfea436d8@github.com>

On Fri, 8 Dec 2023 22:42:42 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> JCov support for byte code version 67.

Happy to see this being changed soon after the fork.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17041#pullrequestreview-1773616082

From gli at openjdk.org  Mon Dec 11 03:19:24 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 11 Dec 2023 03:19:24 GMT
Subject: RFR: 8321688: Build on linux with GCC 7.5.0 fails after 8319577
Message-ID: <vIByQ06ftSU9o1Rb4YOWXPrry1LkYSj-vJqLXaMXQ5g=.d5a0ea33-f57a-4549-addf-b7a9c5eaa67d@github.com>

Hi all,

This patch fixes the building failure introduced by [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version (linux & GCC 7.5.0 locally).

Thanks for the review.

 Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8321688

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

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

From kbarrett at openjdk.org  Mon Dec 11 03:45:15 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 11 Dec 2023 03:45:15 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <V1Ad7zHaS6k3IKkj-wCPZu5bpczAPgqal242vBl3nw8=.a9124f5c-738e-40cf-8229-59ca7ea99598@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

This is effectively creating a new port.  That shouldn't be done lightly. 

Who needs this?  (Real question, not rhetorical.)  We've discussed things like
this in the past (build for Windows using something other than MSVC), and it
wasn't clear there was a user community sufficient to warrant the effort to
develop and (especially) maintain such a port.

Who is going to maintain this?

Most "secondary" ports have an associated JDK project that is responsible for
them.  This provides a place for other developers to find the maintainers.

Because there was only the one configuration, there have been places that
conflate Windows (the OS) and MSVC (the compiler), both in the build system
and in the source code.  And for source code that means both HotSpot and
native code elsewhere in the JDK.  Julian has been cleaning up some of that,
but I've no idea how much might be left.  And things will quickly bit rot if
there aren't active maintainers.

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

PR Review: https://git.openjdk.org/jdk/pull/17019#pullrequestreview-1774237983

From djelinski at openjdk.org  Mon Dec 11 08:48:13 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 11 Dec 2023 08:48:13 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <V1Ad7zHaS6k3IKkj-wCPZu5bpczAPgqal242vBl3nw8=.a9124f5c-738e-40cf-8229-59ca7ea99598@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
 <V1Ad7zHaS6k3IKkj-wCPZu5bpczAPgqal242vBl3nw8=.a9124f5c-738e-40cf-8229-59ca7ea99598@github.com>
Message-ID: <4oA8th3ee_dRC0UfUrvzbO1sWamIw_WGZGZDyoZsEZU=.494c878a-f30b-4dbc-86a5-ba7964780958@github.com>

On Mon, 11 Dec 2023 03:42:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
>> 
>> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
>> 
>> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
>> 
>> In order to use the clang compiler:
>> - install Visual Studio 2022
>> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
>> - configure `--with-toolchain-type=clcl`
>> - compile as usual.
>> 
>> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.
>
> This is effectively creating a new port.  That shouldn't be done lightly. 
> 
> Who needs this?  (Real question, not rhetorical.)  We've discussed things like
> this in the past (build for Windows using something other than MSVC), and it
> wasn't clear there was a user community sufficient to warrant the effort to
> develop and (especially) maintain such a port.
> 
> Who is going to maintain this?
> 
> Most "secondary" ports have an associated JDK project that is responsible for
> them.  This provides a place for other developers to find the maintainers.
> 
> Because there was only the one configuration, there have been places that
> conflate Windows (the OS) and MSVC (the compiler), both in the build system
> and in the source code.  And for source code that means both HotSpot and
> native code elsewhere in the JDK.  Julian has been cleaning up some of that,
> but I've no idea how much might be left.  And things will quickly bit rot if
> there aren't active maintainers.

Thanks @kimbarrett for your input.

I'm not aware of anyone who needs this. I am using clang only for the warnings it reports. It found a number of previously undetected problems.

If new compilers are added on a strictly as-needed basis, this one has no place in the JDK; the Structured Exception Handling implementation in clang is sub-standard, and a hack is required to make it work. The resulting artifacts pass the tests I'm interested in, but I have no intention of running the entire test suite.

I'm only providing this patch to make it easier for others to experiment with clang-cl. If that's not a good enough reason to get this patch merged, I can keep maintaining it in my fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1849568982

From aph-open at littlepinkcloud.com  Mon Dec 11 09:24:34 2023
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 11 Dec 2023 09:24:34 +0000
Subject: Cross compilation discussion
In-Reply-To: <6f40d377-1f06-42ce-a417-27c99bdbf76c@oracle.com>
References: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
 <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>
 <fba01ff6-2fed-40fd-86b4-180473c5d54e@oracle.com>
 <789dcb6f-e326-4be6-ba49-0e50e9251e98@littlepinkcloud.com>
 <5daf61ab-13c4-4c6c-9e03-ddef27c744de@oracle.com>
 <6f40d377-1f06-42ce-a417-27c99bdbf76c@oracle.com>
Message-ID: <eec699cf-73da-4b4b-94aa-762287c19fb1@littlepinkcloud.com>

On 12/8/23 20:36, erik.joelsson at oracle.com wrote:
> 
> On 12/8/23 08:29, Magnus Ihse Bursie wrote:
>>
>>> OK. So you are doing what I'd usually call cross compiling, sort of, but
>>> you don't want to treat it as a cross-compiled build. It's an unusual
>>> case, in that it is cross compiled, but it is also expected to be
>>> able to
>>> run on the build system.
>>
>> The main reason for the build to know if we're doing a
>> cross-compilation or not has been if we need a special compiler to
>> create build tools. For me, that is in essence what the
>> cross-compilation flag is saying.
 >
> I think the issue now is that automatically figuring out if a separate
> compiler is needed or not can be hard. We do it in some cases, but not
> in others, and sometimes we get it wrong (as in the linux-aarch64 issue
> Mikael recently fixed, where the given tuple didn't exactly match what
> config.guess found on the build machine). I think it would be reasonable
> to have a configure parameter to control this explicitly.

I think so, or to be able to override what the build system deduces from
other build parameters.

>> So maybe we should have like "cross-compiling-need-build-compiler" and
>> "cross-complining-can-use-target-compiler"?
>>
> Not sure of the naming here, but in essence, that's where we are making
> implicit assumptions today that are hard to control.
> 
> If you specify --with-openjdk-target and the tuple is different than the
> build tuple, then we can assume the default is to need a build compiler,
> but there are cases where that is still not strictly needed. If
> --with-build-devkit is supplied, then that is also a good indication as
> we are given an explicit build compiler. Just supplying a sysroot/devkit
> should probably not be assumed as needing a build compiler, but paired
> with a suitable option, this could support the cross compile to EL8 from
> EL7. I could for instance imagine setting --with-build-sysroot=/ to help
> nudge configure into defining a separate build compiler, but maybe
> that's too clunky?

Maybe, or at least fails the principle of least surprise. I think I may
be missing something important here: what is the downside of treating a
build as a cross compilation? Is it simply that more work has to be done,
or something else?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From redestad at openjdk.org  Mon Dec 11 11:32:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Dec 2023 11:32:13 GMT
Subject: RFR: 8316657: Support whitebox testing in microbenchmarks
In-Reply-To: <HaiwCawyTW40WjZetAykXWU4ybSNTs6VLepZlRmAZZc=.4e7dd873-2f73-422e-9733-21be262da537@github.com>
References: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
 <HaiwCawyTW40WjZetAykXWU4ybSNTs6VLepZlRmAZZc=.4e7dd873-2f73-422e-9733-21be262da537@github.com>
Message-ID: <HJyfNLBpTxZrhyUjbrfpifMk2CKHDKv3VJN5Z5DqvBo=.9c3e2e41-eee6-4fa9-b45f-b75b175a73f0@github.com>

On Fri, 8 Dec 2023 16:12:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.
>
> make/RunTests.gmk line 598:
> 
>> 596:   endif
>> 597: 
>> 598:   # Set paths for dependencies
> 
> @cl4es So basically this is the line you're objecting to? 
> 
> I can remove the change in RunTests.gmk for this patch. That way the wb.jar will be available, but additional work is needed for the micros to access it. But that might, as you say, perhaps be solved within the micros themselves, by annotations or whatever.
> 
> Does that sound reasonable?

More reasonable, yes. If we need to pack the wb.jar into the benchmarks.jar or can reference it from the test image dir remains to be seen, but it would be the responsibility of those micros that need it to set that up. While a fully self-contained solution might be preferred for simplicity, we can assume that our test harnesses have access to the test image and can pull in the associated wb.jar from there if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16996#discussion_r1422334583

From jwaters at openjdk.org  Mon Dec 11 12:54:14 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 11 Dec 2023 12:54:14 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <ceTnGyTCKTRSLaKG_RIcJCNTtAIBCZ5owpAt8Poc1S4=.bf484d6f-738f-4bba-89a6-0e4a8263333b@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
 <oiwQZmOwoIaf9X-5Zb4N4knBEBgUFeFA3biuqgPXun0=.d01ce856-ca42-42ce-9c4a-1a33958d7ad4@github.com>
 <UxcbHPAHZirJnC7zLWfsS3z11h6SMNOSdSwR7i3LJsY=.ea96f9d4-c793-4f7a-bd75-a6746b3dae3d@github.com>
 <ceTnGyTCKTRSLaKG_RIcJCNTtAIBCZ5owpAt8Poc1S4=.bf484d6f-738f-4bba-89a6-0e4a8263333b@github.com>
Message-ID: <9W-7q8kBfAHQeZ-fo4mk9n36cr5FZOug6XOHLEMHuGw=.4087570b-dba6-4477-880c-ba27e8ed3219@github.com>

On Fri, 8 Dec 2023 23:17:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > > we need to design the integration of clang-cl in a way that we can (hopefully) reuse existing clang warning disables.
> > 
> > 
> > I'd love that. Got any preferences on how that should be handled?
> 
> Not straight out of my hat, no. I wonder what would happen as a first step if we started looking at the DISABLE_WARNINGS_clang fields, by just using a hack. I'm guessing this will take some experimenting.

How about having clang-cl be one of the clang names recognized for Windows in addition to regular clang, much like how AIX has ibm-clang_r as its TOOLCHAIN_CC_BINARY_clang rather than the default of just clang? I don't know how clang-cl's options differ from the regular clang however, so I don't know how feasible this approach would be



> Julian has been cleaning up some of that,
> but I've no idea how much might be left.

Quite a bit, I'm afraid

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1850018336

From ihse at openjdk.org  Mon Dec 11 13:47:26 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Dec 2023 13:47:26 GMT
Subject: RFR: 8316657: Support whitebox testing in microbenchmarks [v2]
In-Reply-To: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
References: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
Message-ID: <CAf73rQCaZeqVYukz9RoNAE31T2h1Y4VUSrwbfPzb5c=.9cec0cfd-80e0-4c7c-be1d-434374c9a155@github.com>

> The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert change in RunTests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16996/files
  - new: https://git.openjdk.org/jdk/pull/16996/files/320a911d..9e394618

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

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

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

From erik.joelsson at oracle.com  Mon Dec 11 13:56:39 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Mon, 11 Dec 2023 05:56:39 -0800
Subject: Cross compilation discussion
In-Reply-To: <eec699cf-73da-4b4b-94aa-762287c19fb1@littlepinkcloud.com>
References: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
 <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>
 <fba01ff6-2fed-40fd-86b4-180473c5d54e@oracle.com>
 <789dcb6f-e326-4be6-ba49-0e50e9251e98@littlepinkcloud.com>
 <5daf61ab-13c4-4c6c-9e03-ddef27c744de@oracle.com>
 <6f40d377-1f06-42ce-a417-27c99bdbf76c@oracle.com>
 <eec699cf-73da-4b4b-94aa-762287c19fb1@littlepinkcloud.com>
Message-ID: <3d405183-d7c5-4f0b-b5b6-95d90126cd94@oracle.com>

On 12/11/23 01:24, Andrew Haley wrote:
> Maybe, or at least fails the principle of least surprise. I think I may
> be missing something important here: what is the downside of treating a
> build as a cross compilation? Is it simply that more work has to be done,
> or something else?
>
Yes, the drawback is that significantly more work has to be done. If we 
cannot use the target JDK as "build JDK" to run tools like jmod and 
jlink, we need to either supply a build JDK or produce one during the 
build. This means building minimally viable JDK for the build platform, 
including libjvm and some other native libs and launchers.

/Erik


From redestad at openjdk.org  Mon Dec 11 14:16:15 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Dec 2023 14:16:15 GMT
Subject: RFR: 8316657: Support whitebox testing in microbenchmarks [v2]
In-Reply-To: <CAf73rQCaZeqVYukz9RoNAE31T2h1Y4VUSrwbfPzb5c=.9cec0cfd-80e0-4c7c-be1d-434374c9a155@github.com>
References: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
 <CAf73rQCaZeqVYukz9RoNAE31T2h1Y4VUSrwbfPzb5c=.9cec0cfd-80e0-4c7c-be1d-434374c9a155@github.com>
Message-ID: <qYJWtHXTSYLpD_lpdKpSyRjV3CGB-xYLYW4PbJ9LkC4=.cfb74519-82a6-420c-a136-bcb5eb6ed9f9@github.com>

On Mon, 11 Dec 2023 13:47:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change in RunTests

This is ok. Enables WB as a compile-time dependency, but leaves it to the author of WB-dependent tests to either add it as a runtime dependency explicitly or work on a solution to have JMH run forks with the WB dependency added.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16996#pullrequestreview-1775234453

From ihse at openjdk.org  Mon Dec 11 14:20:30 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Dec 2023 14:20:30 GMT
Subject: Integrated: 8316657: Support whitebox testing in microbenchmarks
In-Reply-To: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
References: <WNgb3dhGLAjdql6L5VdXXUbJJqPqqLq4lrVfD3Pcrmk=.c2365d31-284d-4628-a6fe-a588a4595e0c@github.com>
Message-ID: <Vz9u-XTre7u6bM1Mqq-Z2bmb56mS-E3Hf7Y78Hw_QKg=.dd3cbcac-1843-4e66-8693-ec47ded0885f@github.com>

On Wed, 6 Dec 2023 15:32:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The need to use whitebox-testing (wb.jar) from JMH microbenchmarks has recently arisen.

This pull request has now been integrated.

Changeset: 486594d4
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/486594d4273e9d5a8db43de861e3ca3ce823f0da
Stats:     58 lines in 3 files changed: 40 ins; 7 del; 11 mod

8316657: Support whitebox testing in microbenchmarks

Reviewed-by: erikj, redestad

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

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

From ihse at openjdk.org  Mon Dec 11 14:23:19 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Dec 2023 14:23:19 GMT
Subject: RFR: JDK-8321621: Update JCov version to 3.0.16
In-Reply-To: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>
References: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>
Message-ID: <CpJZIkFjqcPniUzbhzOZmW79UJfF3RkLYUHOma8c37o=.20dcce68-e15b-4fd3-a1c6-4767e91476e0@github.com>

On Fri, 8 Dec 2023 22:42:42 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> JCov support for byte code version 67.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17041#pullrequestreview-1775249715

From ihse at openjdk.org  Mon Dec 11 14:36:15 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Dec 2023 14:36:15 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <4rbfOThp0nGiqE1xu428T-tOeniWGWjQKTBW7DzD8qs=.39b2a6ab-cd99-494d-a05a-0877e0a360ec@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

I tend to agree with both Camp Kim and Camp David/Julian here. In many ways, the code gets healthier the more variation we have, i terms of support for operating systems, architectures, compilers and C libraries. Both the actual code base gets more exposure which can force out bugs that were lurking in the dark, and the build system gets a requirement for clear separations and structure. So in general, I like to see more compilers and platforms in the JDK!

But, then there is Kim's argument about maintenance cost. And it is not to be taken lightly. If the port can be "sneaked in" without much effort or impact on other code, then it essentially free, and even if it is not strictly needed, or we do not have an active maintainer, I see no problem with using it. Great examples of this would be the zero ports on odd CPUs, like MIPS.  The more the port interferes with existing code, the higher this barrier becomes.

But there is also a second cost associated with new ports (I'm counting the new compiler as a port, in this context), and that is the arbitrary differences that do not bring forth any solved bugs, or good abstractions. All these "#ifdef on_this_platform do_it_that_way". If you need many such changes, this also raises the barrier for inclusion.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1850201488

From ihse at openjdk.org  Mon Dec 11 14:40:15 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Dec 2023 14:40:15 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <ljs1I6oIizDnP7eaVuGd8-nlauqL0O7CNPTUcuNyhsY=.c5b4549a-01ae-4fdf-9f86-d2ddb0528ba4@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

So, in this case, I believe that if it is possible to reuse warnings from "normal" clang, and the rest of the build process from the existing microsoft-cl toolchain, then the impact might be very small in the code. But it will require some surgery in the toolchain logic, to separate the actual compiler from the rest of the toolchain. 

It can certainly be done, but might take a few iterations back and forth to get it right. But maybe that's the sort of thing that @TheShermanTanker enjoys?

So my verdict is that we can't really accept this PR as it is, but using microsoft-clang is definitely an interesting experiment, and we should lay the groundwork for being able to implement it in a proper fashion. And if it then actually can be implemented with minimal impact to existing code, then we should do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1850208130

From magnus.ihse.bursie at oracle.com  Mon Dec 11 15:21:55 2023
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 11 Dec 2023 16:21:55 +0100
Subject: Cross compilation discussion
In-Reply-To: <eec699cf-73da-4b4b-94aa-762287c19fb1@littlepinkcloud.com>
References: <fb22b79c-adfd-4ed0-ab5f-3fb35766ab6f@oracle.com>
 <cca6d113-5d97-44f4-808c-747560d93ec8@littlepinkcloud.com>
 <fba01ff6-2fed-40fd-86b4-180473c5d54e@oracle.com>
 <789dcb6f-e326-4be6-ba49-0e50e9251e98@littlepinkcloud.com>
 <5daf61ab-13c4-4c6c-9e03-ddef27c744de@oracle.com>
 <6f40d377-1f06-42ce-a417-27c99bdbf76c@oracle.com>
 <eec699cf-73da-4b4b-94aa-762287c19fb1@littlepinkcloud.com>
Message-ID: <04128de0-c2b7-44ac-9015-de5179029291@oracle.com>


On 2023-12-11 10:24, Andrew Haley wrote:
> On 12/8/23 20:36, erik.joelsson at oracle.com wrote:
>>
>> On 12/8/23 08:29, Magnus Ihse Bursie wrote:
>>>
>>>> OK. So you are doing what I'd usually call cross compiling, sort 
>>>> of, but
>>>> you don't want to treat it as a cross-compiled build. It's an unusual
>>>> case, in that it is cross compiled, but it is also expected to be
>>>> able to
>>>> run on the build system.
>>>
>>> The main reason for the build to know if we're doing a
>>> cross-compilation or not has been if we need a special compiler to
>>> create build tools. For me, that is in essence what the
>>> cross-compilation flag is saying.
> >
>> I think the issue now is that automatically figuring out if a separate
>> compiler is needed or not can be hard. We do it in some cases, but not
>> in others, and sometimes we get it wrong (as in the linux-aarch64 issue
>> Mikael recently fixed, where the given tuple didn't exactly match what
>> config.guess found on the build machine). I think it would be reasonable
>> to have a configure parameter to control this explicitly.
>
> I think so, or to be able to override what the build system deduces from
> other build parameters.

Like everything else in configure, we should try to make automatic 
deduction of sane default values, but allow the user to override 
completely if necessary.

>
>>> So maybe we should have like "cross-compiling-need-build-compiler" and
>>> "cross-complining-can-use-target-compiler"?
>>>
>> Not sure of the naming here, but in essence, that's where we are making
>> implicit assumptions today that are hard to control.
>>
>> If you specify --with-openjdk-target and the tuple is different than the
>> build tuple, then we can assume the default is to need a build compiler,
>> but there are cases where that is still not strictly needed. If
>> --with-build-devkit is supplied, then that is also a good indication as
>> we are given an explicit build compiler. Just supplying a sysroot/devkit
>> should probably not be assumed as needing a build compiler, but paired
>> with a suitable option, this could support the cross compile to EL8 from
>> EL7. I could for instance imagine setting --with-build-sysroot=/ to help
>> nudge configure into defining a separate build compiler, but maybe
>> that's too clunky?
>
> Maybe, or at least fails the principle of least surprise. I think I may
> be missing something important here: what is the downside of treating a
> build as a cross compilation? Is it simply that more work has to be done,
> or something else?


The real downside is if we decide that we need a build jdk, then we need 
to build the JDK twice. Apart from that, I think it is mostly that it 
complicates the configuration.

I'm trying to imagine what would happen if we say we are doing a 
cross-compile but set the sysroot to /, and set the build toolchain and 
the target toolchain to the same native tools. I don't think there would 
be any other negative effects.

But maybe I'm forgetting something...

/Magnus


From luhenry at openjdk.org  Mon Dec 11 18:28:44 2023
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 11 Dec 2023 18:28:44 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v6]
In-Reply-To: <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>
References: <IM48m7ZmMXfs0Hb8Na4S4VzNSsSQr2wF-nAZDOSS7RM=.a0f5e292-ca86-4358-b968-cc8bf0f8f2ec@github.com>
 <xOklXGR_QdSJHh3lcUxV1k4kLWs0TC9wWKZ_eUenbZQ=.5b13ac21-4d7c-482c-b985-a35e19bd89e5@github.com>
 <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com>
 <lQJoZ_hXjfLO-MRGDLar9L0yD6xAXF1QAu2AIAjwnKk=.390b6b58-3e5d-42af-90e6-2dd76b29172f@github.com>
 <AnHvp-NR-sLPEha8BivPv-pBAmquGjSge4TIludLVHM=.e2866a94-78bb-40d7-8506-9807c5a3d786@github.com>
Message-ID: <l5WD1cEIW8M7NHd72gK16F1_2cglU3Leeie4zdyCdR4=.6bb73168-2f49-4091-960c-e332694586fa@github.com>

On Mon, 4 Dec 2023 11:58:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK.

I can add that we are interested to use that for Linux + RISC-V support given the RISC-V support was recently merged into sleef upstream. https://github.com/shibatch/sleef/pull/477

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1850636984

From djelinski at openjdk.org  Tue Dec 12 14:19:32 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Dec 2023 14:19:32 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <ljs1I6oIizDnP7eaVuGd8-nlauqL0O7CNPTUcuNyhsY=.c5b4549a-01ae-4fdf-9f86-d2ddb0528ba4@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
 <ljs1I6oIizDnP7eaVuGd8-nlauqL0O7CNPTUcuNyhsY=.c5b4549a-01ae-4fdf-9f86-d2ddb0528ba4@github.com>
Message-ID: <JHeUhIiuBrpm1Qrs253_330kRrg70C_uhw8HOsDNJSE=.3ed55c16-6459-441a-83df-f2a51138ec1d@github.com>

On Mon, 11 Dec 2023 14:37:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
>> 
>> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
>> 
>> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
>> 
>> In order to use the clang compiler:
>> - install Visual Studio 2022
>> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
>> - configure `--with-toolchain-type=clcl`
>> - compile as usual.
>> 
>> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.
>
> So, in this case, I believe that if it is possible to reuse warnings from "normal" clang, and the rest of the build process from the existing microsoft-cl toolchain, then the impact might be very small in the code. But it will require some surgery in the toolchain logic, to separate the actual compiler from the rest of the toolchain. 
> 
> It can certainly be done, but might take a few iterations back and forth to get it right. But maybe that's the sort of thing that @TheShermanTanker enjoys?
> 
> So my verdict is that we can't really accept this PR as it is, but using microsoft-clang is definitely an interesting experiment, and we should lay the groundwork for being able to implement it in a proper fashion. And if it then actually can be implemented with minimal impact to existing code, then we should do it.

@magicus just to make sure we are talking about the same thing, are you suggesting configuring the compiler separately from the toolchain, using something like `--with-toolchain=microsoft --with-compiler=clang-cl`?

Technically that could work. It still doesn't address the argument that no organization is going to take up the task of maintaining this setup.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1852123265

From ihse at openjdk.org  Tue Dec 12 14:32:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Dec 2023 14:32:25 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <SsXcV-mmFtXevoRmKNavuuESYcp0M2CZyBFV6CNKu94=.2cc92cc2-6559-49f3-92d6-c0e8d8f8de73@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

Yes, something like that, I guess. That's the best way I see towards modelling the change that occurs when cl.exe is replaced with clang-cl.exe. I have not really thought about the details, but the "toolchain" concept has been a bit loose, basically from day 1. For instance, "clang" might mean "clang on linux" or "clang as part of Xcode", and sometimes we really have meant the latter but expressed it like it included the former also.

We have had a very simple world to model before, where we have had basically 1 os <-> 1 toolchain <-> 1 compiler:
* linux - "gnu toolchain" - gcc
* macOS - Xcode - clang
* windows - visual studio/windows sdk - cl

This has allowed us to be sloppy on exactly what we mean. In some cases we have started to tighten up the distinction between os and compiler+toolchain, but we have not really addressed the situation where the compiler is separate from the rest of the toolchain, even though we have had two such cases (originally, gcc was used alongside clang on macOS, and currently, clang is supported as an alternative to gcc on linux).

So I do not know how we should express it as a command line, or how much change is needed in the code base, but yeah, something like that...

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1852147287

From djelinski at openjdk.org  Tue Dec 12 15:07:44 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Dec 2023 15:07:44 GMT
Subject: RFR: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <PsSxuGxAT1bZyGl0vfOBKWaDHBCuKWx96A0fpxRCgWc=.53c412b0-896e-41a6-aa42-2fdbcbf35382@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

Thanks for the discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/17019#issuecomment-1852218648

From djelinski at openjdk.org  Tue Dec 12 15:07:45 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Dec 2023 15:07:45 GMT
Subject: Withdrawn: 8321533: Clang build for Windows
In-Reply-To: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
References: <wjStvhfOItQEFaKVYsLWOR0BNQgRpuUkRV0TQyHDo1c=.02b75ca6-e631-4daf-9a4c-3ec7c9b75bd6@github.com>
Message-ID: <b1XT4uf4F93dx3NrGMygcWzF5Kr7MuTMhSuv-DSl9Kw=.0ab5512c-6c60-4c19-980e-689e0751dfb4@github.com>

On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I'd like to propose a new toolchain for Windows using the clang-cl compiler frontend.
> 
> Clang-cl is available as an optional feature in all Visual Studio editions, including the free-for-OSS-development community edition.
> 
> Clang-cl command line is mostly compatible with cl. However, clang-cl offers a distinct set of diagnostic messages and warnings, which can be used to improve code quality.
> 
> In order to use the clang compiler:
> - install Visual Studio 2022
> - install C++ Clang Compiler (https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild?view=msvc-170)
> - configure `--with-toolchain-type=clcl`
> - compile as usual.
> 
> Note: at this moment the code does not build; I plan to submit separate patches that fix the build problems separately. For the impatient, [this patch](https://github.com/djelinski/jdk/commit/d67a16244f4e6db8e6e8c59266bebd17827bc2a5) should be enough to compile the JDK, and [this one](https://github.com/djelinski/jdk/commit/1580e7cf54cca61d3ab58891619553994ea26b10) is needed to get tier1 to pass.

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Tue Dec 12 15:45:57 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Dec 2023 15:45:57 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
 <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
 <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>
Message-ID: <miE0bEN_JyzIhfmBGCV7OkWags8LM9jM4oQYz1S5z20=.87be0fa6-3860-4bf8-8f57-3b8daaa1e996@github.com>

On Wed, 6 Dec 2023 17:20:10 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> Okay, then I guess I am fine with this.
>
> Thank you Magnus!

@vamsi-parasa You said:
> Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.

but now we have https://bugs.openjdk.org/browse/JDK-8321688. Did you introduce any changes after you tested with GCC 7.5? It seems strange to me that the code simultaneously both works and not works with gcc 7.5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1424200521

From duke at openjdk.org  Tue Dec 12 17:36:55 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 12 Dec 2023 17:36:55 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <miE0bEN_JyzIhfmBGCV7OkWags8LM9jM4oQYz1S5z20=.87be0fa6-3860-4bf8-8f57-3b8daaa1e996@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
 <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
 <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>
 <miE0bEN_JyzIhfmBGCV7OkWags8LM9jM4oQYz1S5z20=.87be0fa6-3860-4bf8-8f57-3b8daaa1e996@github.com>
Message-ID: <pZiF9EcYqj3s4xZg8nGaZKslA3PgzQFJEpcSM54r6QA=.dc100d45-ed72-4a32-a9bc-22e21425b033@github.com>

On Tue, 12 Dec 2023 15:42:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thank you Magnus!
>
> @vamsi-parasa You said:
>> Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.
> 
> but now we have https://bugs.openjdk.org/browse/JDK-8321688. Did you introduce any changes after you tested with GCC 7.5? It seems strange to me that the code simultaneously both works and not works with gcc 7.5.

Hi Magnus (@magicus), did a fresh pull of the OpenJDK and was able to build it successfully (without any errors) using GCC 7.5.0 on Ubuntu Linux machine. 
(I am on vacation till Jan7th, 2024. Our team will look into this issue)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1424352122

From shurailine at openjdk.org  Tue Dec 12 20:44:40 2023
From: shurailine at openjdk.org (Alexandre Iline)
Date: Tue, 12 Dec 2023 20:44:40 GMT
Subject: Integrated: JDK-8321621: Update JCov version to 3.0.16
In-Reply-To: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>
References: <duIcVZlfKM7KtRZHNstcX8DPRF0lk8j4W_3YTeD1KQk=.33c715fc-7150-48d2-9ed2-07ea30dc518c@github.com>
Message-ID: <eUBnc0_chlwULPOz9G2RqcC2j3t33V84oMXruyehLBA=.abf3416e-968d-48fb-ae72-b265fcc40a58@github.com>

On Fri, 8 Dec 2023 22:42:42 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

> JCov support for byte code version 67.

This pull request has now been integrated.

Changeset: d5a96e3f
Author:    Alexandre Iline <shurailine at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5a96e3f490ba9591f61b23dc2b06e65b0098140
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8321621: Update JCov version to 3.0.16

Reviewed-by: erikj, alanb, ihse

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

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

From erikj at openjdk.org  Tue Dec 12 21:34:40 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Dec 2023 21:34:40 GMT
Subject: Integrated: 8321557: Move SOURCE line verification for OracleJDK out
 of OpenJDK
In-Reply-To: <UyyQ3xvNFLcrqmEvxX38ST7mrl4LQR-DjgZXZGf3ASE=.aa8f51e5-6c62-4f49-868b-a297883ff0c8@github.com>
References: <UyyQ3xvNFLcrqmEvxX38ST7mrl4LQR-DjgZXZGf3ASE=.aa8f51e5-6c62-4f49-868b-a297883ff0c8@github.com>
Message-ID: <V6TzG4erl_fPcXKCoc2A-SOikd-MRG-8eTWnytzAqYQ=.57fac471-b489-4037-8df3-cbdf5ed7c12c@github.com>

On Thu, 7 Dec 2023 23:29:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The main goal of this patch is to remove the OracleJDK specific verification of the SOURCE field in the release file from the OpenJDK test. While at it, I decided to do some cleanup as well to make the code a bit more modern and less unnecessarily verbose.

This pull request has now been integrated.

Changeset: 5463c9cd
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5463c9cd9a0a6f95f90787c330679b2ea78690c6
Stats:     70 lines in 1 file changed: 8 ins; 39 del; 23 mod

8321557: Move SOURCE line verification for OracleJDK out of OpenJDK

Reviewed-by: ihse

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

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

From ihse at openjdk.org  Wed Dec 13 09:52:02 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Dec 2023 09:52:02 GMT
Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, 
 float arrays) [v12]
In-Reply-To: <pZiF9EcYqj3s4xZg8nGaZKslA3PgzQFJEpcSM54r6QA=.dc100d45-ed72-4a32-a9bc-22e21425b033@github.com>
References: <yI9DA4K_3UqfZGJ7qvOTtWnkMfF1lS4U71CARznDzCE=.4242105e-3431-4f41-a1c6-be1f2a961144@github.com>
 <e5w5YZ0WD8S3UVFBYz6I0PdKZ6yOkD77BCq2arDd6i4=.7eecadcb-e627-4e9b-8f1e-3fc41c63243b@github.com>
 <bopxvLCquUtZQxt8kAJskzXBR2YE_I0PW13i3NBJNNY=.e65abf3d-0ff4-4450-875b-ca3717170485@github.com>
 <DeQgR1PaXlk2yzlxV15N3ViZY26wXtlgfVKxRY6vuWo=.6d38f729-0ca9-4f43-9e23-f5e73a01cc23@github.com>
 <b1Nv5Y7Klpvp5ACcHJTTblwGmnA64cyRg-3YzotaHvc=.0bd8a0f0-0844-44a9-a3bb-4af2e8514ee1@github.com>
 <t_23EA--aX8v2US9Lsib1ZF3bl4HQx_Z4RXqlgQo8LE=.6f1f2873-015c-4b69-ad47-b449e5b77a45@github.com>
 <pRcJlU1a4jG9gMaftLn5IerudMSDIrvr70KBefkpNSo=.f442f0d4-887f-4376-a66e-8254fa35927c@github.com>
 <OJ1ZK4a8c_bZik60v503VUtZoweFFv6VhhGg1sp4qSY=.e8852bf1-2d7f-4164-b952-d88b294ec1f7@github.com>
 <_gSNXk0qGAtpY-WJ5OCHk_3-nuGrwwSn-ffK9f2TEcs=.40f785ba-83dd-40fe-8075-a7a7872ea600@github.com>
 <v95kXnbADF5XriLfeg2v5yVYBo-BUzR-dhpcubuMDcI=.03d8e5a7-8b0c-4291-99df-2d3ec6cd356c@github.com>
 <D2AGAYSictxU124OSQMg3V5bpM1oKBdxKLd
 BS0X7ow8=.326a6f38-e9ab-4b24-a6d6-d8eebdb346f7@github.com>
 <wpFxnb5dr5v2UHZYPPdi4XsBUiLtFXGxRySgr6xCmJM=.74175d6e-0f30-464e-9c76-cc4e8bd6f36a@github.com>
 <7_T6sM3wjbSzZ0ab9FsptbpPnlQ2J4NNctQNkdbDFdI=.b595a8cc-4b14-44c6-8319-00e68fea21c3@github.com>
 <M2KPFFgTiBmYcdxO7_wNRYYokECxNAHmgsvbt-s8_k0=.6320d2de-2710-4ca7-a6b4-d1954167ca01@github.com>
 <miE0bEN_JyzIhfmBGCV7OkWags8LM9jM4oQYz1S5z20=.87be0fa6-3860-4bf8-8f57-3b8daaa1e996@github.com>
 <pZiF9EcYqj3s4xZg8nGaZKslA3PgzQFJEpcSM54r6QA=.dc100d45-ed72-4a32-a9bc-22e21425b033@github.com>
Message-ID: <wXOSMHIAVb46JQ85dujzmA0LAdQlsL-iDnQoxosc9Z4=.c8b13738-9007-4fe7-a96b-18fdcaf6462b@github.com>

On Tue, 12 Dec 2023 17:33:12 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> @vamsi-parasa You said:
>>> Made sure that OpenJDK builds without errors using both GCC 7.5 and GCC 6.4.
>> 
>> but now we have https://bugs.openjdk.org/browse/JDK-8321688. Did you introduce any changes after you tested with GCC 7.5? It seems strange to me that the code simultaneously both works and not works with gcc 7.5.
>
> Hi Magnus (@magicus), did a fresh pull of the OpenJDK and was able to build it successfully (without any errors) using GCC 7.5.0 on Ubuntu Linux machine. 
> (I am on vacation till Jan7th, 2024. Our team will look into this issue)

New information in JDK-8321688 says it is only happening on slowdebug. This is probably why it was missed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1425106097

From hannesw at openjdk.org  Thu Dec 14 17:20:07 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 14 Dec 2023 17:20:07 GMT
Subject: RFR: JDK-8320458: Improve structural navigation in API documentation
Message-ID: <Y2J4qzdqFTyv4UYXVEOrK5WKe0sppWdYuAl3fAUoQjM=.da828e23-7613-437e-9871-565111397222@github.com>

This is a rather big change to update the structural navigation in API documentation generated by JavaDoc. It adds a table of contents for the current page to module, package, and class documentation, and replaces the old sub-navigation bar with a breadcrumb-style links in those pages. The table of contents is displayed as sidebar on wide/desktop displays and integrated into the collapsible menu for narrow/mobile displays. The generated docs can be browsed here:

https://cr.openjdk.org/~hannesw/8320458/api.00/

This change includes improvements in `stylesheet.css` and `script.js` that are not strictly related to the navigation changes, but happened as a consequence of the necessary restructuring. All these are described together with the more on-topic changes in the list below.

 - The table of contents is composed as the respective writers generate the pages. For this purpose, `HtmlDocletWriter` has a new `tocBuilder` field of new type `ListBuilder`. If the field is not `null` it is used to build the table of contents as the page is built using either one of the  new`HtmlDocletWriter.addToTableOfContents` methods or the `ListBuilder` directly.
 - Once the TOC is built, `HtmlDocletWriter.getSideBar` is used to generate the markup for the sidebar and it is added to the page via the `BodyContents.setSideContent` method.
 - Both existing navigation bars (top and sub-navigation) get an additional `<div>` container with CSS class `nav-content` that uses a flex layout for its content. This also handles vertical positioning, so the old workaround for vertical of the language version label in `Docs.gmk` is not necessary anymore.
 - Apart from modules, packages, and classes, other pages that were converted to obtain a table of contents are the "Constant Field Values" page and the Help page. 
 - Originally, I used the `<aside>` element for the sidebar, but I learned that this was the wrong element as it is meant for content that is not strictly related to the main content of the page. The prevailing notion seems to be that a table of contents is a navigation element and therefore should use the `<nav>` element, so I used that for the TOC sidebar. The same applies for the breadcrumbs sub-navigation, so I left the header `<nav>` element wrapped around both top and sub-navigation.
 - For the new lists in TOC and breadcrumbs I used ordered list elements `<ol>` instead of unordered `<ul>` we use everywhere else, as that is what should be used when list order is important. 
 - The `SEARCH` link that also served as label for the search input field has moved to the top navigation bar. The search input field uses "Search" as placeholder and also got a "Search in documentation" aria-label attribute.
 - The code to locate target anchors in relation to the header navigation has been much improved. For this purpose, new CSS custom properties `--top-nav-height`, `--sub-nav-height` and `--nav-height` have been introduced which are also updated dynamically to avoid any flickering seen in the previous version.
 - Also introduced were a few new CSS custom properties and rules for font sizes that line height that were previously missing. One example is package pages which previously had different line spacing depending on whether a `<p>` tag was present or not.
 - The `Navigation` has been simplified a bit and now uses a single `addOverviewLink` to generate a link to the overview page, the first module page, or the first package page, depending on configuration. a new `addPageElementLink` method creates a link to the current page element. 
 - Several tests were added to `TestNavigation` and `TestModuleNavigation` to check the navigation links in previously untested configurations.
 - Some functionality in `search.js.template` such as implementation of the mobile menu and creating the heading anchor links was not search related and therefore  belonged into `script.js`. This required `script.js` localized properties to be injected into `script.js` which is therefore renamed to `script.js.template` Unfortunately, git did not recognize this as renaming but rather as removal of `script.js` and addition of `script.js.template`, but the file is pretty much unchanged up to line 232 with the new code starting in line 233. 
 - The reset `x` button in the search input field and the new TOC filter field behave a bit differently than previously in that they are only visible if there is some text in the input field. 
 - An empty string `""` in a fragment was so far interpreted as no fragment. However, the empty fragment is now used to navigate to the top of the page (this is standard behaviour and implemented in all browsers and different from clicking on a link without `#` which results in reloading the page rather than scrolling to the top). This required the changes in `DocLink` and `HtmlLinkInfo` as well as  the `LinkChecker` test.
 - Empty and single element lists are required or hard to avoid in breadcrumb and TOC navigation (empty list is present in subheader without breadcrumb links to keep the search input in place, and singleton lists often appear in sublists for single members or headings). Therefore, ample exceptions had to be made in the `TestSingletonLists` test.
 - The `TestSubTitle` test was removed as module and package subtitles have been replaced by the breadcrumb links.

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

Commit messages:
 - Add navigation tests for untested configurations.
 - Consolidate stylesheet changes
 - Fix selector
 - Adapt tests to previous commit
 - Use more appropriate HTML elements, add ARIA label to toc.
 - JDK-8320458: Improve structural navigation in API documentation

Changes: https://git.openjdk.org/jdk/pull/17062/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320458
  Stats: 2987 lines in 70 files changed: 1627 ins; 865 del; 495 mod
  Patch: https://git.openjdk.org/jdk/pull/17062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17062/head:pull/17062

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

From jjg at openjdk.org  Thu Dec 14 17:20:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 14 Dec 2023 17:20:10 GMT
Subject: RFR: JDK-8320458: Improve structural navigation in API
 documentation
In-Reply-To: <Y2J4qzdqFTyv4UYXVEOrK5WKe0sppWdYuAl3fAUoQjM=.da828e23-7613-437e-9871-565111397222@github.com>
References: <Y2J4qzdqFTyv4UYXVEOrK5WKe0sppWdYuAl3fAUoQjM=.da828e23-7613-437e-9871-565111397222@github.com>
Message-ID: <Tky7yzyCtOvmFB4_eh0pvDdvzIY16TZ_ryH7GeUdE5M=.4000f7dc-1662-4a5d-baba-4a3862f6c248@github.com>

On Mon, 11 Dec 2023 16:36:09 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This is a rather big change to update the structural navigation in API documentation generated by JavaDoc. It adds a table of contents for the current page to module, package, and class documentation, and replaces the old sub-navigation bar with a breadcrumb-style links in those pages. The table of contents is displayed as sidebar on wide/desktop displays and integrated into the collapsible menu for narrow/mobile displays. The generated docs can be browsed here:
> 
> https://cr.openjdk.org/~hannesw/8320458/api.00/
> 
> This change includes improvements in `stylesheet.css` and `script.js` that are not strictly related to the navigation changes, but happened as a consequence of the necessary restructuring. All these are described together with the more on-topic changes in the list below.
> 
>  - The table of contents is composed as the respective writers generate the pages. For this purpose, `HtmlDocletWriter` has a new `tocBuilder` field of new type `ListBuilder`. If the field is not `null` it is used to build the table of contents as the page is built using either one of the  new`HtmlDocletWriter.addToTableOfContents` methods or the `ListBuilder` directly.
>  - Once the TOC is built, `HtmlDocletWriter.getSideBar` is used to generate the markup for the sidebar and it is added to the page via the `BodyContents.setSideContent` method.
>  - Both existing navigation bars (top and sub-navigation) get an additional `<div>` container with CSS class `nav-content` that uses a flex layout for its content. This also handles vertical positioning, so the old workaround for vertical of the language version label in `Docs.gmk` is not necessary anymore.
>  - Apart from modules, packages, and classes, other pages that were converted to obtain a table of contents are the "Constant Field Values" page and the Help page. 
>  - Originally, I used the `<aside>` element for the sidebar, but I learned that this was the wrong element as it is meant for content that is not strictly related to the main content of the page. The prevailing notion seems to be that a table of contents is a navigation element and therefore should use the `<nav>` element, so I used that for the TOC sidebar. The same applies for the breadcrumbs sub-navigation, so I left the header `<nav>` element wrapped around both top and sub-navigation.
>  - For the new lists in TOC and breadcrumbs I used ordered list elements `<ol>` instead of unordered `<ul>` we use everywhere else, as that is what should be used when list order is important...

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java line 47:

> 45: import jdk.javadoc.internal.doclets.formats.html.markup.HtmlTree;
> 46: import jdk.javadoc.internal.doclets.formats.html.Navigation.PageMode;
> 47: import jdk.javadoc.internal.doclets.formats.html.markup.Text;

Quibble: order of imports?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java line 425:

> 423:         List<Content> subnavLinks = new ArrayList<>();
> 424:         if (configuration.showModules) {
> 425:             ModuleElement mdle = configuration.docEnv.getElementUtils().getModuleOf(typeElement);

It's more common to use `utils.elementUtils` than the expression `configuration.docEnv.getElementUtils()`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Headings.java line 125:

> 123:         static final TagName SUMMARY_HEADING = TagName.H2;
> 124:     }
> 125: 

Yay!

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/ListBuilder.java line 41:

> 39:  * list. Lists can be added to and removed from the stack using the {@code pushNested}
> 40:  * and {@code popNested} methods.
> 41:  */

Nice!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17062#discussion_r1425741244
PR Review Comment: https://git.openjdk.org/jdk/pull/17062#discussion_r1425745958
PR Review Comment: https://git.openjdk.org/jdk/pull/17062#discussion_r1425755714
PR Review Comment: https://git.openjdk.org/jdk/pull/17062#discussion_r1425756738

From erikj at openjdk.org  Thu Dec 14 17:43:47 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 14 Dec 2023 17:43:47 GMT
Subject: RFR: JDK-8320458: Improve structural navigation in API
 documentation
In-Reply-To: <Y2J4qzdqFTyv4UYXVEOrK5WKe0sppWdYuAl3fAUoQjM=.da828e23-7613-437e-9871-565111397222@github.com>
References: <Y2J4qzdqFTyv4UYXVEOrK5WKe0sppWdYuAl3fAUoQjM=.da828e23-7613-437e-9871-565111397222@github.com>
Message-ID: <S_UIpSrXK63XN_k7pZHT72MG2544dEclmYRyJL0et5A=.c3e8a9da-d454-4107-af4d-40e32e20f6eb@github.com>

On Mon, 11 Dec 2023 16:36:09 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This is a rather big change to update the structural navigation in API documentation generated by JavaDoc. It adds a table of contents for the current page to module, package, and class documentation, and replaces the old sub-navigation bar with a breadcrumb-style links in those pages. The table of contents is displayed as sidebar on wide/desktop displays and integrated into the collapsible menu for narrow/mobile displays. The generated docs can be browsed here:
> 
> https://cr.openjdk.org/~hannesw/8320458/api.00/
> 
> This change includes improvements in `stylesheet.css` and `script.js` that are not strictly related to the navigation changes, but happened as a consequence of the necessary restructuring. All these are described together with the more on-topic changes in the list below.
> 
>  - The table of contents is composed as the respective writers generate the pages. For this purpose, `HtmlDocletWriter` has a new `tocBuilder` field of new type `ListBuilder`. If the field is not `null` it is used to build the table of contents as the page is built using either one of the  new`HtmlDocletWriter.addToTableOfContents` methods or the `ListBuilder` directly.
>  - Once the TOC is built, `HtmlDocletWriter.getSideBar` is used to generate the markup for the sidebar and it is added to the page via the `BodyContents.setSideContent` method.
>  - Both existing navigation bars (top and sub-navigation) get an additional `<div>` container with CSS class `nav-content` that uses a flex layout for its content. This also handles vertical positioning, so the old workaround for vertical of the language version label in `Docs.gmk` is not necessary anymore.
>  - Apart from modules, packages, and classes, other pages that were converted to obtain a table of contents are the "Constant Field Values" page and the Help page. 
>  - Originally, I used the `<aside>` element for the sidebar, but I learned that this was the wrong element as it is meant for content that is not strictly related to the main content of the page. The prevailing notion seems to be that a table of contents is a navigation element and therefore should use the `<nav>` element, so I used that for the TOC sidebar. The same applies for the breadcrumbs sub-navigation, so I left the header `<nav>` element wrapped around both top and sub-navigation.
>  - For the new lists in TOC and breadcrumbs I used ordered list elements `<ol>` instead of unordered `<ul>` we use everywhere else, as that is what should be used when list order is important...

Build changes look good given that the stylesheet workaround is no longer needed.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17062#pullrequestreview-1782364123

From duke at openjdk.org  Fri Dec 15 05:34:04 2023
From: duke at openjdk.org (Sam James)
Date: Fri, 15 Dec 2023 05:34:04 GMT
Subject: RFR: 8318696: Do not use LFS64 symbols on Linux
Message-ID: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>

The LFS64 symbols provided by glibc are not part of any standard and were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). This commit replaces the usage of LFS64 symbols with their regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions will always act as their -64 variants on glibc.

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

Commit messages:
 - Do not use LFS64 symbols on Linux

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

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

From duke at openjdk.org  Fri Dec 15 05:34:05 2023
From: duke at openjdk.org (Sam James)
Date: Fri, 15 Dec 2023 05:34:05 GMT
Subject: RFR: 8318696: Do not use LFS64 symbols on Linux
In-Reply-To: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
References: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
Message-ID: <ExT0V1zfgbRl4xvzxoKhHNEZxIb2yVZXVOlnxsxiNe4=.7d2f4a0e-2878-49a4-ae72-1513bad711a7@github.com>

On Tue, 24 Oct 2023 01:36:32 GMT, Sam James <duke at openjdk.org> wrote:

> The LFS64 symbols provided by glibc are not part of any standard and were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). This commit replaces the usage of LFS64 symbols with their regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions will always act as their -64 variants on glibc.

I've already got an OCA processed for MySQL in the past.

I can't see a signup button for the bug tracker so I can't file an issue to include as a link.

Thanks!

I need to pipe config.h through to handle the x86 failure. I'll do that either today or the day after tomorrow.

OK, this should be better now. I've checked with static asserts that the definition propagates and it also errors out without those anyway on incompat. ptr. types.

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

PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1776330393
PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1776334231
PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1777669228
PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1777726306
PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1857301791

From shade at openjdk.org  Fri Dec 15 05:34:05 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Dec 2023 05:34:05 GMT
Subject: RFR: 8318696: Do not use LFS64 symbols on Linux
In-Reply-To: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
References: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
Message-ID: <q7cM1k3AUr3UtT8ttGPlYPoXmzRdtVwy8YatuYzcYdA=.413e229f-2d3b-43fd-b26f-51a09ca52a1a@github.com>

On Tue, 24 Oct 2023 01:36:32 GMT, Sam James <duke at openjdk.org> wrote:

> The LFS64 symbols provided by glibc are not part of any standard and were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). This commit replaces the usage of LFS64 symbols with their regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions will always act as their -64 variants on glibc.

Submitted the bug: https://bugs.openjdk.org/browse/JDK-8318696
Please rename the PR to: `8318696: Do not use LFS64 symbols on Linux` to get it hooked.

Please also go to https://github.com/thesamesam/jdk/actions and enable testing. The testing would normally trigger by new commit, but you can trigger it manually; select the "OpenJDK GHA Sanity Checks", then do "Run workflow" on the right, selecting the branch that corresponds to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1776636163

From ihse at openjdk.org  Fri Dec 15 05:34:07 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Dec 2023 05:34:07 GMT
Subject: RFR: 8318696: Do not use LFS64 symbols on Linux
In-Reply-To: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
References: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
Message-ID: <Xe2YIRbD_70BcfqgDfeoJMKC2_wyUE632nDVysgjPlE=.fea5e703-9072-4e29-8c1e-04029c783557@github.com>

On Tue, 24 Oct 2023 01:36:32 GMT, Sam James <duke at openjdk.org> wrote:

> The LFS64 symbols provided by glibc are not part of any standard and were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). This commit replaces the usage of LFS64 symbols with their regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions will always act as their -64 variants on glibc.

make/autoconf/configure.ac line 198:

> 196: 
> 197: # Ensure _FILE_OFFSET_BITS is set to 64 for glibc
> 198: AC_SYS_LARGEFILE

We do not use any of the AC_SYS macros in the JDK build. If you want to add `-D_FILE_OFFSET_BITS=64` to the flags, then you need to do so explicitly, at the right location. And you need to decide if it should be added only for Hotspot, only for the JDK native libraries, or both.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16329#discussion_r1389559499

From kbarrett at openjdk.org  Fri Dec 15 07:53:43 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 15 Dec 2023 07:53:43 GMT
Subject: RFR: 8314488: Compile the JDK as C++17
In-Reply-To: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
Message-ID: <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>

On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260)

Nearly ready.  Still need to figure out the minimum compiler versions to require.

src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp line 77:

> 75: #define read_csr(csr)                                           \
> 76: ({                                                              \
> 77:         unsigned long __v;                                      \

Can this change be made separately?  I'd like to have the C++17 switch be as clean as possible.

src/hotspot/share/memory/allocation.cpp line 114:

> 112: //
> 113: 
> 114: void* AnyObj::operator new(size_t size, Arena *arena) {

This change was recently made as part of JDK-8317132.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14988#pullrequestreview-1783283088
PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427655730
PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427654886

From jwaters at openjdk.org  Fri Dec 15 08:08:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Dec 2023 08:08:11 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
Message-ID: <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>

On Fri, 15 Dec 2023 07:48:46 GMT, Kim Barrett <kbarrett 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 five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-7
>>  - Revert vm_version_linux_riscv.cpp
>>  - vm_version_linux_riscv.cpp
>>  - allocation.cpp
>>  - 8310260
>
> src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp line 77:
> 
>> 75: #define read_csr(csr)                                           \
>> 76: ({                                                              \
>> 77:         unsigned long __v;                                      \
> 
> Can this change be made separately?  I'd like to have the C++17 switch be as clean as possible.

No problem!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427669495

From jwaters at openjdk.org  Fri Dec 15 08:08:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Dec 2023 08:08:10 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
Message-ID: <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>

> Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260)

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

 - Merge branch 'openjdk:master' into patch-7
 - Revert vm_version_linux_riscv.cpp
 - vm_version_linux_riscv.cpp
 - allocation.cpp
 - 8310260

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14988/files
  - new: https://git.openjdk.org/jdk/pull/14988/files/09cecd7e..a1f21bbd

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

  Stats: 1027205 lines in 9267 files changed: 298949 ins; 587677 del; 140579 mod
  Patch: https://git.openjdk.org/jdk/pull/14988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14988/head:pull/14988

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

From jwaters at openjdk.org  Fri Dec 15 08:15:40 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Dec 2023 08:15:40 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
 <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>
Message-ID: <-sioWQwLXv1R5crwmt49RTy4FLTqLaHTqDxPpEIlPQY=.73c20e2d-fdcd-49a6-9851-c8198b20efc9@github.com>

On Fri, 15 Dec 2023 08:03:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp line 77:
>> 
>>> 75: #define read_csr(csr)                                           \
>>> 76: ({                                                              \
>>> 77:         unsigned long __v;                                      \
>> 
>> Can this change be made separately?  I'd like to have the C++17 switch be as clean as possible.
>
> No problem!

There are, strangely, many more register keywords in the JDK codebase than just this one, but none of them throw the same errors, only this one does

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427676677

From kbarrett at openjdk.org  Fri Dec 15 09:08:40 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 15 Dec 2023 09:08:40 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <-sioWQwLXv1R5crwmt49RTy4FLTqLaHTqDxPpEIlPQY=.73c20e2d-fdcd-49a6-9851-c8198b20efc9@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
 <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>
 <-sioWQwLXv1R5crwmt49RTy4FLTqLaHTqDxPpEIlPQY=.73c20e2d-fdcd-49a6-9851-c8198b20efc9@github.com>
Message-ID: <O1Y9mEb7-Yt4SG4tGI3wjBi7FSI42Pv-fDrr4IIKpXU=.2a005595-625f-4a19-bc1f-50e52acf0da3@github.com>

On Fri, 15 Dec 2023 08:12:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> No problem!
>
> There are, strangely, many more register keywords in the JDK codebase than just this one, but none of them throw the same errors, only this one does

Looks like this change has also already been made, by JDK-8319440.

All of the other non-comment uses of "register" I found in HotSpot are gcc local variable register specifications:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Local-Register-Variables.html
So are a different thing and not affected by the deprecation/removal of the C++ "register" keyword.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427728697

From jwaters at openjdk.org  Fri Dec 15 11:27:42 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Dec 2023 11:27:42 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <O1Y9mEb7-Yt4SG4tGI3wjBi7FSI42Pv-fDrr4IIKpXU=.2a005595-625f-4a19-bc1f-50e52acf0da3@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
 <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>
 <-sioWQwLXv1R5crwmt49RTy4FLTqLaHTqDxPpEIlPQY=.73c20e2d-fdcd-49a6-9851-c8198b20efc9@github.com>
 <O1Y9mEb7-Yt4SG4tGI3wjBi7FSI42Pv-fDrr4IIKpXU=.2a005595-625f-4a19-bc1f-50e52acf0da3@github.com>
Message-ID: <g4ZymVmK7AZYIe0Q-EWd4e2FNg5oyBVhmH7pcyv03JE=.1eff5070-2b73-4963-8024-c2fc873a386e@github.com>

On Fri, 15 Dec 2023 09:05:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> There are, strangely, many more register keywords in the JDK codebase than just this one, but none of them throw the same errors, only this one does
>
> Looks like this change has also already been made, by JDK-8319440.
> 
> All of the other non-comment uses of "register" I found in HotSpot are gcc local variable register specifications:
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Local-Register-Variables.html
> So are a different thing and not affected by the deprecation/removal of the C++ "register" keyword.

Ah, I was not aware that the asm specifications for explicit registers overrides the warning about the register keyword, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427866744

From dholmes at openjdk.org  Fri Dec 15 12:31:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Dec 2023 12:31:38 GMT
Subject: RFR: 8318696: Do not use LFS64 symbols on Linux
In-Reply-To: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
References: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
Message-ID: <zlyP_F2_Lx0SrhFP5B3N_XrjjBZOGG4iqMQWpRxDoiM=.551ab6e7-9af5-4616-9c0f-ab772e32ad77@github.com>

On Tue, 24 Oct 2023 01:36:32 GMT, Sam James <duke at openjdk.org> wrote:

> The LFS64 symbols provided by glibc are not part of any standard and were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). This commit replaces the usage of LFS64 symbols with their regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions will always act as their -64 variants on glibc.

>From what version of glibc can we be sure that the non-64 version is exactly equivalent to the 64 version for all these functions?

There are also uses of some 64 functions in the JDK code as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1857807361

From kbarrett at openjdk.org  Fri Dec 15 12:34:41 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 15 Dec 2023 12:34:41 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <g4ZymVmK7AZYIe0Q-EWd4e2FNg5oyBVhmH7pcyv03JE=.1eff5070-2b73-4963-8024-c2fc873a386e@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
 <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>
 <-sioWQwLXv1R5crwmt49RTy4FLTqLaHTqDxPpEIlPQY=.73c20e2d-fdcd-49a6-9851-c8198b20efc9@github.com>
 <O1Y9mEb7-Yt4SG4tGI3wjBi7FSI42Pv-fDrr4IIKpXU=.2a005595-625f-4a19-bc1f-50e52acf0da3@github.com>
 <g4ZymVmK7AZYIe0Q-EWd4e2FNg5oyBVhmH7pcyv03JE=.1eff5070-2b73-4963-8024-c2fc873a386e@github.com>
Message-ID: <RkCkO83FzmIoN26nusmPU2YFHicvzZRPrUWA7gzL09E=.eb069037-dcd2-4916-bd31-facf039470ac@github.com>

On Fri, 15 Dec 2023 11:25:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Looks like this change has also already been made, by JDK-8319440.
>> 
>> All of the other non-comment uses of "register" I found in HotSpot are gcc local variable register specifications:
>> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Local-Register-Variables.html
>> So are a different thing and not affected by the deprecation/removal of the C++ "register" keyword.
>
> Ah, I was not aware that the asm specifications for explicit registers overrides the warning about the register keyword, thanks!

It's not that it overrides the warning.  They are different syntactic constructs that just happen to have
a word in common.  The joys of parsing C++ ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427925300

From jwaters at openjdk.org  Fri Dec 15 12:58:39 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Dec 2023 12:58:39 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <RkCkO83FzmIoN26nusmPU2YFHicvzZRPrUWA7gzL09E=.eb069037-dcd2-4916-bd31-facf039470ac@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
 <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>
 <-sioWQwLXv1R5crwmt49RTy4FLTqLaHTqDxPpEIlPQY=.73c20e2d-fdcd-49a6-9851-c8198b20efc9@github.com>
 <O1Y9mEb7-Yt4SG4tGI3wjBi7FSI42Pv-fDrr4IIKpXU=.2a005595-625f-4a19-bc1f-50e52acf0da3@github.com>
 <g4ZymVmK7AZYIe0Q-EWd4e2FNg5oyBVhmH7pcyv03JE=.1eff5070-2b73-4963-8024-c2fc873a386e@github.com>
 <RkCkO83FzmIoN26nusmPU2YFHicvzZRPrUWA7gzL09E=.eb069037-dcd2-4916-bd31-facf039470ac@github.com>
Message-ID: <TBbRGxKwbC34akfUtFZVAhxVuFRVp9KSJnO5bO76MqU=.8bb834fa-79c9-4afa-84bc-0dc44318602b@github.com>

On Fri, 15 Dec 2023 12:31:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Ah, I was not aware that the asm specifications for explicit registers overrides the warning about the register keyword, thanks!
>
> It's not that it overrides the warning.  They are different syntactic constructs that just happen to have
> a word in common.  The joys of parsing C++ ...

The keyword also happens to go in the same location as well. How coincidental...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427947238

From jwaters at openjdk.org  Fri Dec 15 13:08:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 15 Dec 2023 13:08:38 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <TBbRGxKwbC34akfUtFZVAhxVuFRVp9KSJnO5bO76MqU=.8bb834fa-79c9-4afa-84bc-0dc44318602b@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
 <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>
 <-sioWQwLXv1R5crwmt49RTy4FLTqLaHTqDxPpEIlPQY=.73c20e2d-fdcd-49a6-9851-c8198b20efc9@github.com>
 <O1Y9mEb7-Yt4SG4tGI3wjBi7FSI42Pv-fDrr4IIKpXU=.2a005595-625f-4a19-bc1f-50e52acf0da3@github.com>
 <g4ZymVmK7AZYIe0Q-EWd4e2FNg5oyBVhmH7pcyv03JE=.1eff5070-2b73-4963-8024-c2fc873a386e@github.com>
 <RkCkO83FzmIoN26nusmPU2YFHicvzZRPrUWA7gzL09E=.eb069037-dcd2-4916-bd31-facf039470ac@github.com>
 <TBbRGxKwbC34akfUtFZVAhxVuFRVp9KSJnO5bO76MqU=.8bb834fa-79c9-4afa-84bc-0dc44318602b@github.com>
Message-ID: <ZkpibEZ4hSL1QDqU8uba-9KAwQfwj_OpqcIVTwrbncA=.d7c94d5e-5aae-4d57-a5f7-7322c0d93824@github.com>

On Fri, 15 Dec 2023 12:56:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> It's not that it overrides the warning.  They are different syntactic constructs that just happen to have
>> a word in common.  The joys of parsing C++ ...
>
> The keyword also happens to go in the same location as well. How coincidental...

I also realized that this uses a gcc statement expression currently, I wonder if this could use a lambda expression instead in another change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1427955879

From mdoerr at openjdk.org  Fri Dec 15 13:54:47 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 15 Dec 2023 13:54:47 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
Message-ID: <Fdnfsaa4wVGZzEl0NTiVVc4GkPQ-DF2mZbMZjzQZT3A=.b81e8f8e-5e50-4a7f-8aad-99ad3db54114@github.com>

On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-7
>  - Revert vm_version_linux_riscv.cpp
>  - vm_version_linux_riscv.cpp
>  - allocation.cpp
>  - 8310260

In case you want to update the required compiler versions as part of this PR: We have tested
-TOOLCHAIN_MINIMUM_VERSION_xlc="16.1.0.0011"
+TOOLCHAIN_MINIMUM_VERSION_xlc="17.1.1.4"
(Already discussed with Kim.)

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1857916995

From kbarrett at openjdk.org  Fri Dec 15 15:54:47 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 15 Dec 2023 15:54:47 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
Message-ID: <LWhMxqvcqUAbLu31OjSp_P0xwyEIf2iJFRYx9FqedMI=.c643f2ec-d417-435c-8d77-921eb6a066ab@github.com>

On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-7
>  - Revert vm_version_linux_riscv.cpp
>  - vm_version_linux_riscv.cpp
>  - allocation.cpp
>  - 8310260

In conjunction with changing to C++17, I suggest the following changes to the
minimum compiler versions, as indicated in make/autoconf/toolchain.m4

old:
make/autoconf/toolchain.m4
TOOLCHAIN_MINIMUM_VERSION_clang="3.5"
TOOLCHAIN_MINIMUM_VERSION_gcc="6.0"
TOOLCHAIN_MINIMUM_VERSION_microsoft="19.28.0.0" # VS2019 16.8, aka MSVC 14.28
TOOLCHAIN_MINIMUM_VERSION_xlc="16.1.0.0011"

proposed new:
TOOLCHAIN_MINIMUM_VERSION_clang="13.0"
TOOLCHAIN_MINIMUM_VERSION_gcc="9.0"
TOOLCHAIN_MINIMUM_VERSION_microsoft="19.28.0.0" # VS2019 16.8, aka MSVC 14.28
TOOLCHAIN_MINIMUM_VERSION_xlc="17.1.1.4"

Here's the rationale for each of these:

----- 
gcc:
https://gcc.gnu.org/gcc-9/changes.html
"The C++17 implementation is no longer experimental."

----- 
open xl c++ for aix
https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.1?topic=features-supported-language-levels
supports C17 and C++17, with experimental support for C++20
17.1.0 docs explicitly says __clang_version__ is 13.0.0, with the other
version macros set accordingly.  17.1.1 just describes the version macros, but
doesn't say what their values are.  But the __VERSION__ macro description
includes "Clang 15.0.0" in the string.
Note that there is now a 17.1.2 version, but the aix-ppc porters haven't proposed
going that far.

----- 
Visual Studio
https://learn.microsoft.com/en-gb/cpp/overview/visual-cpp-language-conformance?view=msvc-170
We already require VS2019 16.8, which covers all of C++17 features listed on
that page.

----- 
clang
https://clang.llvm.org/cxx_status.html
c++17 - Clang 5

However, there is a critical bug for which we really want a fix. Using
[[noreturn]] seems to be buggy and leads to crashes. This has been seen with
clang 12. It appears to be fixed with clang 13.0.0 (Xcode 13.0).

There may also be a bug somewhere in the 13.x release series with the handling
of noexcept.  See discussion in https://bugs.openjdk.org/browse/JDK-8255082.

Oracle is currently using Xcode 14.3.1 (clang 14.0.3), so I think we wouldn't
object to something between 13.0.0 and 14.0.3 as the minimum version.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1858097523

From kbarrett at openjdk.org  Fri Dec 15 16:22:48 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 15 Dec 2023 16:22:48 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
Message-ID: <rALQV1gN8swhyvV9HKuR_Zy0Pxlmh9hSroAXbAjp57k=.6d33fcfd-f46b-46ef-a8de-8258e7705810@github.com>

On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-7
>  - Revert vm_version_linux_riscv.cpp
>  - vm_version_linux_riscv.cpp
>  - allocation.cpp
>  - 8310260

I agree that before throwing this switch, we need to look at some specific
issues that might need to be addressed, discuss the benefits, and also the
costs.

As was discussed for the change to C++14, there is *never* a good time to
start introducing the use of new language features as far as backporting is
concerned, unless one is going to backport the language change too. We didn't
do that for C++14, and I don't think we are going to (nor should) do it for
C++17 either.  But backporting concerns can't be all powerful, as that will
forever prevent potentially significant improvements.

I started to make a list of new language features that seem particularly
beneficial or otherwise important.  I was going to write style guide updates
for these, but haven't gotten very far with that yet.

P0035R4: Dynamic memory allocation for over-aligned data
P0135R1: Guaranteed copy elision
P0145R3: Refining Expression Evaluation Order for Idiomatic C++
P0292R2: constexpr if
P0091R3/P0512R0: Template argument deduction for class templates

Here are some others that might be of interest to us.
N4268: Allow constant evaluation for all non-type template arguments
N3928: Extending static_assert
P0118R1: [[fallthrough]] attribute
P0189R1: [[nodiscard]] attribute
P0212R1: [[maybe_unused]] attribute
P0170R1: Wording for constexpr lambda
P0283R2: Ignoring unsupported non-standard attributes 
P0061R1: __has_include for C++17
P0386R2: Inline variables

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1858136247

From duke at openjdk.org  Sat Dec 16 06:50:37 2023
From: duke at openjdk.org (Sam James)
Date: Sat, 16 Dec 2023 06:50:37 GMT
Subject: RFR: 8318696: Do not use LFS64 symbols on Linux
In-Reply-To: <zlyP_F2_Lx0SrhFP5B3N_XrjjBZOGG4iqMQWpRxDoiM=.551ab6e7-9af5-4616-9c0f-ab772e32ad77@github.com>
References: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
 <zlyP_F2_Lx0SrhFP5B3N_XrjjBZOGG4iqMQWpRxDoiM=.551ab6e7-9af5-4616-9c0f-ab772e32ad77@github.com>
Message-ID: <jtWHErWdM8Bf0t0XJCdEfiB3xiaLFSBBRHB0Fv-illM=.c2b1f895-e330-4fc6-8790-986778291f70@github.com>

On Fri, 15 Dec 2023 12:28:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>From what version of glibc can we be sure that the non-64 version is exactly equivalent to the 64 version for all these functions?

Fortunately, support for `_FILE_OFFSET_BITS=64` making `off_t` 64-bit has been supported for quite a long time in glibc (unlike 64-bit `time_t` on 32-bit arches which is _way_ more recent, like the last 2 years...).

It dates back to 1997. The exception is for `fts.h` which got wired up in 2015 (8b7b7f75d91f7bac323dd6a370aeb3e9c5c4a7d5) (glibc-2.23). OpenJDK doesn't use fts, so we're fine. It errored out before then anyway, it didn't silently fallback to 32-bit.

>There are also uses of some 64 functions in the JDK code as well.

This requires closer inspection to determine how broken they are outside of these changes.

For some of the cases in the JDK code, `foo64()` functions are only used in some cases on AIX, leaving `foo()` used on e.g. 32-bit Linux. Some of them might be semantically broken already, not just at build-time with newer musl where `off_t` is always 64-bit.

My preference for moving forward is:
1) I add some `static_assert` for `off_t` to the modified JVM bits to be safe (that's what I tested with);
2) We keep this PR for the build-only fixes which are semantically identical to the previous code - this PR currently "preserves" bitness, it doesn't fix anything other than avoiding use of `foo64()` where it's unnecessary by converting to foo, but the `foo64()` use was right - just a glibcism - until now. From what I can tell, the JVM code touched here was correct, just relying on glibcisms;
3) In another PR, we look at the general 32-bit LFS situation which may involve runtime fixes if - as it appears - `off_t` is actually 32-bit on x86 systems right now and non `foo64()` functions are being used. Then we either port more stuff to use `foo64()` (not ideal), or consistently use `foo()` in more places with `FILE_OFFSET_BITS`.

My hope is to separate these semantic changes from the equivalent-behaviour stuff both to ease review but also because there's a bunch of projects which need noop fixes like this still that I need to look at.

I can't promise to be able to do 3) immediately though. I can probably start it soon, I just can't promise to get the whole thing done quickly.

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1858739783

From aph at openjdk.org  Sat Dec 16 13:04:38 2023
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 16 Dec 2023 13:04:38 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <ZkpibEZ4hSL1QDqU8uba-9KAwQfwj_OpqcIVTwrbncA=.d7c94d5e-5aae-4d57-a5f7-7322c0d93824@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <7D2C1yM2AS-G86oZF15MzMSrO0-pFMwXBVtVgzQ-_-Q=.0a5e2f6b-9aaa-483a-97c6-d75fee5f197d@github.com>
 <dLAHNvJxJGrz2JMEhDthBJwQTBvSmJlx0NWBAOQ3yGc=.ae213409-eabf-4beb-aaa2-b9449c19dce8@github.com>
 <-sioWQwLXv1R5crwmt49RTy4FLTqLaHTqDxPpEIlPQY=.73c20e2d-fdcd-49a6-9851-c8198b20efc9@github.com>
 <O1Y9mEb7-Yt4SG4tGI3wjBi7FSI42Pv-fDrr4IIKpXU=.2a005595-625f-4a19-bc1f-50e52acf0da3@github.com>
 <g4ZymVmK7AZYIe0Q-EWd4e2FNg5oyBVhmH7pcyv03JE=.1eff5070-2b73-4963-8024-c2fc873a386e@github.com>
 <RkCkO83FzmIoN26nusmPU2YFHicvzZRPrUWA7gzL09E=.eb069037-dcd2-4916-bd31-facf039470ac@github.com>
 <TBbRGxKwbC34akfUtFZVAhxVuFRVp9KSJnO5bO76MqU=.8bb834fa-79c9-4afa-84bc-0dc44318602b@github.com>
 <ZkpibEZ4hSL1QDqU8uba-9KAwQfwj_OpqcIVTwrbncA=.d7c94d5e-5aae-4d57-a5f7-7322c0d93824@github.com>
Message-ID: <tOX0d5_sjQ4Ccm_LDbDMxwCda1hdlCJbkzUuzTLCnQE=.82884abb-4866-4bd0-87f9-bf459bf51722@github.com>

On Fri, 15 Dec 2023 13:05:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> The keyword also happens to go in the same location as well. How coincidental...
>
> I also realized that this uses a gcc statement expression currently, I wonder if this could use a lambda expression instead in another change?

That's the standard idiom for accessing CSR, as used in libc and elsewhere. I think that avoiding divergence with such other sources is probably more important than some notion of standard purity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1428804231

From dholmes at openjdk.org  Sun Dec 17 22:39:37 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 17 Dec 2023 22:39:37 GMT
Subject: RFR: 8318696: Do not use LFS64 symbols on Linux
In-Reply-To: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
References: <OLspwqHgoPpCvmUWdKtJWAQUvDejuds9B_-wN2Si5jk=.fd93f1f6-ccc8-4461-91a7-370a4966fc77@github.com>
Message-ID: <otKFVJUsY_ikMLRQUas2IPQch5amTlafp9dRd3ahDYw=.0579561a-94ff-4865-8c6e-e7d39bb26bad@github.com>

On Tue, 24 Oct 2023 01:36:32 GMT, Sam James <duke at openjdk.org> wrote:

> The LFS64 symbols provided by glibc are not part of any standard and were gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). This commit replaces the usage of LFS64 symbols with their regular counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions will always act as their -64 variants on glibc.

I did a bit of archaeology here and have linked a number of existing JBS issues to JDK-8318696.

I don't know the exact history as to why we chose to use LFS64 vs FOB64 (perhaps glibc version limitations?) but it is clear (e.g. from [JDK-8062658](https://bugs.openjdk.org/browse/JDK-8062658)) that there has been confusion about when to use the 64-bit variants in the JDK. For Hotspot I don't see any issue switching to  FOB64 in place of LFS64. So the outlined plan seems good.

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

PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1859307211

From fthevenet at openjdk.org  Mon Dec 18 19:21:01 2023
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Mon, 18 Dec 2023 19:21:01 GMT
Subject: RFR: 8322309: Fix an inconsistancy in spacing style in
 spec.gmk.template
Message-ID: <ItrPc5H8-wXeOoiWnP8DMLNMfnX29fnb5isVps1vv38=.07bf3fc4-c24e-41f0-85d5-ea4c8dc3a5b1@github.com>

[JDK-8320763](https://bugs.openjdk.org/browse/JDK-8320763) fixed the consistency of spaces around the assignment operators in spec.gmk.in (as it was called then).
Unfortunately [JDK-8321374](https://bugs.openjdk.org/browse/JDK-8321374) re-introduced one such inconsistency and so this follow-up aims to fix this.

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

Commit messages:
 - Fix an inconsistancy in spacing style in spec.gmk.template

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

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

From sgehwolf at openjdk.org  Tue Dec 19 13:05:47 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Dec 2023 13:05:47 GMT
Subject: RFR: 8322309: Fix an inconsistancy in spacing style in
 spec.gmk.template
In-Reply-To: <ItrPc5H8-wXeOoiWnP8DMLNMfnX29fnb5isVps1vv38=.07bf3fc4-c24e-41f0-85d5-ea4c8dc3a5b1@github.com>
References: <ItrPc5H8-wXeOoiWnP8DMLNMfnX29fnb5isVps1vv38=.07bf3fc4-c24e-41f0-85d5-ea4c8dc3a5b1@github.com>
Message-ID: <hOPFN4gVDXLJE6El5dervca8tsezTtG_mBj2fdAyLfw=.28ae5362-47ef-4a83-8819-a4f22674c67c@github.com>

On Mon, 18 Dec 2023 17:06:51 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> [JDK-8320763](https://bugs.openjdk.org/browse/JDK-8320763) fixed the consistency of spaces around the assignment operators in spec.gmk.in (as it was called then).
> Unfortunately [JDK-8321374](https://bugs.openjdk.org/browse/JDK-8321374) re-introduced one such inconsistency and so this follow-up aims to fix this.

Looks good (and trivial).

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17149#pullrequestreview-1788823609

From erikj at openjdk.org  Tue Dec 19 13:47:41 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 19 Dec 2023 13:47:41 GMT
Subject: RFR: 8322309: Fix an inconsistancy in spacing style in
 spec.gmk.template
In-Reply-To: <ItrPc5H8-wXeOoiWnP8DMLNMfnX29fnb5isVps1vv38=.07bf3fc4-c24e-41f0-85d5-ea4c8dc3a5b1@github.com>
References: <ItrPc5H8-wXeOoiWnP8DMLNMfnX29fnb5isVps1vv38=.07bf3fc4-c24e-41f0-85d5-ea4c8dc3a5b1@github.com>
Message-ID: <ryUUGIIP52lBSL_Y7UXmf8Xnac1f5x13Na4Ub8mxQgs=.9127ec37-d1e1-4f39-8e3e-7875fa40fa2b@github.com>

On Mon, 18 Dec 2023 17:06:51 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> [JDK-8320763](https://bugs.openjdk.org/browse/JDK-8320763) fixed the consistency of spaces around the assignment operators in spec.gmk.in (as it was called then).
> Unfortunately [JDK-8321374](https://bugs.openjdk.org/browse/JDK-8321374) re-introduced one such inconsistency and so this follow-up aims to fix this.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17149#pullrequestreview-1788900164

From fthevenet at openjdk.org  Tue Dec 19 13:57:53 2023
From: fthevenet at openjdk.org (Frederic Thevenet)
Date: Tue, 19 Dec 2023 13:57:53 GMT
Subject: Integrated: 8322309: Fix an inconsistancy in spacing style in
 spec.gmk.template
In-Reply-To: <ItrPc5H8-wXeOoiWnP8DMLNMfnX29fnb5isVps1vv38=.07bf3fc4-c24e-41f0-85d5-ea4c8dc3a5b1@github.com>
References: <ItrPc5H8-wXeOoiWnP8DMLNMfnX29fnb5isVps1vv38=.07bf3fc4-c24e-41f0-85d5-ea4c8dc3a5b1@github.com>
Message-ID: <2q3mRc8BwNlazJlu5rgb1EiK1Lo3zGx_mpPanednQWM=.2d7055dd-fe96-4a77-a32c-4286b811f886@github.com>

On Mon, 18 Dec 2023 17:06:51 GMT, Frederic Thevenet <fthevenet at openjdk.org> wrote:

> [JDK-8320763](https://bugs.openjdk.org/browse/JDK-8320763) fixed the consistency of spaces around the assignment operators in spec.gmk.in (as it was called then).
> Unfortunately [JDK-8321374](https://bugs.openjdk.org/browse/JDK-8321374) re-introduced one such inconsistency and so this follow-up aims to fix this.

This pull request has now been integrated.

Changeset: 3bc5679c
Author:    Frederic Thevenet <fthevenet at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bc5679cab03936005be02e7b8140d549396d5e2
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8322309: Fix an inconsistancy in spacing style in spec.gmk.template

Reviewed-by: sgehwolf, erikj

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

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

From acobbs at openjdk.org  Tue Dec 19 22:53:16 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 19 Dec 2023 22:53:16 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
Message-ID: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>

Please review several fixes and improvements to the `this-escape` lint warning analyzer.

The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.

Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.

The changes are summarized here:

#### 1. Generalize how we categorize references

The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".

Previously the `Ref` categories were:
* `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
* `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
* `VarRef` - A local variable or method parameter currently in scope
* `ExprRef` - An object reference sitting on top of the Java execution stack
* `YieldRef` - The current switch expression's yield value(s)
* `ReturnRef` - The current method's return value(s)

For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).

The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.

In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".

As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.

#### 2. Track the types of all references

By keeping track of the actual type of each reference (as opposed to just looking at its compile-time type), we can make more precise calculations. We weren't doing this before.

For example consider this class:

public class Leaker {

    public Leaker() {
        Runnable r = new Runnable() {
            public void run() {
                Leaker.this.mightLeak();
            }
        };
        r.run();   // there is a leak here
    }

    protected void mightLeak() {
        // a subclass could override this method
    }
}

Previously we would not have detected a 'this' escape because we wouldn't have known that variable `r` is a `Leaker$1`, which allows us to deduce that `r.run()` is actually `Leaker$1.run()` (which we can analyze) instead of just `Runnable.run()` (which we can't).

Because of this change, some `Ref` types that were previously singletons are no longer singletons. For example, now there can be more than one `ReturnRef` in scope at any time, representing different possible types for the method's return value.

#### 3. Handling of non-public outer instances

To eliminate some false positives, we no longer warn if a leak happens solely due to a "non-public" outer instance.

For example, consider this code:

public class Test {

    public Test() {
        System.out.println(new Inner());
    }   

    private class Inner {
        Object getMyOuter() {
            return Test.this;
        }
    }
}

The outer `Test` instance associated with objects of type `Test.Inner` is considered "non-public" because it's not directly accessible to the outside world (because `Test.Inner` is a private class). So while it's true that instances of `Test.Inner` retain a reference to their enclosing instance, an unrelated method like `System.out.println()` wouldn't know how to access them. The only way a `Test.Inner` could leak its outer instance to such a method is if it did so (perhaps indirectly) through some entr?e that the method "knows about". Of course, that's possible, but absent any further analysis (which could be added in the future), the cost/reward trade-off doesn't seem worth generating a warning here.

This is an area for future research. In other words: when a `Ref` is passed to unknown code, when is it worth complaining about a leak, and when should we just be silent? Previously we always complained, but now that we have more information about references (namely, their types) we can be a little more discriminating.

In any case, this decision is encapsulated in a new method `triggersUnknownInvokeLeak()`.

#### 4. Fix tracking of new instances

Previously we were not tracking references from a constructor's "return value", i.e., the new instance. We fix this by pretending that constructors end with `return this`.

#### 5. Fix tracking of enhanced `for()` loops

Previously we were not tracking the implicit invocations of `iterator()`, `hasNext()`, and `next()` associated with enhanced `for()` loops. This patch adds that tracking.

#### 6. Fix leaks via return values from lambdas and method references

Leaks inside lambdas and methods referred-to by method reference were being detected properly, but leaks from the _return values_ of those things were not.

So for example, this code would escape notice:

import java.util.function.Supplier;
public class Test {

    public Test() {
        ((Supplier<Test>)this::self).get().mightLeak();
    }   

    public final Test self() {
        return this;
    }

    protected void mightLeak() {
        // a subclass could override this method
    }
}

This patch fixes this omission.

#### 7. Some minor refactoring to make the code clearer

* Some methods were renamed
* Some bits of code were extracted into separate methods
* Added `Ref`  methods `toDirect()`, `toIndirect()`, `toOuter()`, and `fromOuter()`

#### 8. Remove some unnecessary suppression

Several `*.gmk` build files were suppressing `this-escape` warnings unnecessarily. These have been updated.

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

Commit messages:
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Javadoc++
 - Merge branch 'master' into JDK-8317376
 - Several improvements to the 'this' escape analyzer.

Changes: https://git.openjdk.org/jdk/pull/16208/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317376
  Stats: 870 lines in 20 files changed: 512 ins; 148 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/16208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208

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

From jwaters at openjdk.org  Wed Dec 20 04:52:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 20 Dec 2023 04:52:27 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v3]
In-Reply-To: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
Message-ID: <H6MFkWgob3mKdYdGAeWJ_CPL5hlS9_Gl7CFDjMZFCD8=.2d66257b-f475-48ea-868f-44e4a0e42929@github.com>

> Compile the JDK as C++17, enabling the use of all C++17 language features

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

 - Compiler versions in toolchain.m4
 - Merge branch 'openjdk:master' into patch-7
 - Merge branch 'openjdk:master' into patch-7
 - Revert vm_version_linux_riscv.cpp
 - vm_version_linux_riscv.cpp
 - allocation.cpp
 - 8310260

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14988/files
  - new: https://git.openjdk.org/jdk/pull/14988/files/a1f21bbd..477f6b94

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

  Stats: 2377 lines in 158 files changed: 1669 ins; 268 del; 440 mod
  Patch: https://git.openjdk.org/jdk/pull/14988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14988/head:pull/14988

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

From stuefe at openjdk.org  Wed Dec 20 08:15:55 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 20 Dec 2023 08:15:55 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <rALQV1gN8swhyvV9HKuR_Zy0Pxlmh9hSroAXbAjp57k=.6d33fcfd-f46b-46ef-a8de-8258e7705810@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
 <rALQV1gN8swhyvV9HKuR_Zy0Pxlmh9hSroAXbAjp57k=.6d33fcfd-f46b-46ef-a8de-8258e7705810@github.com>
Message-ID: <l-0CvjHmctKECA25OK882yKfjx5VaZNWU9nTCRR8m98=.5e5431ce-5068-4d89-9b87-ead883136183@github.com>

On Fri, 15 Dec 2023 16:20:02 GMT, Kim Barrett <kbarrett 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 five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-7
>>  - Revert vm_version_linux_riscv.cpp
>>  - vm_version_linux_riscv.cpp
>>  - allocation.cpp
>>  - 8310260
>
> I agree that before throwing this switch, we need to look at some specific
> issues that might need to be addressed, discuss the benefits, and also the
> costs.
> 
> As was discussed for the change to C++14, there is *never* a good time to
> start introducing the use of new language features as far as backporting is
> concerned, unless one is going to backport the language change too. We didn't
> do that for C++14, and I don't think we are going to (nor should) do it for
> C++17 either.  But backporting concerns can't be all powerful, as that will
> forever prevent potentially significant improvements.
> 
> I started to make a list of new language features that seem particularly
> beneficial or otherwise important.  I was going to write style guide updates
> for these, but haven't gotten very far with that yet.
> 
> P0035R4: Dynamic memory allocation for over-aligned data
> P0135R1: Guaranteed copy elision
> P0145R3: Refining Expression Evaluation Order for Idiomatic C++
> P0292R2: constexpr if
> P0091R3/P0512R0: Template argument deduction for class templates
> 
> Here are some others that might be of interest to us.
> N4268: Allow constant evaluation for all non-type template arguments
> N3928: Extending static_assert
> P0118R1: [[fallthrough]] attribute
> P0189R1: [[nodiscard]] attribute
> P0212R1: [[maybe_unused]] attribute
> P0170R1: Wording for constexpr lambda
> P0283R2: Ignoring unsupported non-standard attributes 
> P0061R1: __has_include for C++17
> P0386R2: Inline variables

@kimbarrett 
> P0035R4: Dynamic memory allocation for over-aligned data

Do we really need this? I ask because, in the end, this will result in something like `posix_memalign` to be called, and I remember it being notorious for causing large footprint overhead depending on how smart the underlying allocator is about using alignment waste.

It will also be non-trivial to implement in hotspot since NMT uses malloc headers. Barring a rewrite of NMT malloc metadata tracking (e.g. using a hash map, which would be more costly both in terms of performance and, probably, footprint), malloc headers would have to be revised. Probably would need to be dynamic-sized. This is the reason we did not bother wrapping posix_memalign.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1864039399

From dfuchs at openjdk.org  Wed Dec 20 09:06:37 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Dec 2023 09:06:37 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <i2dqrXTLtVjEDs2ZwOEz_DxZfYlq_hDUZAtTM_ucni8=.580b80a6-8465-423a-809f-09cdba6a2552@github.com>

On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

Hummm... I know a few (two) places in `java.net.http` where we deliberately let `this` escape. One place is where we set up the double final link between an `HttpClientImpl` instance and its facade (set at construction time where the facade has a final field pointing at its implementation and the implementation has a final `WeakRefeference` pointing at its facade, all set up within their constructors). Another place is with the `SSLflowDelegate` where `connect`, a protected method implemented on the `SSLTube.SSLTubeFlowDelegate` subclass is called from within the super class constructor. I assume these were the reason why `this-escape` analysis had been disabled on `java.net.http`, and I expect the reason why the analysis can be reenabled by default is because of point 3 above?

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

PR Comment: https://git.openjdk.org/jdk/pull/16208#issuecomment-1864102081

From kbarrett at openjdk.org  Wed Dec 20 12:23:41 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 20 Dec 2023 12:23:41 GMT
Subject: RFR: 8314488: Compile the JDK as C++17
In-Reply-To: <fwHkvRmlvF5bjHvnh9NnTD0th1SQG4_5z4HCcjCW1gs=.e2e6c4b1-3202-4f7e-b3df-c5ed6bd46a6a@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <WhQB3S6X1pkfnG2EzsdLRYTfoyU3v2Re3EWXKOYpWU0=.ead1cfdc-290b-473a-985d-1dc7c7bfebb0@github.com>
 <fwHkvRmlvF5bjHvnh9NnTD0th1SQG4_5z4HCcjCW1gs=.e2e6c4b1-3202-4f7e-b3df-c5ed6bd46a6a@github.com>
Message-ID: <yp_3yyHBmuXLW-g2A0V-6dG1Ior3VB713J0hMnO6Hd8=.80b0dbe8-a5dd-4157-8ed8-0453371172a7@github.com>

On Sat, 19 Aug 2023 07:45:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Is it impractical to drop the obsolete features of C++11, working in the common subset of C++11 and C++17?

I'm not sure what is being suggested.  Maybe some examples would help.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1864383047

From kbarrett at openjdk.org  Wed Dec 20 12:23:39 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 20 Dec 2023 12:23:39 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <Fdnfsaa4wVGZzEl0NTiVVc4GkPQ-DF2mZbMZjzQZT3A=.b81e8f8e-5e50-4a7f-8aad-99ad3db54114@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
 <Fdnfsaa4wVGZzEl0NTiVVc4GkPQ-DF2mZbMZjzQZT3A=.b81e8f8e-5e50-4a7f-8aad-99ad3db54114@github.com>
Message-ID: <uFWhaiHNpXL4Jz6JW86y6m1lNAnq5ODSCzlVqdoh53g=.e7e52bdc-185d-41f1-9688-afe589d90595@github.com>

On Fri, 15 Dec 2023 13:52:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> In case you want to update the required compiler versions as part of this PR: We have tested -TOOLCHAIN_MINIMUM_VERSION_xlc="16.1.0.0011" +TOOLCHAIN_MINIMUM_VERSION_xlc="17.1.1.4" (Already discussed with Kim.)

Also discussed with the aix-ppc port maintainers at IBM.

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1864380101

From kbarrett at openjdk.org  Wed Dec 20 12:18:54 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 20 Dec 2023 12:18:54 GMT
Subject: RFR: 8314488: Compile the JDK as C++17 [v2]
In-Reply-To: <rALQV1gN8swhyvV9HKuR_Zy0Pxlmh9hSroAXbAjp57k=.6d33fcfd-f46b-46ef-a8de-8258e7705810@github.com>
References: <AEbQwklk0BKKqSNf3fdOEqHSDaC60Kfb-ZwlMH64IBM=.a510a36f-5b27-486f-8f6f-6b60671fcfca@github.com>
 <YRKvw0czAt9T7g8TS6qA1OEEusSzBDRxts1CfJX8eC8=.669b6808-099b-47d2-b301-a8dfee771ca3@github.com>
 <rALQV1gN8swhyvV9HKuR_Zy0Pxlmh9hSroAXbAjp57k=.6d33fcfd-f46b-46ef-a8de-8258e7705810@github.com>
Message-ID: <jtEt_X3Nd7YgCwyrIr49YcbNgb7QsjEIhhjZ-vINFik=.c30eded2-796f-4bb7-8eed-d6595418cd03@github.com>

On Fri, 15 Dec 2023 16:20:02 GMT, Kim Barrett <kbarrett 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 five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into patch-7
>>  - Revert vm_version_linux_riscv.cpp
>>  - vm_version_linux_riscv.cpp
>>  - allocation.cpp
>>  - 8310260
>
> I agree that before throwing this switch, we need to look at some specific
> issues that might need to be addressed, discuss the benefits, and also the
> costs.
> 
> As was discussed for the change to C++14, there is *never* a good time to
> start introducing the use of new language features as far as backporting is
> concerned, unless one is going to backport the language change too. We didn't
> do that for C++14, and I don't think we are going to (nor should) do it for
> C++17 either.  But backporting concerns can't be all powerful, as that will
> forever prevent potentially significant improvements.
> 
> I started to make a list of new language features that seem particularly
> beneficial or otherwise important.  I was going to write style guide updates
> for these, but haven't gotten very far with that yet.
> 
> P0035R4: Dynamic memory allocation for over-aligned data
> P0135R1: Guaranteed copy elision
> P0145R3: Refining Expression Evaluation Order for Idiomatic C++
> P0292R2: constexpr if
> P0091R3/P0512R0: Template argument deduction for class templates
> 
> Here are some others that might be of interest to us.
> N4268: Allow constant evaluation for all non-type template arguments
> N3928: Extending static_assert
> P0118R1: [[fallthrough]] attribute
> P0189R1: [[nodiscard]] attribute
> P0212R1: [[maybe_unused]] attribute
> P0170R1: Wording for constexpr lambda
> P0283R2: Ignoring unsupported non-standard attributes 
> P0061R1: __has_include for C++17
> P0386R2: Inline variables

> @kimbarrett
> 
> > P0035R4: Dynamic memory allocation for over-aligned data
> 
> Do we really need this? I ask because, in the end, this will result in something like `posix_memalign` to be called, and I remember it being notorious for causing large footprint overhead depending on how smart the underlying allocator is about using alignment waste.
> 
> It will also be non-trivial to implement in hotspot since NMT uses malloc headers. Barring a rewrite of NMT malloc metadata tracking (e.g. using a hash map, which would be more costly both in terms of performance and, probably, footprint), malloc headers would have to be revised. Probably would need to be dynamic-sized. This is the reason we did not bother wrapping posix_memalign.

We already have code that (incorrectly) expects dynamic allocation to support
overalignment. There are several classes that overalign (often cache align) a
member to avoid false sharing, but are dynamically allocated. See most (all?)
uses of ZCACHE_ALIGNED for some examples.

One way to fix this would be to give those classes their own operator new to
perform aligned allocation somehow. That's what was done for
OopStorage::Block, but it's clumsy and likely wasteful of memory. And it's
easy to forget. A general solution would probably be better. But yes, NMT
malloc headers certainly make the general problem challenging. The approach
currently used for OopStorage::Block can be generalized and hooked into the
standard mechanism.  But maybe there are (possibly non-portable) alternatives
that avoid the memory waste?

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

PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1864375915

From acobbs at openjdk.org  Wed Dec 20 15:37:48 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 20 Dec 2023 15:37:48 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
In-Reply-To: <i2dqrXTLtVjEDs2ZwOEz_DxZfYlq_hDUZAtTM_ucni8=.580b80a6-8465-423a-809f-09cdba6a2552@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
 <i2dqrXTLtVjEDs2ZwOEz_DxZfYlq_hDUZAtTM_ucni8=.580b80a6-8465-423a-809f-09cdba6a2552@github.com>
Message-ID: <K4lrwBuwborx3maPYe0tOC_G-YzeO4O_EhHt4hn_Z3o=.d8a69ee0-c797-4df6-86fe-8a0f25bda7d4@github.com>

On Wed, 20 Dec 2023 09:03:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I assume these were the reason why this-escape analysis had been disabled on java.net.http, and I expect the reason why the analysis can be reenabled by default is because of point 3 above?

No, the goal here is simply to remove unnecessary build flags. All Java code is compiled with `-Werror` so if the build still succeeds with the build flag removed then (in theory at least) the flag is no longer needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16208#issuecomment-1864689891

From aturbanov at openjdk.org  Wed Dec 20 16:19:42 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 20 Dec 2023 16:19:42 GMT
Subject: RFR: JDK-8320458: Improve structural navigation in API
 documentation
In-Reply-To: <Y2J4qzdqFTyv4UYXVEOrK5WKe0sppWdYuAl3fAUoQjM=.da828e23-7613-437e-9871-565111397222@github.com>
References: <Y2J4qzdqFTyv4UYXVEOrK5WKe0sppWdYuAl3fAUoQjM=.da828e23-7613-437e-9871-565111397222@github.com>
Message-ID: <Oxp_VSfwX43HnhiYF1xapnfV8oalEGDT44PQ5v21fp8=.f1f097db-8ab4-441b-82aa-dd615b2ba217@github.com>

On Mon, 11 Dec 2023 16:36:09 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This is a rather big change to update the structural navigation in API documentation generated by JavaDoc. It adds a table of contents for the current page to module, package, and class documentation, and replaces the old sub-navigation bar with a breadcrumb-style links in those pages. The table of contents is displayed as sidebar on wide/desktop displays and integrated into the collapsible menu for narrow/mobile displays. The generated docs can be browsed here:
> 
> https://cr.openjdk.org/~hannesw/8320458/api.00/
> 
> This change includes improvements in `stylesheet.css` and `script.js` that are not strictly related to the navigation changes, but happened as a consequence of the necessary restructuring. All these are described together with the more on-topic changes in the list below.
> 
>  - The table of contents is composed as the respective writers generate the pages. For this purpose, `HtmlDocletWriter` has a new `tocBuilder` field of new type `ListBuilder`. If the field is not `null` it is used to build the table of contents as the page is built using either one of the  new`HtmlDocletWriter.addToTableOfContents` methods or the `ListBuilder` directly.
>  - Once the TOC is built, `HtmlDocletWriter.getSideBar` is used to generate the markup for the sidebar and it is added to the page via the `BodyContents.setSideContent` method.
>  - Both existing navigation bars (top and sub-navigation) get an additional `<div>` container with CSS class `nav-content` that uses a flex layout for its content. This also handles vertical positioning, so the old workaround for vertical of the language version label in `Docs.gmk` is not necessary anymore.
>  - Apart from modules, packages, and classes, other pages that were converted to obtain a table of contents are the "Constant Field Values" page and the Help page. 
>  - Originally, I used the `<aside>` element for the sidebar, but I learned that this was the wrong element as it is meant for content that is not strictly related to the main content of the page. The prevailing notion seems to be that a table of contents is a navigation element and therefore should use the `<nav>` element, so I used that for the TOC sidebar. The same applies for the breadcrumbs sub-navigation, so I left the header `<nav>` element wrapped around both top and sub-navigation.
>  - For the new lists in TOC and breadcrumbs I used ordered list elements `<ol>` instead of unordered `<ul>` we use everywhere else, as that is what should be used when list order is important...

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 574:

> 572:                 .setStyle(HtmlStyle.toc)
> 573:                 .put(HtmlAttr.ARIA_LABEL, resources.getText("doclet.table_of_contents"));
> 574:         var sidebarHeader =  HtmlTree.DIV(HtmlStyle.tocHeader, contents.contentsHeading);

Suggestion:

        var sidebarHeader = HtmlTree.DIV(HtmlStyle.tocHeader, contents.contentsHeading);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17062#discussion_r1432919830

From sspitsyn at openjdk.org  Wed Dec 20 21:34:19 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 20 Dec 2023 21:34:19 GMT
Subject: [jdk22] RFR: 8311218: fatal error: stuck in
 JvmtiVTMSTransitionDisabler::VTMS_transition_disable
Message-ID: <COoQMKqmu8SrsLBpcEAL6FYJIkg-4CKgpBJhincsgAA=.230c8c6f-5dcc-46b9-aedc-8b99f7b43439@github.com>

Hi all,

This pull request contains a backport of commit [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Serguei Spitsyn on 19 Dec 2023 and was reviewed by Leonid Mesnik and Alan Bateman.

Thanks!

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

Commit messages:
 - Backport 0f8e4e0a81257c678e948c341a241dc0b810494f

Changes: https://git.openjdk.org/jdk22/pull/23/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=23&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311218
  Stats: 229 lines in 15 files changed: 196 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk22/pull/23.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/23/head:pull/23

PR: https://git.openjdk.org/jdk22/pull/23

From erikj at openjdk.org  Thu Dec 21 14:21:46 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 21 Dec 2023 14:21:46 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <5tfqJ0axChFrBuu-YP6qxuVp6w98q26qBt-jusjSPuM=.a81fb73b-49cf-4391-99c0-f31a53f8d431@github.com>

On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

The build changes look ok.

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

PR Review: https://git.openjdk.org/jdk/pull/16208#pullrequestreview-1793061991

From naoto at openjdk.org  Fri Dec 22 19:05:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Dec 2023 19:05:05 GMT
Subject: RFR: 8322647: Short name for the `Europe/Lisbon` time zone is
 incorrect
Message-ID: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>

This is a regression caused by the fix to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is generated during the build time has the following diffs from the previous (incorrect) one:

--- master/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-18 10:28:57
+++ tz/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-22 10:09:13
@@ -304,11 +304,11 @@
             };
         final String[] Azores = new String[] {
                "Azores Standard Time",
-               "HMT",
+               "",
                "Azores Summer Time",
-               "HMT",
+               "",
                "Azores Time",
-               "HMT",
+               "",
             };
         final String[] Bhutan = new String[] {
                "Bhutan Time",
@@ -968,11 +968,11 @@
             };
         final String[] Africa_Central = new String[] {
                "Central Africa Time",
-               "SAST",
-               "",
-               "SAST",
+               "CAT",
                "",
-               "SAST",
+               "CAT",
+               "",
+               "CAT",
             };
         final String[] Africa_Eastern = new String[] {
                "East Africa Time",
@@ -1016,11 +1016,11 @@
             };
         final String[] Europe_Western = new String[] {
                "Western European Standard Time",
-               "FMT",
-               "Western European Summer Time",
-               "FMT",
+               "WET",
+               "Western European Summer Time",
+               "WEST",
                "Western European Time",
-               "FMT",
+               "WET",
             };
         final String[] Mexico_Pacific = new String[] {
                "Mexican Pacific Standard Time",
@@ -1152,11 +1152,11 @@
             };
         final String[] Australia_Western = new String[] {
                "Australian Western Standard Time",
-               "",
+               "AWST",
                "Australian Western Daylight Time",
-               "",
+               "AWDT",
                "Western Australia Time",
-               "",
+               "AWT",
             };
         final String[] Greenland_Eastern = new String[] {
                "East Greenland Standard Time",

Previously, they all had wrong short names due to incorrect parsing.

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

Commit messages:
 - initial commit

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

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